White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue


Page 77 of 144

Understanding OPNFV 77 the time the infrastructure gets provisioned. Copper ensures against this problem by working with two upstream projects: OpenStack Congress (policy-as-a-service) and OpenDaylight Group-Based Policy (GBP). The eventual goal is to ensure policies are part of the VNF package or metadata and to ensure these policies are enforced at every layer across diverse infrastructure managers. Domino (Template distribution service) Centralized orchestration of VNFs and the underlying infrastructure may not always be possible. For example, carrier networks may span geographies, or operators may undergo mergers and acquisitions resulting in heterogeneous orchestration tools. These situations require a top-down layer that can take a template describing service models and policies, and partition that template into specific templates for each local orchestration and controller tool. This is the role of the Domino project. Domino converts policies to TOSCA and distributes respective templates using a pub/sub system while taking dependencies into account. The scope of the project includes defining functionality, APIs, test/integration and debugging/tracing. ENFV (Edge NFV) In vCPE, vPE (provider edge), IoT, or other use cases, it makes sense to split the NFVI between a centralized cloud and edge compute nodes. This is also called fog computing. Splitting NFVI in this manner creates unique challenges. The goal of this project is to specify requirements for edge NFV in areas such as tunneling, the ability to handle many small "data centers", remote node monitoring, data plane optimization, and so on. The project collaborates with other OPNFV projects and influences upstream OpenStack, ODL, and OVS projects. Escalator (Smooth upgrade) With NFV, upgrading the NFVI and VIM becomes more complicated than fixed function boxes. The Escalator project plans to define requirements for smooth upgrades for major or minor version changes in a manner that does not unreasonably degrade VNF uptime. The project identifies parameters such as the maximum duration of upgrade or rollback, maximum duration of VNF interruption, and mechanisms to prepare an upgrade. More recently, the project has also created test cases to test upgrades.

Articles in this issue

Links on this page

view archives of White Papers - Understanding OPNFV