[go: up one dir, main page]

WO2025099732A1 - Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique - Google Patents

Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique Download PDF

Info

Publication number
WO2025099732A1
WO2025099732A1 PCT/IN2023/051020 IN2023051020W WO2025099732A1 WO 2025099732 A1 WO2025099732 A1 WO 2025099732A1 IN 2023051020 W IN2023051020 W IN 2023051020W WO 2025099732 A1 WO2025099732 A1 WO 2025099732A1
Authority
WO
WIPO (PCT)
Prior art keywords
bgp
prefix
sid
nlri
label
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
Application number
PCT/IN2023/051020
Other languages
English (en)
Inventor
Adithya Narayan
Rajesh Kumar MEDURI
Kotesh Babu CHUNDU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to PCT/IN2023/051020 priority Critical patent/WO2025099732A1/fr
Publication of WO2025099732A1 publication Critical patent/WO2025099732A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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/02—Topology update or discovery
    • H04L45/033—Topology update or discovery by updating distance vector protocols
    • 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H04L45/507—Label distribution

Definitions

  • Embodiments of the invention relate to the field of networking; and more specifically, to including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes within a single BGP update message.
  • BGP border gateway protocol
  • NLRI network layer reachability information
  • BGP border gateway protocol
  • prefix-SID BGP prefix segment identifier
  • NLRI Network Layer Reachability Information
  • MPLS globally unique Multiprotocol Label Switching
  • the proposed extensions include the format of the BGP prefix-SID attribute, which for a given prefix contains the following Type-Length- Values (TLVs): (1) Label index TLV, and (2) originator Segment Routing Global Block (SRGB) TLV.
  • TLVs Type-Length- Values
  • Label index TLV contains the assigned, for a given prefix, an MPLS label index that will be unique across the segment routing domain.
  • Originator SRGB TLV contains the label index range for an originator node.
  • Label index TLV is a mandatory TLV and originator SRGB TLV is an optional TLV per RFC 8669.
  • each BGP prefix which is advertised under Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) labeled unicast Address Family (AF), will have a unique label index assigned on the originator node (unique within the corresponding SRGB range).
  • IPv4 Internet Protocol Version 4
  • IPv6 Internet Protocol Version 6
  • AF Internet Protocol Version 6
  • a BGP update message can carry only one BGP NLRI prefix with a BGP prefix-SID attribute thereby removing the advantage of packing multiple NLRI prefixes with the same BGP path attribute set.
  • Embodiments include methods, network device, storage medium, and computer program for including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes within a single BGP update message.
  • BGP border gateway protocol
  • a method is to be implemented by a network device to operate as a border gateway protocol (BGP) node, comprising: determining (402) that a plurality of BGP Network Layer Reachability Information (NLRI) prefixes with different BGP prefix segment identifier (prefix-SID) attributes is in need of being advertised to one or more BGP peer nodes, and transmitting (404) a single BGP update message to the one or more BGP peer nodes based on the determination, wherein the single BGP update message includes: a label index TLV (Type Length and Value) indicating that the label index TLV has been repurposed, an originator Segment Routing Global Block (SRGB) TLV indicating a SRGB range, and a NLRI portion indicating a plurality of labels
  • Embodiments include network devices for including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes within a single BGP update message.
  • a network device is to operate as a border gateway protocol (BGP) node, comprising a processor (612, 642) and non-transitory machine-readable storage medium (618, 648) that provides instructions that, when executed by the processor (612, 642), are capable of causing the processor (612, 642) to perform: determining (402) that a plurality of BGP Network Layer Reachability Information (NLRI) prefixes with different BGP prefix segment identifier (prefix-SID) attributes is in need of being advertised to one or more BGP peer nodes, and transmitting (404) a single BGP update message to the one or more BGP peer nodes based on the determination, wherein the single BGP update message includes: a label index TLV (Type Length and Value) indicating that the label index TLV has been repurposed, an originator
  • TLV Type
  • Embodiments include machine-readable storage media for including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes within a single BGP update message.
  • BGP border gateway protocol
  • NLRI network layer reachability information
  • a machine-readable storage medium provides instructions that, when executed by a processor, are capable of causing the processor to perform: determining (402) that a plurality of BGP Network Layer Reachability Information (NLRI) prefixes with different BGP prefix segment identifier (prefix-SID) attributes is in need of being advertised to one or more BGP peer nodes, and transmitting (404) a single BGP update message to the one or more BGP peer nodes based on the determination, wherein the single BGP update message includes: a label index TLV (Type Length and Value) indicating that the label index TLV has been repurposed, an originator Segment Routing Global Block (SRGB) TLV indicating a SRGB range, and a NLRI portion indicating a plurality
  • multiple NLRI prefixes with a BGP Prefix-SID attribute may be included in a single BGP update message, and such aggregation reduces the number of BGP update messages exchanged between BGP peers, and thus alleviating control traffic in a network, and reducing processing resources needed for processing the BGP update messages in the network.
  • Figure 1 illustrates operations of Border Gateway Protocol (BGP) update messages within a telecommunication network per some embodiments.
  • BGP Border Gateway Protocol
  • Figures 2A-2B illustrate operations of the packed BGP update messages in IPv4 per some embodiments.
  • Figures 3A-3B illustrate operations of the packed BGP update messages in IPv6 per some embodiments.
  • Figure 4 illustrates captured information in a BGP update message with multiple BGP prefix SID attributes per some embodiments.
  • FIG. 5 is a flow diagram illustrating operations including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes with a single BGP update message per some embodiments.
  • BGP border gateway protocol
  • NLRI network layer reachability information
  • Figure 6A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.
  • Figure 6B illustrates an exemplary way to implement a special-purpose network device according to some embodiments of the invention.
  • Figure 6C illustrates various exemplary ways in which virtual network elements (VNEs) may be coupled according to some embodiments of the invention.
  • VNEs virtual network elements
  • Figure 6D illustrates a network with a single network element (NE) on each of the NDs, and within this straightforward approach contrasts a traditional distributed approach (commonly used by traditional routers) with a centralized approach for maintaining reachability and forwarding information (also called network control), according to some embodiments of the invention.
  • NE network element
  • Figure 6E illustrates the simple case of where each of the NDs implements a single NE, but a centralized control plane has abstracted multiple of the NEs in different NDs into (to represent) a single NE in one of the virtual network(s), according to some embodiments of the invention.
  • Figure 6F illustrates a case where multiple VNEs are implemented on different NDs and are coupled to each other, and where a centralized control plane has abstracted these multiple VNEs such that they appear as a single VNE within one of the virtual networks, according to some embodiments of the invention.
  • Figure 7 illustrates an example of a communication system 700 per some embodiments.
  • Border Gateway Protocol is an inter- Autonomous System (AS) routing protocol.
  • AS inter- Autonomous System
  • the primary function of a BGP node is to exchange network reachability information with other peer BGP nodes.
  • This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.
  • a BGP node is also referred to as a BGP speaker, a BGP speaking system (or BGP system), a BGP router/route reflector/route server, or a similar term; and another BGP node that communicates with the BGP node is referred to as a peer BGP node/speaker/system (or a peer BGP), a neighbor/neighboring BGP node, a BGP partner, or a similar term.
  • the BGP messages formats are defined in standards such as Request for Comments (RFC) 4271 of the Internet Engineering Task Force (IETF), entitled “A Border Gateway Protocol 4 (BGP-4)” and dated January 2006.
  • the BGP message formats as discussed in RFC 4271 define (1) various base path attributes like (e.g., weight, origin, AS path) and (2) the rules for packing multiple NLRI messages into one BGP update message. If the BGP path attribute set is the same for multiple Network Layer Reachability Information (NLRI) prefixes, they are eligible to be packed into one BGP update message. This packing helps to reduce the number of BGP update messages (containing multiple NLRI prefixes with the same path attribute set) between BGP peers. Note that the terms of NLRIs, NLRI/prcfixcs, and NLRI prefixes are used interchangeably herein.
  • a variety of BGP messages are defined in RFC 4271, including (1) OPEN, which is sent by a BGP node to initiate a BGP session and includes information about the sender's BGP capabilities and parameters; (2) UPDATE, which is used to advertise routing information (prefixes) to BGP neighbors; (3) NOTIFICATION, which is used to report errors and terminate the BGP session when a problem occurs, and it contains a Code field and a Subcode field to indicate the type and specific nature of the error; (4) KEEPALIVE, which is used to maintain a BGP session and ensure that the connection between peer BGP nodes is still alive, and it is sent periodically as a form of "heartbeat" to keep the session active; and (5) ROUTEREFRESH, which is used to request the re-advertisement of BGP routes, and is typically used when there is a change in the BGP policy and one refers to refresh the routes without tearing down the BGP session.
  • OPEN which is sent by a BGP node to initiate a
  • a BGP UPDATE message can advertise, at most, one set of path attributes, but multiple destinations, provided that the destinations share these attributes. All path attributes contained in a given UPDATE message apply to all destinations carried in the NLRI field of the UPDATE message.
  • An UPDATE message can list multiple routes that are to be withdrawn from service. Each such route is identified by its destination (expressed as an IP prefix), which unambiguously identifies the route in the context of the BGP peer - BGP peer connection to which it has been previously advertised.
  • An UPDATE message might advertise only routes that are to be withdrawn from service, in which case the message will not include path attributes or Network Layer Reachability Information (NLRI). Conversely, it may advertise only a feasible route, in which case the WITHDRAWN ROUTES field need not be present.
  • 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). Each SID represents a topological or servicebased instruction. Per-flow state is maintained only on the ingress node of the SR domain.
  • 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.
  • 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 be comprised of a single 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.
  • SR segment routing
  • MPLS Multiprotocol Label Switching
  • the SID consists of a label, according to standards such as RFC 8660, entitled “Segment Routing with the MPLS Data Plane” and dated December 2019. Note that the terms of label and MPLS label are used interchangeably herein.
  • a BGP Prefix Segment is a BGP prefix with a prefix- SID attached.
  • a BGP prefix- SID is always a global SID within the SR domain and identifies an instruction to forward the packet over the best path computed by BGP to the related prefix, according to standards such as RFC 8402, entitled “Segment Routing Architecture” and dated July 2018.
  • the BGP prefix- SID is the identifier of the BGP Prefix Segment.
  • RFC 8669 proposes the BGP extensions to signal the BGP prefix-SID. Specifically, it 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 multi-protocol BGP IPv4/IPv6 labeled unicast.
  • a BGP prefix-SID will be global, across ASes when the interconnected ASes are part of the same SR domain.
  • ASBRs Autonomous system border routers
  • the BGP prefix-SID attribute is defined to be a set of elements encoded as TLV tuples (a set of TLVs).
  • the BGP prefix-SID attribute includes a mandatory label index TLV and an optional SRGB TLV as discussed above.
  • a BGP UPDATE message can advertise, at most, one set of path attributes, but multiple destinations, provided that the destinations share these attributes. Yet when a BGP prefix-SID attribute is encoded in the UPDATE message, the BGP prefix-SID can carry only a single NLRI prefix, as the prefix-SID attribute differs for each prefix, reducing the ability to pack BGP advertisements. Thus, the BGP UPDATE message in the existing approaches can carry a single prefix-SID attribute only.
  • Embodiments herein disclose a BGP update message, which may be implemented as an extension to the BGP UPDATE message per RFC 4271 or another BGP update message format that advertises routing information (prefixes) to BGP neighbors, and that contains one or more proprietary extensions to the BGP UPDATE message as defined per RFC 4271.
  • the embodiments move the variable part of the BGP prefix-SID in a BGP update message to the NLRI specific portion, which carries the label information, and keep the common prefix-SID information of all the NLRI prefixes belonging to a given SR domain (with the same SRGB range) in the BGP prefix SID path attribute of the update message.
  • FIG. 1 illustrates operations of Border Gateway Protocol (BGP) update messages within a telecommunication network per some embodiments.
  • Network 100 includes two autonomous systems (AS), AS 102 and AS 104.
  • An AS is a collection of networks and network devices under the control of a single organization that presents a common routing policy.
  • the AS may be assigned a unique Autonomous System Number (ASN) by the regional internet registries (RIRs) or the Internet Assigned Numbers Authority (IANA), and ASNs are used to identify and differentiate between different ASes.
  • ASN Autonomous System Number
  • RIRs regional internet registries
  • IANA Internet Assigned Numbers Authority
  • a BGP node is a network device that implements BGP protocols. As shown, each of AS 102 and AS 104 includes three BGP nodes, BGP nodes 110 to 114 and BGP nodes 116 to 119, respectively.
  • BGP update messages may be transmitted in network 100, and it may be transmitted within an autonomous system or between autonomous systems.
  • BGP update message 152 may be transmitted within AS 102
  • BGP update message 150 may be transmitted between AS 102 and AS 104. That is, the BGP update message discussed herein may be an intra-AS BGP (iBGP) message or inter-AS BGP (eBGP) message.
  • a BGP update message may be triggered in a variety of scenarios.
  • the BGP update message may be triggered upon (1) that a BGP node learns about a new route (prefix) or withdrawal of an existing route that the BGP node wants to advertise to its BGP peers, (2) that a path attribute changes, (3) that next-hop IP address associated with a BGP route changes, (4) that aggregation/de-aggregation of multiple prefixes, (5) that a (local) BGP policy (route preference, filtering, or route modification) on a route change, and (6) that a route suppression is needed to minimize the impact of unstable routes.
  • Embodiments of the invention are not limited to a particular scenario for which a BGP update message needs to be advertised.
  • the BGP update message used in network 100 follows the BGP update message format 120. While bit lengths for the fields as shown are defined in RFC 4271, alternative embodiments may have different bit lengths for these fields.
  • the BGP update message format 120 includes a withdrawn route length field 122.
  • the withdrawn route length field 122 indicates the total length of the Withdrawn Routes field in octets. Its value allows the length of the Network Layer Reachability Information field to be determined. A value of 0 indicates that no routes are being withdrawn from service, and that the withdrawn route field 124 is not present in the BGP update message.
  • the withdrawn route field 124 contains a list of IP address prefixes for the routes that are being withdrawn from service.
  • Each IP address prefix may be encoded as a 2-tuple of the form ⁇ length, prefix> in some embodiments, where the length field indicates the length in bits of the IP address prefix. A length of zero indicates a prefix that matches all IP addresses (with prefix, itself, of zero octets).
  • the prefix field contains an IP address prefix, followed by the minimum number of trailing bits needed to make the end of the field fall on an octet boundary.
  • the BGP update message format 120 includes a total path attribute length field 126 that indicates the total length of Path Attributes field (in octets) included in the BGP update message. Its value allows the length of a Network Layer Reachability Information (NLRI) field 130 to be determined. A value of 0 indicates that neither the Path Attributes field 128 nor the NLRI field 130 is present in the BGP update message.
  • the BGP update message format 120 further includes a Path Attributes field 128. In some embodiments, a variable-length sequence of path attributes is present in the BGP update message, except when the BGP update message carries only the withdrawn routes. Each path attribute within the Path Attributes field 128 may be a triple ⁇ attribute type, attribute length, attribute value> of variable length.
  • the BGP update message format 120 additionally includes the NLRI field 130, which contains a list of IP address prefixes.
  • the reachability information may be encoded as one or more 2-tuples of the form ⁇ length, prefix>, where the length field indicates the length in bits of the IP address prefix. A length of zero indicates a prefix that matches all IP addresses (with prefix, itself, of zero octets).
  • the prefix field contains an IP address prefix, followed by the minimum number of trailing bits needed to make the end of the field fall on an octet boundary.
  • the Path Attributes field 128 may pack multiple NLRI prefixes, including a BGP Prefix-SID attribute that is an optional, transitive BGP path attribute in the BGP update message.
  • the attribute type code 40 has been assigned by IANA for it.
  • the BGP Prefix-SID attribute is defined to be a set of elements encoded as a set of TLVs. All BGP Prefix-SID attribute TLVs will start with a 1 -octet type and a 2-octet length.
  • two TLVs are defined for the BGP Prefix-SID attribute in the path attribute field: (1) a mandatory label index TLV and (2) an optional SRGB TLV.
  • the label index TLV is used to carry information about the label stack associated with a particular prefix or segment in an SR domain, while the SRGB TLV is used to carry information about Segment Routing Global Block (SRGB) for the BGP node that originated the TLV.
  • SRGB Segment Routing Global Block
  • the BGP update message can carry only one BGP NLRI prefix with BGP prefix-SID attribute based on the existing path attribute field, where the path attribute includes the mandatory label Index TLV carrying the label index of a given NLRI prefix. Since this label index for each NLRI prefix is different, the BGP path attribute set differs for each NLRI prefix. Yet the actual label, which can be computed from the label index and configured though local SRGB, is also present in the corresponding MPLS field within the NLRI information. Because the actual label in the SRGB TLV may be derived from the index indicated in the mandatory label index TLV, the SRGB TLV is optional per RFC 8669.
  • the label index TLV is thus no longer required to indicate a different label for a different NLRI prefix, since the different label indices of multiple NLRI prefixes may be derived by the same mandatory SRGB TLV and the different actual labels from the MPLS field within the NLRI information.
  • the label index TLV is thus repurposed and the SRGB TLV is made mandatory as shown for the BGP prefix attribute 128M, which is to be included in path attributes 128. Instead of indicating the label index of a NLRI prefix, the label index TLV provides a repurposing indication to indicate that the label index TLV no longer provides a label index.
  • a label index TLV with a repurposing indication is shown at reference 132 per some embodiments.
  • the label index TLV 132 follows the format of the label index TLV of RFC 8669, and includes a type field indicating the type of the TLV, a length field of the length of the TLV, a flags field (e.g., to set a variety of flags regarding the label index TLV or the attributes of the advertised SID), and a label index field (e.g., to indicate a label).
  • the flags field and the label index field are 16 and 32 bits, respectively.
  • the repurposing indication may be provided by the flags field, the label index field, or a combination of both.
  • the repurposing indication may be set using (1) one or more bits in the flags field, (2) a special value indicated by the label index field such as all zeros, all ones, or another bit pattern that is outside of the label index value range, or a combination of (1) and (2).
  • a BGP node may pack multiple NLRI prefixes with different prefix - SID attributes into a single BGP update message.
  • a receiving BGP node receives the BGP update message, and identifies the repurposing indication, the receiving BGP node will derive the label indexes of the multiple NLRI prefixes from SRGB range information and the labels of the multiple NLRI prefixes.
  • the capability of packing multiple NLRI prefixes in a single BGP update message may be enabled or disabled, e.g., through BGP configuration.
  • the configuration may be performed through a management interface.
  • the management interface may be one or more of a Command Line Interface (CLI), a web-based interface, an Application Programming Interface (API) based interface, and a graphical user interface (GUI).
  • CLI Command Line Interface
  • API Application Programming Interface
  • GUI graphical user interface
  • a single BGP update message in embodiments of the disclosure may pack multiple BGP NLRI prefixes, indicating a common prefix-SID attribute.
  • the single BGP update message as transmitted and processed reduces the number of BGP update messages exchanged between BGP peers. Such reduction alleviates control traffic in network 100, as multiple BGP update messages would be necessary to promulgate the same information update without these embodiments.
  • the packing of the multiple BGP NLRI prefixes within the single BGP update message may reduce processing resources needed in network 100 (e.g., central processing units (CPUs) or graphics processing units (GPUs)).
  • Figures 2A-2B illustrate operations of the packed BGP update messages in IPv4 per some embodiments.
  • Figure 2A illustrates path attributes 228 based on existing approaches.
  • Path attributes 228 include regular path attributes such as weight and origin at reference 212; BGP prefix-SID attribute 214, where label index TLV 222 is mandatory and SRGB TLV 224 is optional; and multi-protocol (MP) reach NLRI field 216.
  • MP multi-protocol
  • the MP reach NLRI field 216 includes the Address Family Identifier (AFI) (e.g., to specify the network layer protocol associated with the NLRI), the Subsequent Address Family Identifier (SAFI) (e.g., to refine the NLRI information by specifying additional characteristics of the routing information), and next hop information at reference 232, and the prefix length, and the label at reference 234.
  • AFI Address Family Identifier
  • SAFI Subsequent Address Family Identifier
  • Path attributes 228A and 228B are shown, each for one BGP update message.
  • Path attributes 228 A include a label index A of 100 at reference 222A and the local SRGB range of 16000 to 17000 at reference 224A. The SRGB range thus has a range base value of 16000 and the maximum value of 17000.
  • the prefix is (2.2.2.2) and label A is 16100 as shown at reference 234A.
  • Path attributes 228B include a label index B of 101 at reference 222B, and prefix (22.22.22.22) and label B of 16101 at reference 234B. Due to the difference label index values of 100 and 101, the path attributes 228A and 228B cannot be included in a single BGP update message in the existing approaches.
  • Figure 2B illustrates the packing and unpacking of a single BGP update message per some embodiments.
  • Reference 290 shows the packing of multiple NLRI prefixes in a single BGP update message as transmitted, where the path attributes 228M is similar to path attributes 228 A and 228B with several differences.
  • the label index 222M has a repurposing indication (RI), and the repurposing indication may be indicated by one or more flag bits and/or a special value such as all zero, all ones, or another bit pattern as discussed herein.
  • the repurposing indication is shown as flag/0 as examples.
  • MP reach NLRI 216M now includes the two sets of prefixes and labels that were included in two separated MP reach NLRI 216A and 216B.
  • the packed path attributes 228B are then included in a single BGP update message, which is to advertise to one or more BGP peer nodes in the corresponding network.
  • a receiving BGP peer node upon receiving the BGP update message, may derive multiple label indices from the multiple prefix-SID attributes included in the BGP update message at reference 292.
  • the receiving BGP peer node determines that the label index TLV in the BGP update message includes a repurposing indication, instead of an index value, based on which, the receiving BGP peer node derives index values of the prefix-SID attributes from the labels in MP reach NLRI 216M.
  • a label index may be derived from the SRGB range and a corresponding label in MP reach NLRI 216M.
  • the label index is derived by offsetting a SRGB base of the SRGB range from the corresponding label within the plurality of labels through subtraction.
  • the label value is 16100 and SRGB base is 16000, the label index for the prefix (2.2.2.2) is thus 100.
  • the label value is 16101 and SRGB base is 16000, the label index for the prefix (22.22.22.22) is thus 101.
  • Figures 3A-3B illustrate operations of the packed BGP update messages in IPv6 per some embodiments. The operations are based on IPv6, with different IP address lengths and formats, which are shown at reference 334, 334A-B, and 334M. These figures are otherwise similar to the corresponding Figures 2A-2B.
  • Figure 4 illustrates captured information in a BGP update message with multiple BGP prefix SID attributes per some embodiments.
  • the captured information in the BGP update message shows path attributes including a BGP prefix-SID that contains (1) a label index TLV with a repurposing indication (RI) and (2) an originator SRGB TLV at 432. While the originator SRGB TLV is not expanded, the label index TLV is, and it includes label index flags indicating 0x0001 and label index value indicating 0. Either (1) the label index flags or (2) the label index value or a combination of (1) the label index flags and (2) the label index value may be the repurposing indication.
  • RI repurposing indication
  • MP reach NLRI 416 indicates three labels for the IPv4 prefixes, 16100, 16101, and 16102. From the labels and the base SRGB base of the originator SRGB range (e.g., 16000 as shown in Figures 2 to 3), the label indices can be deduced to be 100, 101, and 102.
  • Figure 5 is a flow diagram illustrating operations including multiple border gateway protocol (BGP) network layer reachability information (NLRI) prefixes with a single BGP update message per some embodiments.
  • the operations of method 500 may be implemented in a network device (see Figures 6A to 6F) to operate as a BGP node thus implementing BGP protocols.
  • BGP border gateway protocol
  • NLRI network layer reachability information
  • the operations of method 500 may be implemented in a network device (see Figures 6A to 6F) to operate as a BGP node thus implementing BGP protocols.
  • NLRI BGP Network Layer Reachability Information
  • prefix-SID BGP prefix segment identifier
  • a single BGP update message is transmitted to the one or more BGP peer nodes based on the determination, where the single BGP update message includes: a label index TLV (Type Length and Value) indicating that the label index TLV has been repurposed, an originator Segment Routing Global Block (SRGB) TLV indicating a SRGB range, and a NLRI portion indicating a plurality of labels, through which label indices of the different BGP prefix-SID attributes are derived.
  • TLV Type Length and Value
  • SRGB originator Segment Routing Global Block
  • a label index of a BGP prefix-SID attribute within the different BGP prefix-SID attributes is derived from the SRGB range and a corresponding label within the plurality of labels, the label being indicated in the NLRI portion for the BGP prefix- SID attribute.
  • the label index is derived by offsetting a SRGB base of the SRGB range from the corresponding label within the plurality of labels through subtraction. The derivation is discussed, and examples are given in Figures 2 to 4.
  • each of the plurality of labels comprises a Multiprotocol Label Switching (MPLS) label.
  • MPLS Multiprotocol Label Switching
  • the label index TLV, the SRGB TLV, and the NLRI portion are included in a path attribute field of the single BGP update message.
  • the path attributes included in the path attribute fields are shown in Figures 2 to 4.
  • the label index TLV includes a special value to indicate that more than one prefix-SID attribute is included in the single BGP update messages.
  • the special value may be one or more of all zeros, all ones, or another bit pattern that is outside of the label index value range.
  • the label index TLV includes a flag to indicate that a plurality of BGP NLRI prefixes with different BGP prefix-SID attributes is included in the single BGP update messages.
  • the flag may be one or more bits of the flags field as shown in the label index TLV 132.
  • a capability of including the plurality of NLRI prefixes with different BGP prefix-SID attributes within the single BGP update message is to be enabled and disabled through a BGP configuration instruction.
  • the BGP configuration instruction is issued through one or more of a Command Line Interface (CLI), a web-based interface, an Application Programming Interface (API) based interface, and a graphical user interface (GUI) based interface.
  • CLI Command Line Interface
  • API Application Programming Interface
  • GUI graphical user interface
  • each of the plurality of BGP NLRI prefixes with different prefix-SID attributes corresponds to an Internet Protocol version 4 (IPv4) prefix or an IP version 6 (IPv6) prefix.
  • IPv4 Internet Protocol version 4
  • IPv6 IP version 6
  • multiple NLRI prefixes with a BGP Prefix-SID attribute may be included in a single BGP update message, and such aggregation reduces the number of BGP update messages exchanged between BGP peers, and thus alleviating control traffic in a network, and reducing processing resources needed for processing the BGP update messages in the network.
  • a network device is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices).
  • Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video).
  • Figure 6A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.
  • Figure 6A shows NDs 600A-H, and their connectivity by way of lines between 600A-600B, 600B-600C, 600C-600D, 600D-600E, 600E-600F, 600F-600G, and 600A-600G, as well as between 600H and each of 600A, 600C, 600D, and 600G.
  • These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link).
  • NDs 600A, 600E, and 600F An additional line extending from NDs 600A, 600E, and 600F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).
  • Two of the exemplary ND implementations in Figure 6A are: 1) a special-purpose network device 602 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general -purpose network device 604 that uses common off-the-shelf (COTS) processors and a standard OS.
  • ASICs application-specific integrated-circuits
  • OS special-purpose operating system
  • COTS common off-the-shelf
  • the special-purpose network device 602 includes networking hardware 610 comprising a set of one or more processor(s) 612, forwarding resource(s) 614 (which typically include one or more ASICs and/or network processors), and physical network interfaces (NIs) 616 (through which network connections are made, such as those shown by the connectivity between NDs 600A-H), as well as non-transitory machine readable storage media 618 having stored therein networking software 620.
  • the networking software 620 may be executed by the networking hardware 610 to instantiate a set of one or more networking software instance(s) 622.
  • Each of the networking software instance(s) 622, and that part of the networking hardware 610 that executes that network software instance form a separate virtual network element 630A-R.
  • Each of the virtual network element(s) (VNEs) 630A-R includes a control communication and configuration module 632A-R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 634A-R, such that a given virtual network element (e.g., 630A) includes the control communication and configuration module (e.g., 632A), a set of one or more forwarding table(s) (e.g., 634A), and that portion of the networking hardware 610 that executes the virtual network element (e.g., 630A).
  • networking software 620 includes a BGP message manager 625 that implements operations to generate, transmit, receive, and process the BGP update messages discussed herein relating to Figures 1 to 5.
  • the special-purpose network device 602 is often physically and/or logically considered to include: 1) a ND control plane 624 (sometimes referred to as a control plane) comprising the processor(s) 612 that execute the control communication and configuration module(s) 632A-R; and 2) a ND forwarding plane 626 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 614 that utilize the forwarding table(s) 634A-R and the physical NIs 616.
  • a ND control plane 624 (sometimes referred to as a control plane) comprising the processor(s) 612 that execute the control communication and configuration module(s) 632A-R
  • a ND forwarding plane 626 sometimes referred to as a forwarding plane, a data plane, or a media plane
  • the forwarding resource(s) 614 that utilize the forwarding table(s) 634A-R and the physical NIs 616.
  • the ND control plane 624 (the processor(s) 612 executing the control communication and configuration module(s) 632A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 634A-R, and the ND forwarding plane 626 is responsible for receiving that data on the physical NIs 616 and forwarding that data out the appropriate ones of the physical NIs 616 based on the forwarding table(s) 634A-R.
  • data e.g., packets
  • the ND forwarding plane 626 is responsible for receiving that data on the physical NIs 616 and forwarding that data out the appropriate ones of the physical NIs 616 based on the forwarding table(s) 634A-R.
  • Figure 6B illustrates an exemplary way to implement the special-purpose network device 602 according to some embodiments of the invention.
  • Figure 6B shows a specialpurpose network device including cards 638 (typically hot pluggable). While in some embodiments the cards 638 are of two types (one or more that operate as the ND forwarding plane 626 (sometimes called line cards), and one or more that operate to implement the ND control plane 624 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and/or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card).
  • additional card types e.g., one additional type of card is called a service card, resource card, or multi-application card.
  • a service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)).
  • Layer 4 to Layer 7 services e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)
  • GPRS General Pack
  • the general-purpose network device 604 includes hardware 640 comprising a set of one or more processor(s) 642 (which are often COTS processors) and physical NIs 646, as well as non-transitory machine -readable storage media 648 having stored therein software 650.
  • the processor(s) 642 execute the software 650 to instantiate one or more sets of one or more applications 664A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization.
  • the virtualization layer 654 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 662A-R called software containers that may each be used to execute one (or more) of the sets of applications 664A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes.
  • the multiple software containers also called virtualization engines, virtual private servers, or jails
  • user spaces typically a virtual memory space
  • the virtualization layer 654 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 664A-R is run on top of a guest operating system within an instance 662A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and/or application may be aware of the presence of virtualization for optimization purposes.
  • a hypervisor sometimes referred to as a virtual machine monitor (VMM)
  • VMM virtual machine monitor
  • one, some or all of the applications are implemented as unikemel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers/libraries of OS services) that provide the particular OS services needed by the application.
  • libraries e.g., from a library operating system (LibOS) including drivers/libraries of OS services
  • networking software 650 includes a BGP message manager 655 that implements operations to generate, transmit, receive, and process the BGP update messages discussed herein relating to Figures 1 to 5.
  • the instantiation of the one or more sets of one or more applications 664A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 652.
  • the virtual network element(s) 660A-R perform similar functionality to the virtual network element(s) 630A-R - e.g., similar to the control communication and configuration module(s) 632A and forwarding table(s) 634A (this virtualization of the hardware 640 is sometimes referred to as network function virtualization (NFV)).
  • NFV network function virtualization
  • CPE customer premise equipment
  • each instance 662A-R corresponding to one VNE 660A-R
  • alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 662A-R to VNEs also apply to embodiments where such a finer level of granularity and/or unikernels are used.
  • the virtualization layer 654 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 662A-R and the physical NI(s) 646, as well as optionally between the instances 662A-R; in addition, this virtual switch may enforce network isolation between the VNEs 660A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).
  • VLANs virtual local area networks
  • the third exemplary ND implementation in Figure 6A is a hybrid network device 606, which includes both custom ASICs/special-purpose OS and COTS processors/standard OS in a single ND or a single card within an ND.
  • a platform VM i.e., a VM that that implements the functionality of the special-purpose network device 602 could provide for para- virtualization to the networking hardware present in the hybrid network device 606.
  • NE network element
  • each of the VNEs receives data on the physical NIs (e.g., 616, 646) and forwards that data out the appropriate ones of the physical NIs (e.g., 616, 646).
  • a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where “source port” and “destination port” refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services code point (DSCP) values.
  • transport protocol e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services code point (DSCP) values.
  • UDP user datagram protocol
  • TCP Transmission Control Protocol
  • DSCP differentiated services code point
  • Figure 6C illustrates various exemplary ways in which VNEs may be coupled according to some embodiments of the invention.
  • Figure 6C shows VNEs 670A.1-670A.P (and optionally VNEs 670A.Q-670A.R) implemented in ND 600A and VNE 670H.1 in ND 600H.
  • VNEs 670A.1-P are separate from each other in the sense that they can receive packets from outside ND 600A and forward packets outside of ND 600A; VNE 670A.1 is coupled with VNE 670H.1, and thus they communicate packets between their respective NDs; VNE 670A.2-670A.3 may optionally forward packets between themselves without forwarding them outside of the ND 600A; and VNE 670A.P may optionally be the first in a chain of VNEs that includes VNE 670A.Q followed by VNE 670A.R (this is sometimes referred to as dynamic service chaining, where each of the VNEs in the series of VNEs provides a different service - e.g., one or more layer 4-7 network services). While Figure 6C illustrates various exemplary relationships between the VNEs, alternative embodiments may support other relationships (e.g., more/fewer VNEs, more/fewer dynamic service chains, multiple different dynamic service chains with some common VNEs and some different V
  • the NDs of Figure 6A may form part of the Internet or a private network; and other electronic devices (not shown; such as end user devices including workstations, laptops, netbooks, tablets, palm tops, mobile phones, smartphones, phablets, multimedia phones, Voice Over Internet Protocol (VOIP) phones, terminals, portable media players, GPS units, wearable devices, gaming systems, set-top boxes, Internet enabled household appliances) may be coupled to the network (directly or through other networks such as access networks) to communicate over the network (e.g., the Internet or virtual private networks (VPNs) overlaid on (e.g., tunneled through) the Internet) with each other (directly or through servers) and/or access content and/or services.
  • end user devices including workstations, laptops, netbooks, tablets, palm tops, mobile phones, smartphones, phablets, multimedia phones, Voice Over Internet Protocol (VOIP) phones, terminals, portable media players, GPS units, wearable devices, gaming systems, set-top boxes, Internet enabled household appliances
  • VOIP
  • Such content and/or services are typically provided by one or more servers (not shown) belonging to a service/content provider or one or more end user devices (not shown) participating in a peer-to-peer (P2P) service, and may include, for example, public webpages (e.g., free content, store fronts, search services), private webpages (e.g., usemame/password accessed webpages providing email services), and/or corporate networks over VPNs.
  • end user devices may be coupled (e.g., through customer premise equipment coupled to an access network (wired or wirelessly)) to edge NDs, which are coupled (e.g., through one or more core NDs) to other edge NDs, which are coupled to electronic devices acting as servers.
  • one or more of the electronic devices operating as the NDs in Figure 6A may also host one or more such servers (e.g., in the case of the general-purpose network device 604, one or more of the software instances 662A-R may operate as servers; the same would be true for the hybrid network device 606; in the case of the special-purpose network device 602, one or more such servers could also be run on a virtualization layer executed by the processor(s) 612); in which case the servers are said to be co-located with the VNEs of that ND.
  • the servers are said to be co-located with the VNEs of that ND.
  • a virtual network is a logical abstraction of a physical network (such as that in Figure 6A) that provides network services (e.g., L2 and/or L3 services).
  • a virtual network can be implemented as an overlay network (sometimes referred to as a network virtualization overlay) that provides network services (e.g., layer 2 (L2, data link layer) and/or layer 3 (L3, network layer) services) over an underlay network (e.g., an L3 network, such as an Internet Protocol (IP) network that uses tunnels (e.g., generic routing encapsulation (GRE), layer 2 tunneling protocol (L2TP), IPSec) to create the overlay network).
  • IP Internet Protocol
  • a network virtualization edge sits at the edge of the underlay network and participates in implementing the network virtualization; the network-facing side of the NVE uses the underlay network to tunnel frames to and from other NVEs; the outward-facing side of the NVE sends and receives data to and from systems outside the network.
  • a virtual network instance is a specific instance of a virtual network on a NVE (e.g., a NE/VNE on an ND, a part of a NE/VNE on a ND where that NE/VNE is divided into multiple VNEs through emulation); one or more VNIs can be instantiated on an NVE (e.g., as different VNEs on an ND).
  • a virtual access point is a logical connection point on the NVE for connecting external systems to a virtual network; a VAP can be physical or virtual ports identified through logical interface identifiers (e.g., a VLAN ID).
  • Examples of network services include: 1) an Ethernet LAN emulation service (an Ethernet-based multipoint service similar to an Internet Engineering Task Force (IETF) Multiprotocol Label Switching (MPLS) or Ethernet VPN (EVPN) service) in which external systems are interconnected across the network by a LAN environment over the underlay network (e.g., an NVE provides separate L2 VNIs (virtual switching instances) for different such virtual networks, and L3 (e.g., IP/MPLS) tunneling encapsulation across the underlay network); and 2) a virtualized IP forwarding service (similar to IETF IP VPN (e.g., Border Gateway Protocol (BGP)/MPLS IP VPN) from a service definition perspective) in which external systems are interconnected across the network by an L3 environment over the underlay network (e.g., an NVE provides separate L3 VNIs (forwarding and routing instances) for different such virtual networks, and L3 (e.g., IP/MPLS) tunneling encapsulation across the underlay network)).
  • Network services may also include quality of service capabilities (e.g., traffic classification marking, traffic conditioning and scheduling), security capabilities (e.g., filters to protect customer premises from network - originated attacks, to avoid malformed route announcements), and management capabilities (e.g., full detection and processing).
  • quality of service capabilities e.g., traffic classification marking, traffic conditioning and scheduling
  • security capabilities e.g., filters to protect customer premises from network - originated attacks, to avoid malformed route announcements
  • management capabilities e.g., full detection and processing
  • FIG. 6D illustrates a network with a single network element on each of the NDs of Figure 6A, and within this straightforward approach contrasts a traditional distributed approach (commonly used by traditional routers) with a centralized approach for maintaining reachability and forwarding information (also called network control), according to some embodiments of the invention.
  • Figure 6D illustrates network elements (NEs) 670A-H with the same connectivity as the NDs 600A-H of Figure 6A.
  • Figure 6D illustrates that the distributed approach 672 distributes responsibility for generating the reachability and forwarding information across the NEs 670A-H; in other words, the process of neighbor discovery and topology discovery is distributed.
  • the control communication and configuration module(s) 632A-R of the ND control plane 624 typically include a reachability and forwarding information module to implement one or more routing protocols (e.g., an exterior gateway protocol such as Border Gateway Protocol (BGP), Interior Gateway Protocol(s) (IGP) (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Routing Information Protocol (RIP), Eabel Distribution Protocol (EDP), Resource Reservation Protocol (RSVP) (including RSVP-Traffic Engineering (TE): Extensions to RSVP for LSP Tunnels and Generalized Multi-Protocol Label Switching (GMPLS) Signaling RSVP-TE)) that communicate with other NEs to exchange routes, and then selects those routes based on one or more routing metrics.
  • Border Gateway Protocol BGP
  • IGP Interior Gateway Protocol
  • OSPF Open Shortest Path First
  • IS-IS Intermediate System to Intermediate System
  • RIP Routing Information Protocol
  • EDP Eabel Distribution Protocol
  • RSVP Resource Reservation Protocol
  • TE RSVP-Traffic Engineering
  • the NEs 670A-H e.g., the processor(s) 612 executing the control communication and configuration module(s) 632A- R
  • Routes and adjacencies are stored in one or more routing structures (e.g., Routing Information Base (RIB), Label Information Base (LIB), one or more adjacency structures) on the ND control plane 624.
  • routing structures e.g., Routing Information Base (RIB), Label Information Base (LIB), one or more adjacency structures
  • the ND control plane 624 programs the ND forwarding plane 626 with information (e.g., adjacency and route information) based on the routing structure(s). For example, the ND control plane 624 programs the adjacency and route information into one or more forwarding table(s) 634A-R (e.g., Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), and one or more adjacency structures) on the ND forwarding plane 626.
  • the ND can store one or more bridging tables that are used to forward data based on the layer 2 information in that data. While the above example uses the special-purpose network device 602, the same distributed approach 672 can be implemented on the general-purpose network device 604 and the hybrid network device 606.
  • FIG. 6D illustrates that a centralized approach 674 (also known as software defined networking (SDN)) that decouples the system that makes decisions about where traffic is sent from the underlying systems that forwards traffic to the selected destination.
  • the illustrated centralized approach 674 has the responsibility for the generation of reachability and forwarding information in a centralized control plane 676 (sometimes referred to as a SDN control module, controller, network controller, OpenFlow controller, SDN controller, control plane node, network virtualization authority, or management control entity), and thus the process of neighbor discovery and topology discovery is centralized.
  • a centralized control plane 676 sometimes referred to as a SDN control module, controller, network controller, OpenFlow controller, SDN controller, control plane node, network virtualization authority, or management control entity
  • the centralized control plane 676 has a south bound interface 682 with a data plane 680 (sometime referred to the infrastructure layer, network forwarding plane, or forwarding plane (which should not be confused with a ND forwarding plane)) that includes the NEs 670A-H (sometimes referred to as switches, forwarding elements, data plane elements, network nodes or nodes).
  • the centralized control plane 676 includes a network controller 678, which includes a centralized reachability and forwarding information module 679 that determines the reachability within the network and distributes the forwarding information to the NEs 670A-H of the data plane 680 over the south bound interface 682 (which may use the OpenFlow protocol).
  • the network intelligence is centralized in the centralized control plane 676 executing on electronic devices that are typically separate from the NDs.
  • each of the control communication and configuration module(s) 632A-R of the ND control plane 624 typically include a control agent that provides the VNE side of the south bound interface 682.
  • the ND control plane 624 (the processor(s) 612 executing the control communication and configuration module(s) 632A-R) performs its responsibility for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) through the control agent communicating with the centralized control plane 676 to receive the forwarding information (and in some cases, the reachability information) from the centralized reachability and forwarding information module 679 (it should be understood that in some embodiments of the invention, the control communication and configuration module(s) 632A-R, in addition to communicating with the centralized control plane 676, may also play some role in determining reachability and/or calculating forwarding information - albeit less so than in the case of a distributed approach; such embodiments are generally considered to fall under the centralized approach 674, but may also be considered a hybrid approach).
  • data e.g., packets
  • the control agent communicating with the centralized control plane 676 to receive the forwarding
  • the same centralized approach 674 can be implemented with the general-purpose network device 604 (e.g., each of the VNE 660A-R performs its responsibility for controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) by communicating with the centralized control plane 676 to receive the forwarding information (and in some cases, the reachability information) from the centralized reachability and forwarding information module 679; it should be understood that in some embodiments of the invention, the VNEs 660A-R, in addition to communicating with the centralized control plane 676, may also play some role in determining reachability and/or calculating forwarding information - albeit less so than in the case of a distributed approach) and the hybrid network device 606.
  • the general-purpose network device 604 e.g., each of the VNE 660A-R performs its responsibility for controlling how data (e.g., packets) is to be routed (e.g., the next
  • NFV is able to support SDN by providing an infrastructure upon which the SDN software can be run
  • NFV and SDN both aim to make use of commodity server hardware and physical switches.
  • FIG. 6D also shows that the centralized control plane 676 has a north bound interface 684 to an application layer 686, in which resides application(s) 688.
  • the centralized control plane 676 has the ability to form virtual networks 692 (sometimes referred to as a logical forwarding plane, network services, or overlay networks (with the NEs 670A-H of the data plane 680 being the underlay network)) for the application(s) 688.
  • virtual networks 692 sometimes referred to as a logical forwarding plane, network services, or overlay networks (with the NEs 670A-H of the data plane 680 being the underlay network)
  • the centralized control plane 676 maintains a global view of all NDs and configured NEs/VNEs, and it maps the virtual networks to the underlying NDs efficiently (including maintaining these mappings as the physical network changes either through hardware (ND, link, or ND component) failure, addition, or removal).
  • Figure 6D shows the distributed approach 672 separate from the centralized approach 674
  • the effort of network control may be distributed differently or the two combined in certain embodiments of the invention.
  • embodiments may generally use the centralized approach (SDN) 674, but have certain functions delegated to the NEs (e.g., the distributed approach may be used to implement one or more of fault monitoring, performance monitoring, protection switching, and primitives for neighbor and/or topology discovery); or 2) embodiments of the invention may perform neighbor discovery and topology discovery via both the centralized control plane and the distributed protocols, and the results compared to raise exceptions where they do not agree.
  • SDN centralized approach
  • Such embodiments are generally considered to fall under the centralized approach 674 but may also be considered a hybrid approach.
  • Figure 6D illustrates the simple case where each of the NDs 600A-H implements a single NE 670A-H
  • the network control approaches described with reference to Figure 6D also work for networks where one or more of the NDs 600A-H implement multiple VNEs (e.g., VNEs 630A-R, VNEs 660A-R, those in the hybrid network device 606).
  • the network controller 678 may also emulate the implementation of multiple VNEs in a single ND.
  • the network controller 678 may present the implementation of a VNE/NE in a single ND as multiple VNEs in the virtual networks 692 (all in the same one of the virtual network(s) 692, each in different ones of the virtual network(s) 692, or some combination).
  • the network controller 678 may cause an ND to implement a single VNE (a NE) in the underlay network, and then logically divide up the resources of that NE within the centralized control plane 676 to present different VNEs in the virtual network(s) 692 (where these different VNEs in the overlay networks are sharing the resources of the single VNE/NE implementation on the ND in the underlay network).
  • Figures 6E and 6F respectively illustrate exemplary abstractions of NEs and VNEs that the network controller 678 may present as part of different ones of the virtual networks 692.
  • Figure 6E illustrates the simple case of where each of the NDs 600A-H implements a single NE 670A-H (see Figure 6D), but the centralized control plane 676 has abstracted multiple of the NEs in different NDs (the NEs 670A-C and G-H) into (to represent) a single NE 6701 in one of the virtual network(s) 692 of Figure 6D, according to some embodiments of the invention.
  • Figure 6E shows that in this virtual network, the NE 6701 is coupled to NE 670D and 670F, which are both still coupled to NE 670E.
  • Figure 6F illustrates a case where multiple VNEs (VNE 670A.1 and VNE 670H.1) are implemented on different NDs (ND 600 A and ND 600H) and are coupled to each other, and where the centralized control plane 676 has abstracted these multiple VNEs such that they appear as a single VNE 670T within one of the virtual networks 692 of Figure 6D, according to some embodiments of the invention.
  • the abstraction of a NE or VNE can span multiple NDs.
  • FIG. 7 illustrates an example of a communication system 700 per some embodiments.
  • the communication system 700 includes a telecommunication network 702 that includes an access network 704, such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 708.
  • the access network 704 includes one or more access network nodes, such as network nodes 710A and 710B (one or more of which may be generally referred to as network nodes 710), or any other similar 3 rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points.
  • 3GPP 3 rd Generation Partnership Project
  • a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor.
  • network nodes include disaggregated implementations or portions thereof.
  • the telecommunication network 702 includes one or more Open-RAN (ORAN) network nodes.
  • ORAN Open-RAN
  • An ORAN network node is a node in the telecommunication network 702 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 702, including one or more network nodes 710 and/or core network nodes 708.
  • Each network node may be one of network element 670A-670E shown in Figure 6D.
  • Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification).
  • a near-real time control application e.g., xApp
  • rApp non-real time control application
  • the network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface.
  • an ORAN access node may be a logical node in a physical node.
  • an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized.
  • the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies.
  • the network nodes 710 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 712A, 712B, 712C, and 712D (one or more of which may be generally referred to as UEs 712) to the core network 706 over one or more wireless connections.
  • UE user equipment
  • Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors.
  • the communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.
  • the communication system 700 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.
  • the UEs 712 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 710 and other communication devices.
  • the network nodes 710 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 712 and/or with other network nodes or equipment in the telecommunication network 702 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 702.
  • the core network 706 connects the network nodes 710 to one or more hosts, such as host 716. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts.
  • the core network 706 includes one more core network nodes (e.g., core network node 708) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 708.
  • Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDE), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).
  • MSC Mobile Switching Center
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • SIDE Subscription Identifier De-concealing function
  • UDM Unified Data Management
  • SEPP Security Edge Protection Proxy
  • NEF Network Exposure Function
  • UPF User Plane Function
  • the host 716 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and/or the telecommunication network 702, and may be operated by the service provider or on behalf of the service provider.
  • the host 716 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.
  • the communication system 700 of Figure 7 enables connectivity between the UEs, network nodes, and hosts.
  • the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • the telecommunication network 702 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunication network 702 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 702. For example, the telecommunication network 702 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.
  • URLLC Ultra Reliable Low Latency Communication
  • eMBB Enhanced Mobile Broadband
  • mMTC Massive Machine Type Communication
  • the UEs 712 are configured to transmit and/or receive information without direct human interaction.
  • a UE may be designed to transmit information to the access network 704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 704.
  • a UE may be configured for operating in single- or multiple radio access technology (multi-RAT) or multi-standard mode.
  • multi-RAT radio access technology
  • a UE may operate with any one or combination of WiFi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR- DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).
  • MR- DC multi-radio dual connectivity
  • the hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 712C and/or 712D) and network nodes (e.g., network node 710B).
  • the hub 714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs.
  • the hub 714 may be a broadband router enabling access to the core network 706 for the UEs.
  • the hub 714 may be a controller that sends commands or instructions to one or more actuators in the UEs.
  • the hub 714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data.
  • the hub 714 may be a content source. For example, for a UE that is a virtual reality (VR) headset, display, loudspeaker or other media delivery device, the hub 714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 714 then provides to the UE either directly, after performing local processing, and/or after adding additional local content.
  • the hub 714 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.
  • the hub 714 may have a constant/persistent or intermittent connection to the network node 710b.
  • the hub 714 may also allow for a different communication scheme and/or schedule between the hub 714 and UEs (e.g., UE 712C and/or 712D), and between the hub 714 and the core network 706.
  • the hub 714 is connected to the core network 706 and/or one or more UEs via a wired connection.
  • the hub 714 may be configured to connect to a machine-to-machine (M2M) service provider over the access network 704 and/or to another UE over a direct connection.
  • M2M machine-to-machine
  • UEs may establish a wireless connection with the network nodes 710 while still connected via the hub 714 via a wired or wireless connection.
  • the hub 714 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 710B.
  • the hub 714 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 710B, but which is additionally capable of operating as a communication start and/or end point for certain data channels.
  • the network devices 602, 604, or 606 may implement network nodes 708, 710A-B, or host 717, which then performs operations discussed herein above relating to Figures 1 to 5.
  • references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” and so forth, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • Coupled is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other.
  • Connected is used to indicate the establishment of wireless or wireline communication between two or more elements that are coupled with each other.
  • a “set,” as used herein can refer to any whole number of items including one item.
  • An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as a computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine -readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical, or other form of propagated signals - such as carrier waves, infrared signals).
  • machine-readable media also called computer-readable media
  • machine -readable storage media e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory
  • machine-readable transmission media also called a carrier
  • carrier e.g., electrical, optical, radio, acoustical, or other form of propagated signals - such
  • an electronic device e.g., a computer
  • includes hardware and software such as a set of one or more processors (e.g., of which a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), other electronic circuitry, or a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data.
  • processors e.g., of which a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), other electronic circuitry, or a combination of one or more of the preceding
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when
  • Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices.
  • NI(s) physical network interface(s)
  • the set of physical NIs may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection.
  • a physical NI may comprise radio circuitry capable of (1) receiving data from other electronic devices over a wireless connection and/or (2) sending data out to other devices through a wireless connection.
  • This radio circuitry may include transmitter(s), receiver(s), and/or transceiver(s) suitable for radio frequency communication.
  • the radio circuitry may convert digital data into a radio signal having the proper parameters (e.g., frequency, timing, channel, bandwidth, and so forth).
  • the radio signal may then be transmitted through antennas to the appropriate recipient(s).
  • the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter.
  • NICs network interface controller
  • the NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate with wire through plugging in a cable to a physical port connected to an NIC.
  • One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.
  • module may refer to a circuit for performing the function specified.
  • the function specified may be performed by a circuit in combination with software such as by software executed by a general-purpose processor.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
  • the term unit may have conventional meaning in the field of electronics, electrical devices, and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Des modes de réalisation comprennent des procédés, un dispositif électronique, un support d'enregistrement et un programme informatique destinés à inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (NLRI) de protocole de passerelle frontière (BGP) dans un seul message de mise à jour de BGP. Dans un mode de réalisation, un procédé doit être mis en œuvre par un dispositif de réseau pour fonctionner en tant que nœud de protocole de passerelle frontière (BGP), comprenant : la détermination (402) qu'une pluralité de préfixes NLRI BGP avec différents attributs d'identifiant de segment de préfixe BGP (SID de préfixe) a besoin d'être annoncée à un ou plusieurs nœuds homologues de BGP, et la transmission (404) d'un message de mise à jour de BGP unique aux nœuds homologues de BGP sur la base de la détermination, le message de mise à jour de BGP unique comprenant : un indice d'étiquette TLV indiquant que l'indice d'étiquette TLV a été réutilisé, un TLV de bloc global de routage de segment (SRGB) d'expéditeur indiquant une plage SRGB, et une portion NLRI indiquant des étiquettes, à travers lesquelles des indices d'étiquette des différents attributs de SID de préfixe de BGP sont déduits.
PCT/IN2023/051020 2023-11-06 2023-11-06 Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique Pending WO2025099732A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IN2023/051020 WO2025099732A1 (fr) 2023-11-06 2023-11-06 Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2023/051020 WO2025099732A1 (fr) 2023-11-06 2023-11-06 Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique

Publications (1)

Publication Number Publication Date
WO2025099732A1 true WO2025099732A1 (fr) 2025-05-15

Family

ID=95695428

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2023/051020 Pending WO2025099732A1 (fr) 2023-11-06 2023-11-06 Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique

Country Status (1)

Country Link
WO (1) WO2025099732A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20210258249A1 (en) * 2020-02-18 2021-08-19 Juniper Networks, Inc. FLEXIBLE ALGORITHM AWARE BORDER GATEWAY PROTOCOL (BGP) PREFIX SEGMENT ROUTING IDENTIFIERS (SIDs)

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20210258249A1 (en) * 2020-02-18 2021-08-19 Juniper Networks, Inc. FLEXIBLE ALGORITHM AWARE BORDER GATEWAY PROTOCOL (BGP) PREFIX SEGMENT ROUTING IDENTIFIERS (SIDs)

Similar Documents

Publication Publication Date Title
US11438254B2 (en) Apparatus and method to trace packets in a packet processing pipeline of a software defined networking switch
US10225169B2 (en) Method and apparatus for autonomously relaying statistics to a network controller in a software-defined networking network
US9774504B2 (en) Route refresh mechanism for border gateway protocol link state
EP3878214B1 (fr) Dérivation locale du protocole de réseau identificateur-localisateur (ilnp)
RU2704714C1 (ru) Технологии для предоставления максимальной глубины идентификатора сегмента узла и/или линии связи, использующие ospf
US10404573B2 (en) Efficient method to aggregate changes and to produce border gateway protocol link-state (BGP-LS) content from intermediate system to intermediate system (IS-IS) link-state database
US12317179B2 (en) Dynamic access network selection based on application orchestration information in an edge cloud system
WO2021134434A1 (fr) Procédé et système de filtrage d'horizon divisé de réseau privé virtuel ethernet (evpn)
US12244495B2 (en) Method and apparatus for layer 2 route calculation in a route reflector network device
WO2020212998A1 (fr) Attribution d'adresse de réseau dans un domaine de couche 2 virtuel s'étendant sur de multiples grappes de conteneurs
US11343332B2 (en) Method for seamless migration of session authentication to a different stateful diameter authenticating peer
WO2018042230A1 (fr) Mécanisme de packet-in configurable pour commutateurs openflow
CN115668883B (zh) 以太网虚拟私用网络出口快速重路由中的瞬变环路防止
US12463891B2 (en) Methods and systems to prioritize border gate protocol (BGP) route target (RT) membership network layer reachability information (NLRI) handling
WO2025099732A1 (fr) Procédés et systèmes pour inclure de multiples préfixes d'informations d'accessibilité de couche de réseau (nlri) de protocole de passerelle frontière (bgp) dans un message de mise à jour de bgp unique
US11876881B2 (en) Mechanism to enable third party services and applications discovery in distributed edge computing environment
WO2025027375A1 (fr) Procédés et systèmes pour une mise à jour de routage de réseau sur la base d'une interface de bouclage conditionnel
HK1248417B (zh) 揭示最大分段标识符深度值的方法、设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23958190

Country of ref document: EP

Kind code of ref document: A1