Academia.eduAcademia.edu

Figure 16 – uploaded by Arun Yerra

See full PDFdownloadDownload figure
Figure 9: The RO Control Plane view considering a recursive programmatic interface for joint compute, storage and network provisioning Based on the recursion principles shown above and the complexity implied by separate interfaces for compute and network resources, one could imagine a recursive programmatic interface for joint compute, storage and network provisioning as depicted in Figure 9.

Figure 9 The RO Control Plane view considering a recursive programmatic interface for joint compute, storage and network provisioning Based on the recursion principles shown above and the complexity implied by separate interfaces for compute and network resources, one could imagine a recursive programmatic interface for joint compute, storage and network provisioning as depicted in Figure 9.

Related Figures (36)

Other average utilization parameters such as VM CPU utilization, VM. Memory utilization, VM disk read IOPS, Network utilization/latency etc. could be used by the policy engine to enforce other types of placement policies. Figure 1: NFVIaaS Architecture for Policy Based Resource Placement and Scheduling
Other average utilization parameters such as VM CPU utilization, VM. Memory utilization, VM disk read IOPS, Network utilization/latency etc. could be used by the policy engine to enforce other types of placement policies. Figure 1: NFVIaaS Architecture for Policy Based Resource Placement and Scheduling
policy" is just a derived subsystem configuration using an appropriate policy enforcement technology to support an actually intended policy. Figure 1: Example of Subsystem Translations of Policy Actions
policy" is just a derived subsystem configuration using an appropriate policy enforcement technology to support an actually intended policy. Figure 1: Example of Subsystem Translations of Policy Actions
Figure 2: Global versus Local Policy Engines
Figure 2: Global versus Local Policy Engines
Figure 3: A Hierarchical Policy Framework Metro and wide-area network (WAN) used to interconnect data centers would also be independent subsystems with their own policy engines.
Figure 3: A Hierarchical Policy Framework Metro and wide-area network (WAN) used to interconnect data centers would also be independent subsystems with their own policy engines.
Figure 4: A Policy Pub/Sub Bus The above examples demonstrate the need for subsystems to subscribe to policy updates at the Global policy level. A policy publication/subscription (pub/sub) bus would be required as shown in Figure 4.
Figure 4: A Policy Pub/Sub Bus The above examples demonstrate the need for subsystems to subscribe to policy updates at the Global policy level. A policy publication/subscription (pub/sub) bus would be required as shown in Figure 4.
Figure 5: Pub/Sub Bus - Hierarchical Policy Framework policy framework requires a policy pub/sub bus between all levels to allow for conflict detection, conflict information propagation, and conflict resolution (Figure 5).
Figure 5: Pub/Sub Bus - Hierarchical Policy Framework policy framework requires a policy pub/sub bus between all levels to allow for conflict detection, conflict information propagation, and conflict resolution (Figure 5).
Figure 6: Simplified view of a service provider’s NFV Architecture: Multipoint Ethernet Service Example
Figure 6: Simplified view of a service provider’s NFV Architecture: Multipoint Ethernet Service Example
Figure 4: Universal Node - an innovative element that integrates on the same platform both compute and networking components Figure 3: A virtualized Point of Presence (PoP) with software resources (Compute Node - CN)
Figure 4: Universal Node - an innovative element that integrates on the same platform both compute and networking components Figure 3: A virtualized Point of Presence (PoP) with software resources (Compute Node - CN)
Figure 5: Resource Orchestrator: information base, inputs and outpu' In Figure 5 we illustrate a resource orchestrator (RO) as a functional entity whose task is to map the service graph to the infrastructure resources under some service constraints and tak into account the NF resource descriptions.
Figure 5: Resource Orchestrator: information base, inputs and outpu' In Figure 5 we illustrate a resource orchestrator (RO) as a functional entity whose task is to map the service graph to the infrastructure resources under some service constraints and tak into account the NF resource descriptions.
Figure 6: The RO Control Plane view. Control plane interfaces are indicated with (line) arrows. Data plane connections are indicated with simple lines.
Figure 6: The RO Control Plane view. Control plane interfaces are indicated with (line) arrows. Data plane connections are indicated with simple lines.
In turn, each single Compute Node (CN) may also have internal switching resources (see Figure 8). In a carrier environment, in order to meet data path requirements, allocation of compute node internal distributed resources (blades, CPU cores, etc.) may become equivalently important.
In turn, each single Compute Node (CN) may also have internal switching resources (see Figure 8). In a carrier environment, in order to meet data path requirements, allocation of compute node internal distributed resources (blades, CPU cores, etc.) may become equivalently important.
Figure 8: Compute Node with internal switching resource
Figure 8: Compute Node with internal switching resource
Figure 10: PoP DC Network with Compute Nodes (CN) considering the U interface and the URC element
Figure 10: PoP DC Network with Compute Nodes (CN) considering the U interface and the URC element
Note however, that traffic between the DC internal SFs (VNF1, VNF2Z VNF3) need to exit and re-enter the DC through the external SDN switch. This, certainly, is sub-optimal an results in ping-pong traffic similar to the local and remote DC case discussed in [I-D.zu-nfvrg-elasticity-vnf]. Figure 2: Black Box Data Center with ext Overlay
Note however, that traffic between the DC internal SFs (VNF1, VNF2Z VNF3) need to exit and re-enter the DC through the external SDN switch. This, certainly, is sub-optimal an results in ping-pong traffic similar to the local and remote DC case discussed in [I-D.zu-nfvrg-elasticity-vnf]. Figure 2: Black Box Data Center with ext Overlay
Figure 3: White Box Data Center with L2 Overlay
Figure 3: White Box Data Center with L2 Overlay
Figure 4: Recursive Domain Virtualization and Joint VNF FC programming: Overarching View Figure 4 illustrates a joint domain virtualization and programming setup. In Figure 4 "[x]" denotes ports of the virtualized data plane while "x" denotes port created dynamically as part of the VNF deployment request. Over the joint software and network virtualization VNF placement and the corresponding traffic steering could be defined in an atomic, which is orchestrated, split and handled to the next levels (see Figure 5) in the hierarchy for further orchestration. Such setup allows clear operational separation, arbitrary domain virtualization (e.g., topology details could be omitted) and constraint based optimization of domain wide resources.
Figure 4: Recursive Domain Virtualization and Joint VNF FC programming: Overarching View Figure 4 illustrates a joint domain virtualization and programming setup. In Figure 4 "[x]" denotes ports of the virtualized data plane while "x" denotes port created dynamically as part of the VNF deployment request. Over the joint software and network virtualization VNF placement and the corresponding traffic steering could be defined in an atomic, which is orchestrated, split and handled to the next levels (see Figure 5) in the hierarchy for further orchestration. Such setup allows clear operational separation, arbitrary domain virtualization (e.g., topology details could be omitted) and constraint based optimization of domain wide resources.
Figure 5: Recursive Domain Virtualization and Joint VNF FC programming: Domain Views
Figure 5: Recursive Domain Virtualization and Joint VNF FC programming: Domain Views
Internet-Draft Figure 6: Big Switch with Big Software definition
Internet-Draft Figure 6: Big Switch with Big Software definition
Figure 7: Big Switch with Big Software definition with a Network Function - Forwarding Graph (NF-FG)
Figure 7: Big Switch with Big Software definition with a Network Function - Forwarding Graph (NF-FG)
Figure 8: Virtualizer’s YANG data model: tree view
Figure 8: Virtualizer’s YANG data model: tree view
Figure 10: Functional decomposition of the NFVO and the VIM according to the ETSI MANO » managing the association of the virtualised resources to the physical compute, storage, networking resources.
Figure 10: Functional decomposition of the NFVO and the VIM according to the ETSI MANO » managing the association of the virtualised resources to the physical compute, storage, networking resources.
Management as shown in Figure 11, then a more flexible virtualization programming architecture could be created as shown in Figure 12. Figure 11: Functional decomposition of the NFVO and the VIM with the Joint Software and Network control API
Management as shown in Figure 11, then a more flexible virtualization programming architecture could be created as shown in Figure 12. Figure 11: Functional decomposition of the NFVO and the VIM with the Joint Software and Network control API
Figure 12: Joint Software and Network Control API: Recurring Flexible Architecture
Figure 12: Joint Software and Network Control API: Recurring Flexible Architecture
Figure 13: Single node infrastructure report example: Virtualization view
Figure 13: Single node infrastructure report example: Virtualization view
Figure 14: Single node infrastructure report example: xml view
Figure 14: Single node infrastructure report example: xml view
Figure 15: 3-node infrastructure report example: Virtualization view
Figure 15: 3-node infrastructure report example: Virtualization view
Figure 17 and Figure 18 show the allocation request for 3 NFs (NF1: Parental control B.4, NF2: Http Cache 1.2 and NF3: Stateful firewall C) as instrumented over a BiS-BiS node. It can be seen that the configuration request contains both the NF placement and the forwarding overlay definition as a joint request. Figure 17: Simple request of 3 NFs on a single BiS-BiS: Virtualization view
Figure 17 and Figure 18 show the allocation request for 3 NFs (NF1: Parental control B.4, NF2: Http Cache 1.2 and NF3: Stateful firewall C) as instrumented over a BiS-BiS node. It can be seen that the configuration request contains both the NF placement and the forwarding overlay definition as a joint request. Figure 17: Simple request of 3 NFs on a single BiS-BiS: Virtualization view
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved