Seamless BFD Introduction
Bidirectional Forwarding Detection (BFD) was introduced as part of OAM functionality for path continuity check that helps with rapid failure detection that plays a key role in enhancing fast convergence and traffic redirection within few 10s of milliseconds to abide with end user applications expectation. BFD is a light weight, less control plane overhead protocol that creates a session with neighbor after a 3-way handshake and exchange control packets at regular interval (few msec) and notify any failure to the client protocols like IGP, PIM, RSVP within few milliseconds.
Segment Routing is key enabler for Software Defined Networking and plays an essential role to dynamically instantiate tunnel between end points by encoding the state/path entries only on the tunnel head end. Such Traffic Engineering tunnels instantiated with Segment Routing are required to validate the path before using it for data traffic. Applying BFD for such requirement uncovers several limitations due to the base characteristics of BFD:
- BFD creates state entries on both headend and tailend. Any node acting as tail end for 1000s of headend will result in creating 1000 state entries for uni-directional path validation. This results in scaling problems.
- BFD requires exchanging the discriminators that introduces a delay before validating the path.
- BFD can become resource intensive with respect to memory utilization and CPU processing due to 1-1 session between end points.
The above challenges directly imposed a need for a simple mechanism to monitor the path and virtual resources for any failure detection. In this document, we introduce Seamless BFD (S-BFD) and explain how S-BFD addresses the challenges listed above.
Seamless BFD Overview
RFC 7880 proposes the S-BFD architecture. S-BFD was designed by extending the BFD and addressing the challenges faced with BFD. S-BFD introduces the below:
- Concept of pre-assigning domain wide unique discriminator and advertise the same using IGP protocol extension.
- Concept of Reflector session that reflects the control packet if the Your Discriminator matches the local reflector session discriminator value.
There are two components of S-BFD as below:
- S-BFD Discriminators
- S-BFD Reflector session
S-BFD Discriminator
A pair of Discriminator negotiated between BFD neighbors identifies a BFD session. In traditional BFD, the Discriminator is negotiated as part of 3-way handshake. With Seamless BFD, each network entity within same administrative domain will be pre-assigned with a minimum of one domain wide unique Discriminator and advertised using IGP protocol extensions.
The uniqueness of S-BFD Discriminator being the key aspect, it is the Operators responsibility to maintain the domain wide uniqueness as like the System or Router ID of IGP protocol. While the simple option is to arbitrarily allocate from a pool of Discriminator manually by Operators, there are other various options that can be considered. For example, when the underlying IGP protocol is OSPF, the uniqueness of 32-bit Router Identifier can be leveraged and use the same as S-BFD Discriminator. Alternately, the centralized intelligence like SDN can also be leveraged to dynamically assign from a pool. Cisco implementation supports leveraging the loopback IPv4 address as Discriminator.
In Figure 1, it can be noted that each entity that needs to be monitored will be assigned with a unique S-BFD Discriminator. As shown in Figure 1, Host H1 assigns Discriminator D1 for Entity E1 and Discriminator D2 for Entity E2. When any node within the domain is required to monitor Entity E1 within Host H1, will send a S-BFD Control packet to H1 and set the control packet details in S-BFD as Your Discriminator (YD)=D1 and My Discriminator (MD)=Local-Random-value.
This enhanced characteristic of S-BFD completely eliminates the need for any handshake or Discriminator negotiation between end points to monitor any path or local resources. This drastically reduces the time taken by the Initiator to create a session and, consequently, augments the swiftness for path and resource liveliness validation.
S-BFD Reflector session
Each network entity participating in S-BFD architecture will create one or more reflector sessions. The intention of reflector session is to respond back to a received S-BFD control packet with “Your Discriminator” (YD) as any one of the locally assigned S-BFD Discriminator.
The routers are allowed to have multiple reflector session with associated S-BFD Discriminator. This is required when S-BFD Discriminator is used for services other than basic connectivity. For example, a router can assign a S-BFD Discriminator to any local service and create a reflector session for the service S-BFD Discriminator. The router will respond back to control packet till the associated service is up. In case of the service failure, the associated reflector session will be disabled and no response will be sent back causing the session to fail on Initiator to take any necessary action.
This aspect of S-BFD eliminates the need for a per session state entry in each BFD neighbors.
S-BFD Functional Operation
Initiator behavior
Any node, upon instructed to check the liveliness of a remote entity by local client or manually, will trigger a S-BFD session by querying the local database to fetch the respective Discriminator advertised by the remote node for the entity. This Discriminator value will be used in Your Discriminator field of S-BFD control packet.
In Figure 2, Initiator is instructed to check the liveliness of Entity E1 on Responder. Accordingly, it will trigger a BFD session to Responder and will use the below details:
- “My Discriminator” as any random value that does not overlaps with local SBFD Discriminator.
- “Your Discriminator” as “02020202” - the value assigned and advertised by Responder for Entity E1.
- “State” to a value describing the local state.
- Set “Demand” bit in control packet.
Figure 3 shows the control packet format where the above information will be populated. Upon receiving a reply back from the remote node (S-BFD Responder), the Initiator should declare that the session is UP. If there is no reply from remote node till the local timer expired, Initiator should intimate the failure to respective local client associated with this session.
Responder behavior
Any node, upon receiving S-BFD control packet with “Your Discriminator” value matching one of the locally assigned S-BFD Discriminator, should forward it to S-BFD Reflector session after following the traditional BFD packet validation. In Figure 2, Responder on receiving S-BFD with Your Discriminator of “02020202” will forward to S-BFD Reflector session. The Reflector session will generate a reply back with below details:
- “My Discriminator” as “02020202”
- “Your Discriminator” as value copied from received BFD control packet.
- “State” to value describing the local state.
- Clear the “Demand” bit.
Experimental Testing and analytical result
Test Environment
We performed the testing in a test bed with two Cisco routers back-to-back connected. For performance accuracy, we didn’t include any transit devices We tried the testing on 2 different Cisco IOS-XR software versions. We used MPLS-TE as BFD Client. This study is to compare the resource utilization between traditional BFD and S-BFD.
- Number of Sessions: ~1000
- Metrics studied: Memory consumption, CPU Utilization for BFD process, Time taken for session establishment.
- Hardware Type: Cisco ASR9000 Routers
- Software: Cisco IOS-XR 5.3.4 and Cisco IOS-XR 6.1.2.
Analytical Result
Below is the observed analytical result while comparing the performance between traditional BFD and S-BFD using MPLS-TE as the client.
Traditional BFD (Cisco IOS-XR version 5.3.4) | |||
No. of Sessions | Memory Consumed (in KB) | Time taken for session establishment (in msec) | CPU Utili |
200 | 2138 | 4012 | 0.18% |
400 | 4437 | 9120 | 0.85% |
600 | 6679 | 12238 | 1.02% |
960 | 10672 | 17331 | 2.03% |
Table 1. Statistics for Traditional BFD (IOS-XR 5.3.4 Version)
Traditional BFD (Cisco IOS-XR version 6.1.2) | |||
No. of Sessions | Memory Consumed (in KB) | Time taken for session establishment (in msec) | CPU Utili |
200 | 2617 | 12231 | 0.20% |
400 | 5718 | 13141 | 0.80% |
600 | 8721 | 16998 | 1.00% |
960 | 14914 | 23124 | 2.00% |
Table 2. Statistics for Traditional BFD (IOS-XR 6.1.2 Version)
Seamless BFD (Cisco IOS-XR version 5.3.4) | |||
No. of Sessions | Memory Consumed (in KB) | Time taken for session establishment (in msec) | CPU Util |
200 | 122 | 200 | 0.12% |
400 | 245 | 2510 | 0.68% |
600 | 369 | 3011 | 0.94% |
960 | 590 | 4000 | 1.92% |
Table 3. Statistics for Seamless BFD (IOS-XR 5.3.4 Version)
Seamless BFD (Cisco IOS-XR version 6.1.2) | |||
No. of Sessions | Memory Consumed (in KB) | Time taken for session establishment (in msec) | CPU Util |
200 | 140 | 1009 | 0.50% |
400 | 260 | 2110 | 0.70% |
600 | 380 | 2560 | 1.00% |
960 | 610 | 3000 | 2.00% |
Table 4. Statistics for Seamless BFD (IOS-XR 6.1.2 Version)
Graphical Comparision is as below:
Conclusion:
As summarized in the above tables and Graphs, below are the observed metrics while testing BFD and S-BFD:
- The Memory consumption for traditional BFD is directly proportional to the number of sessions while it does not increase drastically for Seamless BFD.
- As the number of session increases, the time taken for session establishment is more for traditional BFD due to the Discriminator negotiation while it is minimal for Seamless BFD as there is no Discriminator negotiation.
- The CPU utilization is nearly the same for both Traditional BFD and Seamless BFD with a very negligible difference.
Disclaimer: The statistics are collected from testing environment and is not absolute value but relative values.
* There is no difference in rate at which packets are exchanged as it is based on the configured interval
No comments:
Post a Comment