Page 161 - ITU-T Focus Group IMT-2020 Deliverables
P. 161

ITU-T Focus Group IMT-2020 Deliverables                                3


            which are largely considered as SDN’s responsibility. However, as mentioned above, SDN’s data plane is not
            so much flexibly programmable.

            We posit that data plane programmability may bring more innovations in future networking, in network
            softwarization, especially in the SDN and NFV areas applied to 5G mobile networking. We expect at least
            three benefits enabled by deeply programmable data plane, (1) enhanced interaction between applications
            and networks, (2) enhanced flexibility and optimization of network functions, and (3) rapid development of
            new network protocols such as ICN.

            7.3.2   Challenges in Data Plane Programmability [Ref.7.3-2]
            To enable flexibly and deeply programmable, we post there are three major technical challenges, (1) ease of
            programming,  (2)  reasonable  and  predictable  performance  and  (3)  isolation  among  multiple  concurrent
            logics
            First,  we  must  consider  lowering  the  barrier  to  entry  for  programming  network  functions.  Network
            softwarization is considered as cost-effective solutions, but the premise is that we need lots of programmers
            for creating network functions, let alone data plane functionalities. Therefore, one of the most important
            challenges to resolve is how we can accommodate programmers of various levels of skills and thus increase
            the  entire  number  of  programmers.  There  could  be  lots  of  kinds  of  programming  models  for  defining
            programmable data plane, such as FPGA, Intel Data Plane Development Kit (DPDK), Network Processors with
            many cores, but we need to carefully select these platforms in terms of ease of programming and debugging.

            Second,  performance  is  another  challenge  in  programmable  networking.  It  is  often  the  case  with
            programmable network equipment that there is trade-off between the programmability, i.e., how simply and
            flexibly we can program and the performance, i.e., how fast we can execute programs. Especially, software
            solutions are mostly susceptible to performance degradation, although it is highly flexible and can be quickly
            designed and implemented. In the light of this observation, we believe that we should select the platform
            with high flexibly but reasonable and at least predictable performance.
            And finally, we believe the capability of programming multiple concurrent logics on top of a single physical
            programmable environment is significant. We can virtualize the physical hardware resources and provision
            necessary amount of virtual resources per logic to achieve programming of multiple logics on top of isolated
            virtual resources. Isolation of resources plays a very important role.

            7.3.3   Introduction to FLARE [Ref.7.3-1, 7.3-2 and 7.3-5]
            In FLARE [Ref.7.3-1] architecture, we attempt to resolve all three major technical challenges enumerated in
            Clause 7.3.2, namely (1) ease of programming, (2) reasonable and predictable performance and (3) isolation
            among multiple concurrent logics, in realizing software-defined data plane programmability. We introduce
            Toy-Block networking programming model to enable drag and drop programming in FLARE to resolve (1).
            Also, in order to achieve (2), we combine a hybrid of computation resources especially design a hierarchical
            structure of high-frequency small-number- core processors and low-frequency many-core processors. And
            finally,  for  (3),  we  employ  a  lightweight  resource  virtualization  technique  called  resource  container  for
            isolation of multiple logics. For the best isolation, we decide to partition many cores into groups and deploy
            a resource container per group [Ref.7.3-2].





















                                                                                                         155
   156   157   158   159   160   161   162   163   164   165   166