The previously handled users avoiding likewise single points

The considered scenario involves the architecture of a classical ISP network where the service creation point of residential services, which for this case refers to the BRAS, was located at the edge of the core network. As mentioned before in this scenario each of the subscriber’s home gateways (HGWs) are required to establish a tunnel with the BRAS in order to be served with the privileges and attributes that enable them as part of the network.A classical architecture implies a high-cost platforms that can be able to provide the creation of residential services for a huge quantity of users. Therefore a solution that can be handled at the edge of the aggregation network or even closer to the end-customer is desired. Thus, a low-cost-effective system may supply those services to a fraction of the previously handled users avoiding likewise single points of failure topologies.In general, there are four main entities that comprehend the scenario proposed when considering DSL as the framework technology. The first includes the HGWs which are the devices in charge of initiate the connection requests to join the ISP network. Secondly, DSLAM is a technology that provides multiplexing of access lines leading to traffic aggregation of multiple users. Third, according to the design point of view of the service provider, the BRAS system would be placed to serve a certain amount of users and therefore it receives the connection of one or more DSLAMs. Fourth, the core network can be assumed as a black box router that provides reachability to other sites, services or the internet. These entities are observable in figure
ef{fig:BRAS_scenario}.The service creation is triggered by the HGW which uses, as explained in previous sections, an encapsulation tunnel that connects to the service creation point system. In addition, the scenario considers the case when multiple users want to receive access configuration parameters at the same time or more precisely, within a very small window time. Those parameters must be provided for the system in the shortest time possible. For that reason, the system must integrate on-site authentication and authorization services. To comply with the network placement location of the system (at the edge of the ISPs’ access/aggregation network) the platform deployment is intended to be placed at Main Distribution Frames (MDF). This platform must receive the HGW session request and process them accordingly.According to the geographical location, the scenario considers a variable amount of users connected to the system. For example, according to citep{internetlivestats:germany} the internet penetration in Germany in December 2016 is around 88\%. If considering that Darmstadt has 150.000 inhabitants, then 132.000 will possess internet access. Based on the Organisation for Economic Co-operation and Development (OECD) cite{oecd:broadsubscr1.2} the 75\% of internet fixed access connections in 2016 in Germany is provided by using DSL technologies. Therefore, as a rough example, 90.000 out of 132.000 internet users in Darmstadt are connected through DSL technologies. If we consider that there are a total of six main distribution frames (MDF) in this city citep{meinkontes}, and moreover supposing that each of them handles the same amount of users, we can conclude that 16.500 is the number of users per MDF in Darmstadt. Using the same calculation procedure for the users in the district of Wolfskehlen, which has around 4.200 inhabitants, the result of users handled in the single MDF is 2.772, which compared to the attended users per MDF in Darmstadt is about six times smaller. Taking this into account, different BRAS system solutions must be provided. Thus, in the case that a single platform handles the subscribers at the MDF of Darmstadt, a less robust platform may be considered to be deployed in Wolfskehlen’s MDF preserving the normal function of the system and enabling a heterogeneous system implementation. Figure
ef{fig:Darmstadt_wolfskehlen_MDF} shows a representation of the related example.On the other hand, the scenario considers that the number of HGW, as well as the DSLAMS, may increase. For instance, assume that a unification of offices occurs, and so, the number of sessions supported by the current infrastructure would be duplicated. In that case, it is likely that if all those sessions are migrated directly to the infrastructure of the surviving MDF, the number of rules handled by the BRAS data plane of the system may overflow. Hence, it is required an infrastructure that focuses on the benefits of scaling out solutions, which can be able to adapt to changes like the ones exposed before.The high interest in implementing virtualization techniques for services running over classical platforms is boosted by different organizations, however, most of the current ISP network infrastructures evidence a lack of already deployed virtualization solutions. For this sake, our scenario contemplates the absence of a centralized controller entity, which for example controls the platforms located at the access network. Furthermore, the scenario is deemed to stand in a ‘classical-to-NFV’ migration phase. It means that the approaches considered in the related work must be evaluated and decide whether or not they support a transition from classical network protocols towards handling the access services with the adapted and implemented virtualized network functions once the system deployment is carried out. Other systems that require, for instance, a fully compliant SDN architecture to its implementation, will not be able to handle the services in the migration phase and therefore will not fit in the described scenario.