BIER Next-Hop Selection Using BFR Node And Priority Attributes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current next hop determining methods in Bit Index Explicit Replication (BIER) domains are not flexible enough, particularly when multiple transit BFRs advertise the same BFER parameters, limiting the selection to longest match or ECMP policies.
Innovation Solution
A method and apparatus that allow for flexible next hop determination by considering attributes such as anycast BFR prefixes, node identifiers, and priority identifiers to select the optimal next hop based on specific policies, even when BIER information is identical.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If longest match policy or ECMP policy is used to select next hop, then routing decision is made based on standard policies, but flexibility in next hop selection is insufficient
Solution Approach 1:
The patent applies preliminary action by pre-establishing attribute information for each BFR (including node identifiers, priority identifiers, and anycast BFR prefixes) before the actual next hop selection process. This allows the third BFR to quickly reference these pre-prepared attributes when making routing decisions, enhancing flexibility without adding complex real-time computation.
Solution Approach 2:
The patent implements parameter changes by introducing multiple new parameters for BFR identification and selection (node identifiers, priority identifiers, anycast BFR prefixes) beyond the traditional BFR-id. These additional parameters provide more dimensions for next hop selection, allowing the system to adapt to different routing scenarios and requirements.
2Adaptability or versatility
If multiple transit BFRs advertise same BFER parameters, then BIER information is identical from multiple sources, but next hop selection becomes limited to standard policies
Solution Approach 1:
The patent applies local quality by assigning unique attribute information to each BFR (node identifiers, priority identifiers, anycast BFR prefixes) that differentiates them from one another. Even when BIER information is identical, these local quality attributes allow the third BFR to distinguish between different transit BFRs and make informed next hop selections based on specific local characteristics of each BFR.
Solution Approach 2:
The patent uses preliminary action by pre-collecting and storing attribute information from each BFR before the routing decision is needed. This includes obtaining node identifiers, priority identifiers, and anycast BFR prefixes in advance, so that when multiple BFRs advertise identical BFER parameters, the third BFR already has the differentiation information ready for selection.
3Productivity
If anycast BFR prefix is used as attribute, then next hop selection can be optimized for anycast traffic, but requires additional attribute information management
Solution Approach 1:
The patent applies preliminary action by pre-obtaining and storing the anycast BFR prefix attribute information from each BFR before it is needed for routing decisions. This allows the third BFR to efficiently match anycast traffic against pre-stored anycast prefixes and quickly determine the appropriate next hop, improving forwarding performance without requiring complex real-time attribute management.
Data Source
AI summary
A next-hop determining method is applied to a BIER domain based on bit index forwarding routing, and includes: A third device obtains first BIER information of a first device, an attribute of the first device, second BIER information of a second device, and an attribute of the second device, where the first BIER information includes a BFR-id of an edge BFR in a sub-domain, and the second BIER information includes the BFR-id of the edge BFR in the sub-domain. The third device determines, based on the first BIER information, the second BIER information, the attribute of the first device, and the attribute of the second device, a next hop to the edge BFR in the sub-domain.