Sponsored content
BRAS, located at the metro edge, is the junction that connects the broadband access network with the metro backbone network in terms of physical position, and the portal for users to implement various broadband and data services by fixed network access and the policy enforcement point to control user broadband services in terms of function.
Taking both computing and forwarding into account, BRAS should not only provide powerful protocol processing capability but also meet the increasingly higher traffic forwarding requirements. BRAS should not be virtualized merely for virtualization. New equipment models are mainly driven by services instead of technology. Over the recent years, NFV technology has become a heated issue in the industry. However, as for whether and how BRAS should be virtualized, we need to analyze what benefits the virtualization will bring to operators and how to meet the new service development in the future.
Now the major pain points of traditional BRAS are:
- Unshareable resources:
- The control plane and the forwarding plane are closely coupled. The control plane is limited by the capability of one single CPU, so one single device/card can only carry a limited number of sessions. As a result, the control plane frequently needs capacity expansion. However, the processing capability of the forwarding plane NP increases according to Moore's Law, so the forwarding plane will be lightly loaded, which causes resource waste.
- Each device is an independent L3 NE. User addresses on each device should be planned in advance. The addresses cannot be shared dynamically among the devices, but must be adjusted manually.
- The devices are deployed in a distributed way and carry different service traffic due to site difference. Different sites cannot share services or back up for each other, so it cannot solve the tidal effect problem.
- Non-centralized management and complicated operation and maintenance
- With independent network and independent control plane, each device must be configured and upgraded independently, so it is difficult to make statistics on network KPI. As the devices further move down, the operation and maintenance is rather difficult and complicated.
- Long TTM period of new services
- Traditional BRAS employs closed software and hardware. The software and hardware are closely coupled, and so are the control plane and the forwarding plane. Therefore, it is difficult to support new requirements. Merely a small change to the requirement of the control plane requires software version upgrade on all devices one by one. A new service requirement from proposition to provisioning generally takes half a year or a longer time.
To sum up, traditional BRAS seriously restricts carrier network transformation and prosperous development of new services. The scissors gap of profit becomes increasingly prominent. In this background, three mainstream vBRAS solutions have emerged in the industry.
Figure 1 Three mainstream vBRAS solutions
Solution 1 simply transplants traditional BRAS software to X86 VM and still uses forwarding/control integrated architecture, so the pain points of traditional BRAS still exist. Besides, as the current X86 server has weak forwarding capability, this solution is not advantageous compared with traditional BRAS and cannot bring benefits to operators.
Therefore, BRAS virtualization must include architecture change. Solution 2 and 3 will be the development trend in the future, and the two solutions can be combined to meet the requirements of different scenarios. C/U separation technology is used to decouple the control plane form the forwarding plane. The core ideas include:
- User access signaling, user management and AAA modules that need strong computing capability are transplanted to X86 servers.
- High-performance packet forwarding and services with strong CT features are transported by high-performance NP/ASIC. Small-traffic services with weak CT features can also be transported by X86.
- C/U planes are completely decoupled to promote interface standardization. Different forwarding pools share the same control plane, as shown in Figure 2 and Figure 3.
Figure 2 Architecture with a unified control plane and two types of forwarding pools
Figure 3 Scenario with a unified control plane and two types of forwarding pools
The vBRAS with separated C/U architecture has been widely acknowledged in the industry and has been written to the technical white paper by the Industry Alliance. It has become the de facto standard. It perfectly solves the pain points of traditional BRAS: the control plane centralized cloudification provides strong computing resources, breaking the resource restriction of one single CPU on traditional BRAS, and increasing the number of user sessions supported by the hardware forwarding pool in the same condition by 5~10 times. The control plane performs centralized management on IP addresses and allocates them to the forwarding pools as required, which improves the utilization efficiency of IP address by more than 30%. Services only need to be configured in a unified way on the control plane and policies are forwarded to all forwarding planes in a centralized way. More than 70% of the requirements only demand software upgrade on the control plane. The service deployment period can be shortened from several months to several weeks.
Future metro networks need to meet the requirements of big video, 5G transport, Internet of Things and private line on demand services. They are required to have higher bandwidth, lower latency, extremely high reliability and intelligent operation and maintenance. As the core device at the service control layer of a metro network, BRAS should have higher elasticity and more open interfaces in architecture and should be able to evolve towards AI.
The high-bandwidth, low-latency and high-concurrency features of 5G services require that 5G data gateways should further move down. FMC is made possible, so BRAS is required to evolve towards C/U separation. Internet of Everything causes the number of network nodes and devices to increase exponentially. Centralized automatic management and control must be provided for massive devices. This requires that BRAS should support access and management of more than ten million sessions. After C/U separation is implemented for BRAS, the control plane can well satisfy this requirement using X86 cloud computing technology.
New Internet services and massive sessions also pose higher requirements for system reliability. At present all components in a single vBRAS system employ redundancy design to improve the reliability in a single DC as much as possible. However, this is far from enough. Faults of one DC such as natural disaster and power failure cannot be avoided completely, so cross-DC backup is a must. Now cross-DC backup includes two solutions: hot standby and cold standby. Hot standby requires real-time synchronization of user data among DCs. When the working DC fails, the standby DC can take over the tasks of the control plane at millisecond level. The user does not need to redial and the session is not interrupted. Cold standby does not require cross-DC user data synchronization and causes lower extra overhead to the system. But when the working DC fails, the user needs to redial to reconnect with the network after network disconnection. To improve user experience and increase user loyalty, it is recommended to deploy cross-DC hot standby, so that the user cannot perceive the disconnection when faults occur.
Early in 2016, ZTE launched the ZXR10 V6000 vBRAS that employs separated C/U architecture. Now the control plane of a single system can support 20 million concurrent sessions and parallel access of more than 200 forwarding devices. The access rate and table entry forwarding rate both exceed 10000 per second. It also supports automatic capacity expansion/reduction, pooling networking and cross-DC hot standby technologies. It has completed applications and trials in China Mobile, China Telecom, China Unicom and some overseas operators. The total number of accumulated projects is more than 20.
Driven by new services and technologies, the control plane of vBRAS should continue to evolve towards microservices and flexibly support third-party applications and services. The forwarding plane should continue to evolve towards universality. As a breakthrough point of metro network virtualization, the vBRAS is leading the network virtualization development direction. Along the long evolution path in the future, ZTE will strengthen cooperation with more equipment providers and upstream/downstream partners to build a wonderful network virtualization path.