US20240073135A1 - BGP Segment Routing optimization by packing multiple prefixes in an update - Google Patents
BGP Segment Routing optimization by packing multiple prefixes in an update Download PDFInfo
- Publication number
- US20240073135A1 US20240073135A1 US17/962,618 US202217962618A US2024073135A1 US 20240073135 A1 US20240073135 A1 US 20240073135A1 US 202217962618 A US202217962618 A US 202217962618A US 2024073135 A1 US2024073135 A1 US 2024073135A1
- Authority
- US
- United States
- Prior art keywords
- bgp
- label
- prefixes
- update message
- peers
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012856 packing Methods 0.000 title claims abstract description 35
- 238000005457 optimization Methods 0.000 title description 13
- 238000000034 method Methods 0.000 claims abstract description 33
- 238000013507 mapping Methods 0.000 claims description 6
- 241000465502 Tobacco latent virus Species 0.000 description 29
- 230000008569 process Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 238000013459 approach Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000006872 improvement Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
- H04L45/748—Address table lookup; Address filtering using longest matching prefix
Definitions
- the present disclosure relates generally to networking and computing. More particularly, the present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update.
- BGP border gateway protocol
- RFC 8669 “Segment Routing Prefix Segment Identifier Extensions for BGP,” December 2019, the contents of which are incorporated by reference in their entirety describes mechanisms for distributing BGP Segment Routing (BGP-SR) segment identifiers (SIDs) to BGP peers in BGP update messages.
- BGP-SR uses BGP Label-unicast network layer reachability information (NLRI) and adds new type-length-value (TLVs) in BGP update messages.
- NLRI BGP Label-unicast network layer reachability information
- TLVs new type-length-value
- Segment Routing leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called “segments.”
- a segment can represent any instruction, topological or service based.
- the ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs).
- SIDs segment identifiers
- Each SID represents a topological or service-based instruction.
- Per-flow state is maintained only on the ingress node of the SR domain.
- An “SR domain” is defined as a single administrative domain for global SID assignment.
- RFC 8669 defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.
- RFC 8669 One disadvantage of the approach described in RFC 8669 is a label index (Li) is associated with each BGP prefix. With a unique label index per NLRI in the attributes, there has to be a BGP update for each prefix. Use of RFC 8669 thus prevents the ability to pack multiple BGP-NLRIs in a single BGP update, referred to as BGP update packing for scale performance improvements.
- the present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update.
- BGP border gateway protocol
- the present disclosure includes a unique mechanism for packing BGP updates in a single update message for BGP-SR prefixes. This mechanism derives the BGP prefix SID from the NLRI label rather than the Label-Index TLV. Accordingly, Label-Index TLV in BGP prefix SID attribute, from RFC 8669, is not required allowing for packing BGP SR prefixes with different prefix SIDs in a single BGP update.
- This approach provides performance improvements on both the sender and receiver side resulting in better convergence time. Also, this approach is backward compatible and proposes a new BGP capability to enable this optimization.
- a router includes circuitry configured to negotiate with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates, receive a plurality of prefixes for a BGP-SR update message, encode the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, and transmit the BGP-SR update message to any of the BGP peers.
- BGP border gateway protocol
- BGP-SR Border gateway protocol
- NLRI network layer reachability information
- the plurality of prefixes all share same attributes.
- the BGP peers can all include a same segment routing global block (SRGB). Any of the BGP peers can include a different segment routing global block (SRGB), and wherein the circuitry is further configured to encode the SRGB of a node performing the transmitting in an attribute.
- the circuitry can be further configured to, responsive to any BGP peers failing to support the packing BGP-SR updates, encode each prefix in a separate BGP-SR update message.
- the circuitry can be further configured to receive a second BGP-SR update message from any of the BGP peers and determine an incoming label mapping (ILM) table based thereon.
- the associated label information can include the label for a corresponding prefix.
- the associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label and a segment routing global block (SRGB).
- the plurality of prefixes can be any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- a method in another embodiment, includes negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates; receiving a plurality of prefixes for a BGP-SR update message; encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message; and transmitting the BGP-SR update message to any of the BGP peers.
- the plurality of prefixes all share same attributes.
- the BGP peers can all include a same segment routing global block (SRGB). Any of the BGP peers include a different segment routing global block (SRGB), and wherein the steps can include encoding the SRGB of a node performing the transmitting in an attribute.
- the steps can include, responsive to any BGP peers failing to support the packing BGP-SR updates, encoding each prefix in a separate BGP-SR update message.
- the steps can include receiving a second BGP-SR update message from any of the BGP peers and determining an incoming label mapping (ILM) table based thereon.
- the associated label information can include the label for a corresponding prefix.
- the associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label and a segment routing global block (SRGB).
- the plurality of prefixes can be any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- a non-transitory computer-readable medium includes instructions that, when executed, cause a network element to perform steps of negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates; receiving a plurality of prefixes for a BGP-SR update message; encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message; and transmitting the BGP-SR update message to any of the BGP peers.
- BGP border gateway protocol
- BGP-SR BGP-Segment Routing
- FIG. 1 is a diagram of a Label-Index TLV from RFC 8669.
- FIG. 2 is a diagram of an Originator SRGB TLV from RFC 8669.
- FIG. 3 is a network diagram of an example network for illustrating BGP-SR updates and the packing solution described herein.
- FIG. 4 is a network diagram of a network for illustrating a single update with the label index in the NLRI with all nodes having the same SRGB.
- FIG. 5 is a network diagram of the network 50 for illustrating a single update with the label index in the NLRI with all nodes having a different SRGB.
- FIG. 6 is a flowchart of a process for border gateway protocol (BGP) Segment Routing optimization by packing updates.
- BGP border gateway protocol
- the present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update.
- the present disclosure includes a unique mechanism for packing BGP updates in a single update message for BGP-SR prefixes. This mechanism derives the BGP prefix SID from the NLRI label rather than the Label-Index TLV. Accordingly, Label-Index TLV in BGP prefix SID attribute, from RFC 8669, is not required allowing for packing BGP SR prefixes with different prefix SIDs in a single BGP update.
- This approach provides performance improvements on both the sender and receiver side resulting in better convergence time. Also, this approach is backward compatible and proposes a new BGP capability to enable this optimization.
- the Segment Routing (SR) architecture leverages the source-routing paradigm.
- a segment represents either a topological instruction, such as “go to prefix P following shortest path”, or a service instruction. Other types of segments may be defined in the future.
- a segment is identified through a Segment Identifier (SID).
- SID Segment Identifier
- An “SR domain” is defined as a single administrative domain for global SID assignment. It may include a single Autonomous System (AS) or multiple ASes under consolidated global SID administration. Typically, the ingress node of the SR domain prepends an SR header containing SIDs to an incoming packet.
- the SID includes a label.
- a BGP Prefix Segment is a BGP prefix with a Prefix-SID attached.
- a BGP Prefix-SID is always a global SID (RFC 8402) within the SR domain and identifies an instruction to forward the packet over the Equal-Cost Multipath (ECMP) best path computed by BGP to the related prefix.
- the BGP Prefix-SID is the identifier of the BGP Prefix Segment. As described herein, we always refer to the BGP Prefix Segment by the BGP Prefix-SID.
- RFC 8669 describes the BGP extensions to signal the BGP Prefix-SID. Specifically, RFC 8669 defines a BGP attribute known as the “BGP Prefix-SID attribute” and specifies the rules to originate, receive, and handle error conditions for the attribute.
- the BGP Prefix-SID attribute defined in RFC 8669 can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast (see RFC 4760, “Multiprotocol Extensions for BGP-4,” January 2007, and RFC 8277, “Using BGP to Bind MPLS Labels to Address Prefixes,” October 2017, the contents of each are incorporated by reference in their entirety).
- RFC 8670 “BGP Prefix Segment in Large-Scale Data Centers,” December 2019, the contents of which are incorporated by reference in their entirety, describes example use cases where the BGP Prefix-SID is used for the above AFI/SAFI combinations.
- the BGP Prefix-SID is realized on the MPLS data plane in the following way:
- the BGP Prefix-SID attribute is an optional, transitive BGP path attribute.
- the attribute type code 40 has been assigned by IANA.
- the BGP Prefix-SID attribute is defined in RFC 8669 to be a set of elements encoded as “Type/Length/Value” tuples (i.e., a set of TLVs). All BGP Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet length.
- the following TLVs are defined in RFC 8669: Label-Index TLV ( FIG. 1 ) and Originator SRGB TLV ( FIG. 2 ).
- the Label-Index and Originator SRGB TLVs are used only when SR is applied to the MPLS data plane.
- the Label-Index TLV is present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes.
- the Label-Index TLV includes a Type: 1, Length: 7, the total length in octets of the value portion of the TLV, RESERVED: 8-bit field, Flags: 16 bits of flags, and Label Index: 32-bit value representing the index value in the SRGB space.
- the Originator SRGB TLV is an optional TLV and includes Type: 3, Length: The total length in octets of the value portion of the TLV: 2+(non-zero multiple of 6), Flags: 16 bits of flags, and SRGB: 3 octets specifying the first label in the range followed by 3 octets specifying the number of labels in the range. Note that the SRGB field may appear multiple times. If the SRGB field appears multiple times, the SRGB consists of multiple ranges that are concatenated.
- the Originator SRGB TLV contains the SRGB of the node originating the prefix to which the BGP Prefix-SID is attached.
- update messaging is optimized by packing multiple prefixes that share BGP attributes (AS-path, multiple exit discriminator (MED), etc.) in single update message. This helps in multifold performance improvement at both sender and receiver as otherwise sender need to create/encode/send N updates and receiver need to individually decode/process individual updates.
- AS-path BGP attributes
- MED exit discriminator
- BGP-SR In BGP-SR, with the Label-index being part of attributes in BGP update message and Label-Index being unique for each prefix, BGP cannot pack updates multiple BGP-SR NLRIs that have same other attributes into single update message. This results in single BGP-SR update message per prefix. In a scaled network, it will be individual update message per prefix and hence not optimized from performance perspective.
- FIG. 3 is a network diagram of an example network 10 for illustrating BGP-SR updates 12 and the packing solution described herein.
- the network 10 includes three SR domains 14 , 16 , 18 .
- the domain 14 includes an ASR 20 and an ASR9k 22 connected to an evolved packet core (EPC) 24 .
- the domain 16 includes the ASR 20 connected to two route reflectors (RR 1 , RR 2 ) 26 , 28 .
- the domain 18 includes the RR 1 , RR 2 26 , 28 and routers 30 , 32 , 34 .
- the RR 1 , RR 2 26 , 28 are configured to provide the BGP-SR updates 12 from the domains 14 , 16 .
- the example network 10 is presented for illustration purposes and other embodiments are contemplated.
- the present disclosure relates to the BGP-SR updates 12 and a packing solution that overcomes the limitations in RFC 8669.
- the BGP-SR updates 12 can be performed by any of the ASR 20 , ASR9k 22 , EPC 24 , RR 1 , RR 2 26 , 28 , and the routers 30 , 32 , 34 .
- a BGP prefix SID based Label is carried in the NLRI and BGP prefix SID label Index can be derived from Label in NLRI, instead of adding label Index TLV in BGP update message.
- BGP prefix SID label Index can be derived from Label in NLRI, instead of adding label Index TLV in BGP update message.
- This provides a single BGP-SR update message for BGP Prefixes with the same attributes.
- This mechanism derives the BGP prefix SID from the label Index TLV in BGP prefix SID.
- Label Index TLV is not required in BGP prefix SID TLV that results in packing.
- BGP prefix SID TLV is not required that results in packing BGP SR prefixes with different prefix SIDs in single BGP update.
- BGP-SR update packing To enable this mode a new BGP capability is proposed referred to as BGP-SR update packing.
- BGP sender e.g., the RR 1 , RR 2 26 , 28
- BGP NLRI with actual Label (SRGB start+Li)
- BGP Label-Index TLV This will assure that rest of attributes can be shared and so multiple NLRI's can be packed in single update message.
- a new optional sub-TLV attribute in the BGP prefix SID can be referred to as a peer SRGB range sub-TLV.
- This will carry a BGP peers SRGB range.
- the SRGB range is kept same throughout the SR domains 14 , 16 , 18 . This is optional if the domains 14 , 16 , 18 have different SRGBs.
- this sub-TLV attribute is not present, a node will use its own SRGB range and calculate the label-index. The calculation can include:
- Label Index Label(fetched from NLRI)—Peer SRGB start Label(either from peer SRGB sub-TLV or local SRGB start Label).
- the node will use the start label in the SRGB and the label index to create its own in-label for an incoming label mapping (ILM) table.
- ILM incoming label mapping
- the new optional sub-TLV attribute can be added. All the prefixes that are coming from this node (with the network service header (NSH) will have same Peer SRGB range and can still be shared in single update message.
- NSH network service header
- this new BGP capability will ensure that we are backward compatible with RFC8669.
- a node will behave as per RFC 8669.
- FIG. 4 is a network diagram of a network 50 for illustrating a single update with the label index in the NLRI with all nodes 52 , 54 , 56 having the same SRGB.
- the SRGB is 100 to 200.
- node 1 52 is sending three prefixes (1.1.1.1, 2.2.2.2, 3.3.3.3) towards nodes 2 54 and each prefix has a unique label index (+10, +20, +30 for 1.1.1.1, 2.2.2.2, 3.3.3.3, respectively). All prefixes will be sent in a single update message having the following information:
- FIG. 5 is a network diagram of the network 50 for illustrating a single update with the label index in the NLRI with all nodes 52 , 54 , 56 having a different SRGB.
- the SRGB is 100 to 200 at the node 1 52 , 200 to 300 at the node 2 54 , and 300 to 400 at the node 3 56 .
- node 1 52 is sending three prefixes (1.1.1.1, 2.2.2.2, 3.3.3.3) towards nodes 2 54 and each prefix has a unique label index (+10, +20, +30 for 1.1.1.1, 2.2.2.2, 3.3.3.3, respectively). All prefixes will be sent in a single update message having the following information:
- the Label Index Actual label received in NLRI ⁇ Peer SRGB start label.
- the node 2 56 can determine an ILM table 64 as
- FIG. 6 is a flowchart of a process 100 for border gateway protocol (BGP) Segment Routing optimization by packing updates.
- the process 100 contemplates implementation as a method having steps, via any network element in the network 10 , including the routers 30 , 32 , 34 , the route reflectors (RR 1 , RR 2 ), and the like, as well as instructions stored in a non-transitory computer-readable medium that cause circuitry or the like to implement the steps.
- Border gateway protocol BGP
- the process 100 includes negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates (step 102 ); receiving a plurality of prefixes for a BGP-SR update message (step 104 ); encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message (step 106 ); and transmitting the BGP-SR update message to any of the BGP peers (step 108 ).
- the plurality of prefixes all share same attributes, and the label is not encoded as an attribute as per RFC 8669.
- the BGP peers all can include a same segment routing global block (SRGB). Also, ant of the BGP peers can include a different segment routing global block (SRGB), and wherein the process 100 includes encoding the SRGB of a node performing the transmitting in an attribute.
- SRGB segment routing global block
- the process 100 can include, responsive to any BGP peers failing to support the packing BGP-SR updates, encoding each prefix in a separate BGP-SR update message as per RFC 8669.
- the process 100 can include receiving a second BGP-SR update message from any of the BGP peers and determining an incoming label mapping (ILM) table based thereon, such as described in FIGS. 4 and 5 .
- ILM incoming label mapping
- the associated label information can include the label for a corresponding prefix.
- the associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label index and a segment routing global block (SRGB).
- the plurality of prefixes are any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- processors such as microprocessors; central processing units (CPUs); digital signal processors (DSPs): customized processors such as network processors (NPs) or network processing units (NPUs), graphics processing units (GPUs), or the like; field programmable gate arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein.
- processors such as microprocessors; central processing units (CPUs); digital signal processors (DSPs): customized processors such as network processors (NPs) or network processing units (NPUs), graphics processing units (GPUs), or the like; field programmable gate arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein.
- circuitry configured or adapted to
- logic configured or adapted to
- some embodiments may include a non-transitory computer-readable storage medium having computer-readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein.
- Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), Flash memory, and the like.
- software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.
- a processor or device e.g., any type of programmable circuitry or logic
Abstract
Systems and methods for border gateway protocol (BGP) Segment Routing (SR) (BGP-SR) update packing include negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates, receiving a plurality of prefixes for a BGP-SR update message, encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, and transmitting the BGP-SR update message to any of the BGP peers.
Description
- The present disclosure relates generally to networking and computing. More particularly, the present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update.
- RFC 8669, “Segment Routing Prefix Segment Identifier Extensions for BGP,” December 2019, the contents of which are incorporated by reference in their entirety describes mechanisms for distributing BGP Segment Routing (BGP-SR) segment identifiers (SIDs) to BGP peers in BGP update messages. BGP-SR uses BGP Label-unicast network layer reachability information (NLRI) and adds new type-length-value (TLVs) in BGP update messages. As noted in RFC 8669, Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called “segments.” A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An “SR domain” is defined as a single administrative domain for global SID assignment. RFC 8669 defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.
- One disadvantage of the approach described in RFC 8669 is a label index (Li) is associated with each BGP prefix. With a unique label index per NLRI in the attributes, there has to be a BGP update for each prefix. Use of RFC 8669 thus prevents the ability to pack multiple BGP-NLRIs in a single BGP update, referred to as BGP update packing for scale performance improvements.
- The present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update. The present disclosure includes a unique mechanism for packing BGP updates in a single update message for BGP-SR prefixes. This mechanism derives the BGP prefix SID from the NLRI label rather than the Label-Index TLV. Accordingly, Label-Index TLV in BGP prefix SID attribute, from RFC 8669, is not required allowing for packing BGP SR prefixes with different prefix SIDs in a single BGP update. This approach provides performance improvements on both the sender and receiver side resulting in better convergence time. Also, this approach is backward compatible and proposes a new BGP capability to enable this optimization.
- In an embodiment, a router includes circuitry configured to negotiate with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates, receive a plurality of prefixes for a BGP-SR update message, encode the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, and transmit the BGP-SR update message to any of the BGP peers. The plurality of prefixes all share same attributes. The BGP peers can all include a same segment routing global block (SRGB). Any of the BGP peers can include a different segment routing global block (SRGB), and wherein the circuitry is further configured to encode the SRGB of a node performing the transmitting in an attribute. The circuitry can be further configured to, responsive to any BGP peers failing to support the packing BGP-SR updates, encode each prefix in a separate BGP-SR update message. The circuitry can be further configured to receive a second BGP-SR update message from any of the BGP peers and determine an incoming label mapping (ILM) table based thereon. The associated label information can include the label for a corresponding prefix. The associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label and a segment routing global block (SRGB). The plurality of prefixes can be any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- In another embodiment, a method includes negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates; receiving a plurality of prefixes for a BGP-SR update message; encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message; and transmitting the BGP-SR update message to any of the BGP peers. The plurality of prefixes all share same attributes. The BGP peers can all include a same segment routing global block (SRGB). Any of the BGP peers include a different segment routing global block (SRGB), and wherein the steps can include encoding the SRGB of a node performing the transmitting in an attribute. The steps can include, responsive to any BGP peers failing to support the packing BGP-SR updates, encoding each prefix in a separate BGP-SR update message. The steps can include receiving a second BGP-SR update message from any of the BGP peers and determining an incoming label mapping (ILM) table based thereon. The associated label information can include the label for a corresponding prefix. The associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label and a segment routing global block (SRGB). The plurality of prefixes can be any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- In a further embodiment, a non-transitory computer-readable medium includes instructions that, when executed, cause a network element to perform steps of negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates; receiving a plurality of prefixes for a BGP-SR update message; encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message; and transmitting the BGP-SR update message to any of the BGP peers. The plurality of prefixes all share same attributes.
- The present disclosure is illustrated and described herein with reference to the various drawings, in which like reference numbers are used to denote like system components/method steps, as appropriate, and in which:
-
FIG. 1 is a diagram of a Label-Index TLV from RFC 8669. -
FIG. 2 is a diagram of an Originator SRGB TLV from RFC 8669. -
FIG. 3 is a network diagram of an example network for illustrating BGP-SR updates and the packing solution described herein. -
FIG. 4 is a network diagram of a network for illustrating a single update with the label index in the NLRI with all nodes having the same SRGB. -
FIG. 5 is a network diagram of thenetwork 50 for illustrating a single update with the label index in the NLRI with all nodes having a different SRGB. -
FIG. 6 is a flowchart of a process for border gateway protocol (BGP) Segment Routing optimization by packing updates. - Again, the present disclosure relates to systems and methods for border gateway protocol (BGP) Segment Routing optimization by packing multiple prefixes in an update. The present disclosure includes a unique mechanism for packing BGP updates in a single update message for BGP-SR prefixes. This mechanism derives the BGP prefix SID from the NLRI label rather than the Label-Index TLV. Accordingly, Label-Index TLV in BGP prefix SID attribute, from RFC 8669, is not required allowing for packing BGP SR prefixes with different prefix SIDs in a single BGP update. This approach provides performance improvements on both the sender and receiver side resulting in better convergence time. Also, this approach is backward compatible and proposes a new BGP capability to enable this optimization.
- The Segment Routing (SR) architecture leverages the source-routing paradigm. A segment represents either a topological instruction, such as “go to prefix P following shortest path”, or a service instruction. Other types of segments may be defined in the future. A segment is identified through a Segment Identifier (SID). An “SR domain” is defined as a single administrative domain for global SID assignment. It may include a single Autonomous System (AS) or multiple ASes under consolidated global SID administration. Typically, the ingress node of the SR domain prepends an SR header containing SIDs to an incoming packet.
- As described in RFC 8402, “Segment Routing Architecture,” July 2018, the contents of which are incorporated by reference in their entirety, when SR is applied to the MPLS data plane (see RFC 8660, “Segment Routing with the MPLS Data Plane,” December 2019, the contents of which are incorporated by reference in their entirety), the SID includes a label.
- A BGP Prefix Segment is a BGP prefix with a Prefix-SID attached. A BGP Prefix-SID is always a global SID (RFC 8402) within the SR domain and identifies an instruction to forward the packet over the Equal-Cost Multipath (ECMP) best path computed by BGP to the related prefix. The BGP Prefix-SID is the identifier of the BGP Prefix Segment. As described herein, we always refer to the BGP Prefix Segment by the BGP Prefix-SID.
- RFC 8669 describes the BGP extensions to signal the BGP Prefix-SID. Specifically, RFC 8669 defines a BGP attribute known as the “BGP Prefix-SID attribute” and specifies the rules to originate, receive, and handle error conditions for the attribute.
- The BGP Prefix-SID attribute defined in RFC 8669 can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast (see RFC 4760, “Multiprotocol Extensions for BGP-4,” January 2007, and RFC 8277, “Using BGP to Bind MPLS Labels to Address Prefixes,” October 2017, the contents of each are incorporated by reference in their entirety). RFC 8670, “BGP Prefix Segment in Large-Scale Data Centers,” December 2019, the contents of which are incorporated by reference in their entirety, describes example use cases where the BGP Prefix-SID is used for the above AFI/SAFI combinations.
- It should be noted that:
-
- 1) A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same SR domain. Alternatively, when interconnecting ASes, the Autonomous system border routers (ASBRs) of each domain will have to handle the advertisement of unique SIDs.
- 2) A BGP Prefix-SID may be attached to a BGP prefix. This implies that each prefix is advertised individually, reducing the ability to pack BGP advertisements (when sharing common attributes). Again, the present disclosure addresses this deficiency.
- The BGP Prefix-SID is realized on the MPLS data plane in the following way:
-
- 1) The operator assigns a globally unique label index, L_I, to a locally originated prefix of a BGP speaker N, which is advertised to all other BGP speakers in the SR domain.
- 2) According to RFC 8402, each BGP speaker is configured with a label block called the segment routing global block (SRGB). While RFC 8402 recommends using the same SRGB across all the nodes within the SR domain, the SRGB of a node is a local property and could be different on different speakers.
- 3) If traffic engineering within the SR domain is required, each node may also be required to advertise topological information and Peer SIDs for each of its links and peers. This information is required to perform the explicit path computation and to express an explicit path as a list of SIDs. The advertisement of topological information and peer segments (Peer SIDs) is done through.
- 4) If a prefix segment is to be included in an MPLS label stack, e.g., for traffic-engineering purposes, knowledge of the prefix originator's SRGB is required in order to compute the local label used by the originator.
- 5) RFC 8669 assumes that Border Gateway Protocol-Link State (BGP-LS) is the preferred method for a collecting both peer segments (Peer SIDs) and SRGB information through RFC 7752, “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP,” March 2016, the contents of which are incorporated by reference in their entirety. However, as an optional alternative for the advertisement of the local SRGB without the topology or the peer SIDs and, therefore, without applicability for TE, the Originator SRGB TLV of the BGP Prefix-SID attribute is specified in Sec. 3.2 of RFC 8669.
- 6) A BGP speaker will derive its local MPLS label L from the label index L_I and its local SRGB as described in RFC 8660. The BGP speaker then programs the MPLS label L in its MPLS data plane as its incoming/local label for the prefix.
- 7) The outgoing label for the prefix is found in the Network Layer Reachability Information (NLRI) of the Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement as defined in RFC 8277. The label index L_I is only used as a hint to derive the local/incoming label.
- 8) Sec. 3.1 of RFC 8669 specifies the Label-Index TLV of the BGP Prefix-SID attribute; this TLV can be used to advertise the label index for a given prefix.
- The BGP Prefix-SID attribute is an optional, transitive BGP path attribute. The attribute type code 40 has been assigned by IANA.
- The BGP Prefix-SID attribute is defined in RFC 8669 to be a set of elements encoded as “Type/Length/Value” tuples (i.e., a set of TLVs). All BGP Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet length. The following TLVs are defined in RFC 8669: Label-Index TLV (
FIG. 1 ) and Originator SRGB TLV (FIG. 2 ). The Label-Index and Originator SRGB TLVs are used only when SR is applied to the MPLS data plane. - The Label-Index TLV is present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes. The Label-Index TLV includes a Type: 1, Length: 7, the total length in octets of the value portion of the TLV, RESERVED: 8-bit field, Flags: 16 bits of flags, and Label Index: 32-bit value representing the index value in the SRGB space.
- The Originator SRGB TLV is an optional TLV and includes Type: 3, Length: The total length in octets of the value portion of the TLV: 2+(non-zero multiple of 6), Flags: 16 bits of flags, and SRGB: 3 octets specifying the first label in the range followed by 3 octets specifying the number of labels in the range. Note that the SRGB field may appear multiple times. If the SRGB field appears multiple times, the SRGB consists of multiple ranges that are concatenated.
- The Originator SRGB TLV contains the SRGB of the node originating the prefix to which the BGP Prefix-SID is attached.
- When BGP-SR is enabled—
-
- 1) A segment identifier Label Index (Li) is manually associated with each BGP prefix.
- 2) Li+SRGB start-label→BGP SR label for prefix carried in NLRI
- 3) Label-Index Li is carried as attribute in MP-BGP packet in BGP update message
- In BGP, update messaging is optimized by packing multiple prefixes that share BGP attributes (AS-path, multiple exit discriminator (MED), etc.) in single update message. This helps in multifold performance improvement at both sender and receiver as otherwise sender need to create/encode/send N updates and receiver need to individually decode/process individual updates.
- In BGP-SR, with the Label-index being part of attributes in BGP update message and Label-Index being unique for each prefix, BGP cannot pack updates multiple BGP-SR NLRIs that have same other attributes into single update message. This results in single BGP-SR update message per prefix. In a scaled network, it will be individual update message per prefix and hence not optimized from performance perspective.
- Packing allows all NLRIs to be sent in single update message resulting in single update TX (faster Transmission of updates) and lesser update processing on receiving side. This is important scale optimization in BGP that give multifold scale performance improvements. With unique label-index per NLRI in attribute, BGP-SR results in NO packing of BGP-SR NLRIs, and this has scale impact.
-
FIG. 3 is a network diagram of anexample network 10 for illustrating BGP-SR updates 12 and the packing solution described herein. Thenetwork 10 includes threeSR domains domain 14 includes anASR 20 and anASR9k 22 connected to an evolved packet core (EPC) 24. Thedomain 16 includes theASR 20 connected to two route reflectors (RR1, RR2) 26, 28. Thedomain 18 includes the RR1,RR2 routers RR2 SR updates 12 from thedomains example network 10 is presented for illustration purposes and other embodiments are contemplated. The present disclosure relates to the BGP-SR updates 12 and a packing solution that overcomes the limitations in RFC 8669. As such, the BGP-SR updates 12 can be performed by any of theASR 20,ASR9k 22,EPC 24, RR1,RR2 routers - In various embodiments, a BGP prefix SID based Label is carried in the NLRI and BGP prefix SID label Index can be derived from Label in NLRI, instead of adding label Index TLV in BGP update message. This provides a single BGP-SR update message for BGP Prefixes with the same attributes. This mechanism derives the BGP prefix SID from the label Index TLV in BGP prefix SID. Hence, Label Index TLV is not required in BGP prefix SID TLV that results in packing. Hence, BGP prefix SID TLV is not required that results in packing BGP SR prefixes with different prefix SIDs in single BGP update.
- To enable this mode a new BGP capability is proposed referred to as BGP-SR update packing. For BGP peers, e.g., the RR1,
RR2 routers RR2 26, 28) will encode BGP NLRI with actual Label (SRGB start+Li) and will not add BGP Label-Index TLV. This will assure that rest of attributes can be shared and so multiple NLRI's can be packed in single update message. - In addition, a new optional sub-TLV attribute in the BGP prefix SID can be referred to as a peer SRGB range sub-TLV. This will carry a BGP peers SRGB range. In most of SR deployments, the SRGB range is kept same throughout the
SR domains domains - Label Index=Label(fetched from NLRI)—Peer SRGB start Label(either from peer SRGB sub-TLV or local SRGB start Label).
- Accordingly, the node will use the start label in the SRGB and the label index to create its own in-label for an incoming label mapping (ILM) table.
- In a scenario where we have different SRGB range in the same SR domain, the new optional sub-TLV attribute can be added. All the prefixes that are coming from this node (with the network service header (NSH) will have same Peer SRGB range and can still be shared in single update message.
- Also, this new BGP capability will ensure that we are backward compatible with RFC8669. In case the new BGP capability is not negotiated, a node will behave as per RFC 8669.
-
FIG. 4 is a network diagram of anetwork 50 for illustrating a single update with the label index in the NLRI with allnodes node 1 52 is sending three prefixes (1.1.1.1, 2.2.2.2, 3.3.3.3) towardsnodes 2 54 and each prefix has a unique label index (+10, +20, +30 for 1.1.1.1, 2.2.2.2, 3.3.3.3, respectively). All prefixes will be sent in a single update message having the following information: -
Attributes Shared for all prefixes Reach NLRI 1.1.1.1/110 (label index = 10) 2.2.2.2/120 (label index = 20) 3.3.3.3/130 (label index = 30) - The
node 2 54 will calculate the out label=local SRGB start label+Label_index received in NLRI. For example, for prefix 1.1.1.1, out label=100+10=110. Accordingly, thenode 2 54 can determine an ILM table 60 as -
Prefix In-label Out-label 1.1.1.1 110 110 2.2.2.2 120 120 3.3.3.3 130 130 -
FIG. 5 is a network diagram of thenetwork 50 for illustrating a single update with the label index in the NLRI with allnodes node 1 52, 200 to 300 at thenode 2 54, and 300 to 400 at thenode 3 56. Again, similar toFIG. 4 , in thisexample node 1 52 is sending three prefixes (1.1.1.1, 2.2.2.2, 3.3.3.3) towardsnodes 2 54 and each prefix has a unique label index (+10, +20, +30 for 1.1.1.1, 2.2.2.2, 3.3.3.3, respectively). All prefixes will be sent in a single update message having the following information: -
Attributes Shared for all prefixes optional peer SRGB sub-TLV attribute Peer SRGB 100-200 Reach NLRI 1.1.1.1/110 (label index = 10) 2.2.2.2/120 (label index = 20) 3.3.3.3/130 (label index = 30) - The
node 2 54 will calculate the out label=local SRGB start label+Label_index received in NLRI. For example, for prefix 1.1.1.1, out label=100+10=110. The Label Index=Actual label received in NLRI−Peer SRGB start label. For prefix 1.1.1.1 on thenode 2 54, Label Index=110−100 (SRGB of thenode 1 52)=10. The In-label for 1.1.1.1 on thenode 2 54, in-label=200 (Local SRGB start Label)+10 (label Index calculated above)=210. Accordingly, thenode 2 54 can determine an ILM table 62 as -
Prefix In-label Out-label 1.1.1.1 210 110 2.2.2.2 220 120 3.3.3.3 230 130 - Similarly, for prefix 1.1.1.1 on the
node 3 56, Label Index=210-200 (Peer SRGB for Node 2)=10. Accordingly, thenode 2 56 can determine an ILM table 64 as -
Prefix In-label Out-label 1.1.1.1 310 210 2.2.2.2 320 220 3.3.3.3 330 230 -
FIG. 6 is a flowchart of aprocess 100 for border gateway protocol (BGP) Segment Routing optimization by packing updates. Theprocess 100 contemplates implementation as a method having steps, via any network element in thenetwork 10, including therouters - The
process 100 includes negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates (step 102); receiving a plurality of prefixes for a BGP-SR update message (step 104); encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message (step 106); and transmitting the BGP-SR update message to any of the BGP peers (step 108). The plurality of prefixes all share same attributes, and the label is not encoded as an attribute as per RFC 8669. - The BGP peers all can include a same segment routing global block (SRGB). Also, ant of the BGP peers can include a different segment routing global block (SRGB), and wherein the
process 100 includes encoding the SRGB of a node performing the transmitting in an attribute. - The
process 100 can include, responsive to any BGP peers failing to support the packing BGP-SR updates, encoding each prefix in a separate BGP-SR update message as per RFC 8669. Theprocess 100 can include receiving a second BGP-SR update message from any of the BGP peers and determining an incoming label mapping (ILM) table based thereon, such as described inFIGS. 4 and 5 . - The associated label information can include the label for a corresponding prefix. The associated label information can include a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label index and a segment routing global block (SRGB). The plurality of prefixes are any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
- It will be appreciated that some embodiments described herein may include one or more generic or specialized processors (“one or more processors”) such as microprocessors; central processing units (CPUs); digital signal processors (DSPs): customized processors such as network processors (NPs) or network processing units (NPUs), graphics processing units (GPUs), or the like; field programmable gate arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more application-specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured or adapted to,” “logic configured or adapted to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.
- Moreover, some embodiments may include a non-transitory computer-readable storage medium having computer-readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.
- Although the present disclosure has been illustrated and described herein with reference to preferred embodiments and specific examples thereof, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions and/or achieve like results. All such equivalent embodiments and examples are within the spirit and scope of the present disclosure, are contemplated thereby, and are intended to be covered by the following claims. The foregoing sections include headers for various embodiments and those skilled in the art will appreciate these various embodiments may be used in combination with one another as well as individually.
Claims (20)
1. A router comprising circuitry configured to:
negotiate with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates,
receive a plurality of prefixes for a BGP-SR update message,
encode the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, wherein the associated label information in the NLRI is utilized to derive a Segment Identifier (SID) for a corresponding prefix of the plurality of prefixes, and
transmit the BGP-SR update message to any of the BGP peers.
2. The router of claim 1 , wherein the plurality of prefixes all share same attributes.
3. The router of claim 1 , wherein the BGP peers all include a same segment routing global block (SRGB).
4. The router of claim 1 , wherein any of the BGP peers include a different segment routing global block (SRGB), and wherein the circuitry is further configured to
encode the SRGB of a node performing the transmitting in an attribute.
5. The router of claim 1 , wherein the circuitry is further configured to
responsive to any BGP peers failing to support the packing BGP-SR updates, encode each prefix in a separate BGP-SR update message.
6. The router of claim 1 , wherein the circuitry is further configured to
receive a second BGP-SR update message from any of the BGP peers and determine an incoming label mapping (ILM) table based thereon.
7. The router of claim 1 , wherein the associated label information includes the label for a corresponding prefix.
8. The router of claim 1 , wherein the associated label information includes a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label index and a segment routing global block (SRGB) start.
9. The router of claim 1 , wherein the plurality of prefixes are any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
10. A method comprising steps of:
negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates;
receiving a plurality of prefixes for a BGP-SR update message;
encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, wherein the associated label information in the NLRI is utilized to derive a Segment Identifier (SID) for a corresponding prefix of the plurality of prefixes; and
transmitting the BGP-SR update message to any of the BGP peers.
11. The method of claim 10 , wherein the plurality of prefixes all share same attributes.
12. The method of claim 10 , wherein the BGP peers all include a same segment routing global block (SRGB).
13. The method of claim 10 , wherein any of the BGP peers include a different segment routing global block (SRGB), and wherein the steps include
encoding the SRGB of a node performing the transmitting in an attribute.
14. The method of claim 10 , wherein the steps include
responsive to any BGP peers failing to support the packing BGP-SR updates, encoding each prefix in a separate BGP-SR update message.
15. The method of claim 10 , wherein the steps include
receiving a second BGP-SR update message from any of the BGP peers and determining an incoming label mapping (ILM) table based thereon.
16. The method of claim 10 , wherein the associated label information includes the label for a corresponding prefix.
17. The method of claim 10 , wherein the associated label information includes a label index for a corresponding prefix such that a label for the corresponding prefix is determined based on the label index and a segment routing global block (SRGB) start.
18. The method of claim 10 , wherein the plurality of prefixes are any of Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) addresses.
19. A non-transitory computer-readable medium comprising instructions that, when executed, cause a network element to perform steps of:
negotiating with border gateway protocol (BGP) peers for packing BGP-Segment Routing (BGP-SR) updates;
receiving a plurality of prefixes for a BGP-SR update message;
encoding the plurality of prefixes with associated label information in network layer reachability information (NLRI) of the BGP-SR update message, wherein the associated label information in the NLRI is utilized to derive a Segment identifier (SID) for a corresponding prefix of the plurality of prefixes; and
transmitting the BGP-SR update message to any of the BGP peers.
20. The non-transitory computer-readable medium of claim 19 , wherein the plurality of prefixes all share same attributes.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN2202211048700 | 2022-08-26 | ||
IN202211048700 | 2022-08-26 |
Publications (1)
Publication Number | Publication Date |
---|---|
US20240073135A1 true US20240073135A1 (en) | 2024-02-29 |
Family
ID=90001548
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/962,618 Pending US20240073135A1 (en) | 2022-08-26 | 2022-10-10 | BGP Segment Routing optimization by packing multiple prefixes in an update |
Country Status (1)
Country | Link |
---|---|
US (1) | US20240073135A1 (en) |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040090913A1 (en) * | 2002-11-12 | 2004-05-13 | Cisco Technology, Inc. | Routing system and method for synchronizing a routing system with peers after failover |
US20060233181A1 (en) * | 2005-04-13 | 2006-10-19 | Robert Raszuk | Method and apparatus for accelerating border gateway protocol convergence |
US20140226531A1 (en) * | 2013-02-14 | 2014-08-14 | Telefonaktiebolaget L M Ericsson (Publ) | Multicast support for EVPN-SPBM based on the mLDP signaling protocol |
US20180337852A1 (en) * | 2017-05-19 | 2018-11-22 | Cisco Technology, Inc. | Managing routing tables |
US20190305988A1 (en) * | 2018-03-30 | 2019-10-03 | Juniper Networks, Inc. | Aliasing behavior for traffic to multihomed sites in ethernet virtual private network (evpn) networks |
US10887225B1 (en) * | 2019-09-30 | 2021-01-05 | Juniper Networks, Inc. | Building a label sequence in Border Gateway Protocol (BGP) labeled network layer reachability information (NLRI) on next hop (NH) attribute change |
US20210029026A1 (en) * | 2019-07-24 | 2021-01-28 | Juniper Networks, Inc. | Using and processing per slice segment identifiers in a network employing segment routing |
US10917330B1 (en) * | 2019-01-28 | 2021-02-09 | Juniper Networks, Inc. | Minimizing or reducing traffic loss when an external border gateway protocol (eBGP) peer goes down |
US20210273827A1 (en) * | 2020-02-28 | 2021-09-02 | Juniper Networks, Inc. | Service-based transport classes for mapping services to tunnels |
US20220094601A1 (en) * | 2020-09-23 | 2022-03-24 | Nokia Solutions And Networks Oy | Targeted neighbor discovery for border gateway protocol |
US20220124186A1 (en) * | 2020-10-20 | 2022-04-21 | Nokia Solutions And Networks Oy | Supporting multiple transport options for border gateway protocol |
-
2022
- 2022-10-10 US US17/962,618 patent/US20240073135A1/en active Pending
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040090913A1 (en) * | 2002-11-12 | 2004-05-13 | Cisco Technology, Inc. | Routing system and method for synchronizing a routing system with peers after failover |
US20060233181A1 (en) * | 2005-04-13 | 2006-10-19 | Robert Raszuk | Method and apparatus for accelerating border gateway protocol convergence |
US20140226531A1 (en) * | 2013-02-14 | 2014-08-14 | Telefonaktiebolaget L M Ericsson (Publ) | Multicast support for EVPN-SPBM based on the mLDP signaling protocol |
US20180337852A1 (en) * | 2017-05-19 | 2018-11-22 | Cisco Technology, Inc. | Managing routing tables |
US20190305988A1 (en) * | 2018-03-30 | 2019-10-03 | Juniper Networks, Inc. | Aliasing behavior for traffic to multihomed sites in ethernet virtual private network (evpn) networks |
US10917330B1 (en) * | 2019-01-28 | 2021-02-09 | Juniper Networks, Inc. | Minimizing or reducing traffic loss when an external border gateway protocol (eBGP) peer goes down |
US20210029026A1 (en) * | 2019-07-24 | 2021-01-28 | Juniper Networks, Inc. | Using and processing per slice segment identifiers in a network employing segment routing |
US10887225B1 (en) * | 2019-09-30 | 2021-01-05 | Juniper Networks, Inc. | Building a label sequence in Border Gateway Protocol (BGP) labeled network layer reachability information (NLRI) on next hop (NH) attribute change |
US20210273827A1 (en) * | 2020-02-28 | 2021-09-02 | Juniper Networks, Inc. | Service-based transport classes for mapping services to tunnels |
US20220094601A1 (en) * | 2020-09-23 | 2022-03-24 | Nokia Solutions And Networks Oy | Targeted neighbor discovery for border gateway protocol |
US20220124186A1 (en) * | 2020-10-20 | 2022-04-21 | Nokia Solutions And Networks Oy | Supporting multiple transport options for border gateway protocol |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10541905B2 (en) | Automatic optimal route reflector root address assignment to route reflector clients and fast failover in a network environment | |
US10164838B2 (en) | Seamless segment routing | |
US9929946B2 (en) | Segment routing techniques | |
US10880203B2 (en) | Centralized segment routing dataplane based backup path validation | |
US9565160B2 (en) | Advertisement of adjacency segment identifiers | |
US8867334B2 (en) | Efficient convergence of grouped VPN prefixes | |
US9231851B2 (en) | System and method for computing point-to-point label switched path crossing multiple domains | |
US8589573B2 (en) | Technique for preventing routing loops by disseminating BGP attribute information in an OSPF-configured network | |
US7957306B2 (en) | Providing reachability information in a routing domain of an external destination address in a data communications network | |
US7522603B2 (en) | Technique for efficiently routing IP traffic on CE-CE paths across a provider network | |
US20220255853A1 (en) | Routing management method and apparatus, network device, and readable storage medium | |
US11362954B2 (en) | Tunneling inter-domain stateless internet protocol multicast packets | |
CN111837368B (en) | Advertising and programming of preferred path routing using interior gateway protocols | |
US11563697B2 (en) | Multiple label spaces in a label switched router | |
US20240073135A1 (en) | BGP Segment Routing optimization by packing multiple prefixes in an update | |
WO2022042610A1 (en) | Information processing method, network controller, node and computer-readable storage medium | |
WO2023173989A1 (en) | Forwarding table generation method and apparatus, and storage medium and electronic apparatus | |
CN116530065A (en) | Method, device and system for creating SR strategy by using path computation element protocol | |
Bowers et al. | Network Working Group Z. Li Internet-Draft N. Wu Intended status: Standards Track Q. Zhao Expires: January 5, 2015 Huawei Technologies A. Atlas |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |