In all the approaches do not take care of

In the environment of NFV and considering the functional tasks exposed in the previous the chapter for a BRAS system as a virtualized network function, the table
ef{tab:Comparison} provides a comparison for each of the approaches presented before.After comparing the different approaches exposed throughout this chapter, we find out that most of them fulfill with basic BRAS system task functionalities such as customer tunneling, AAA services, L2 and L3 forwarding, access control, service differentiation and service aggregation. In general, as explained in chapter 3, those task functionalities correspond to the basic group of functionalities that a BRAS system must provide adding the likes of rate enforcement, multicast traffic support and quality of service assurance. Regarding rate enforcement, multicast traffic support and quality of service assurance is observed that almost all the approaches do not take care of them. There may be different reasons for that to happen, here, according to our own assumptions, we mention the most reasonable ones. In the case of the rate enforcement, there is not explicit related information shown in the corresponding papers. Nonetheless, in both rethinking high-performance virtual BRAS citep{bifulco2013rethinking} and enhancing BRAS session server citep{dietz2015enhancing}, they state that the prototype implements a shaping module for the BRAS system processing and forwarding of packets. Hence, it is believed that the inclusion of policing techniques as part of any of the approaches would be highly relevant that it would be expected to be included within the encountered documentation in the case of being implemented. To conclude, it is assumed that none of the approaches implement policing techniques and as observed in table
ef{tab:Comparison} the column referred as rate enforcement is left with an unknown state meaning that shaping implementation is not noticed throughout the related work, aside from the afore mentioned approaches. For multicast traffic support, it is believed that due to the short maturity of the considered techniques, it remains still as an ongoing field of investigation and therefore, it is assumed extremely premature to find a BRAS system approach that already supports multicast traffic techniques. Just like the explanation for rate enforcement this column is left empty which corresponds to an unknown state.The third identified functional task refers to quality of service. Although in the OpenFlow switch specification citep{openflow2009openflow} are defined basic module mechanisms for quality of services implementation, such as metering and queuing, there was not found information in the related literature referring to a BRAS system approach that implements QoS functionalities. Hence, the column of QoS in table
ef{tab:Comparison} is left in unknown state.Taking in consideration the functionalities for access services creation in a virtualization environment, we evaluate 6 principal features including decentralization of services, service load distribution, load balancing, traffic balancing, session migration and scale out. It can be seen in table
ef{tab:Comparison} that the decentralization of access service creation is the most supported feature among the presented approaches which is clearly expected due to the centralization of services provided by classical technologies. Service load distribution models require, in general, the implementation of a fully functional controller plane able to handle the BRAS data path elements placed in the customer path and therefore, such implementation would not fit the proposed scenario. Load balancing is considered an important characteristic for a virtualization of BRAS system, however, in between the approaches presented there are two that already implement this feature and consequently is not taken further into consideration. It is considered that scale-out functionality is the most relevant for this thesis because there is no other BRAS system implementation that includes this feature and furthermore it is considered as a highly important functional task because of the afforded advantages in the proposed migration-phase scenario. Moreover, it is believed that scale out may be easily complemented with the traffic balancing feature which leads to an attractive implementation.Summing up, we consider the next functional characteristics as the most relevant namely decentralization of services, traffic balancing, scale out. Therefore this thesis will be focused on them.