OpenNESS 19.12 Integration

1 OpenNESS 19.12 Design
2 Gap Analysis for Integrating OpenNESS with ICN
- 2.1 Network Policy
  - 2.1.1 Default network policy: block all ingress
  - 2.1.2 Admin defined network policy
- 2.2 DNS
- 2.3 Cross-Node communication
- 2.4 OS (Ubuntu)
3 Openness Integration Design
4 ICN Requirements for adding EAA support for geo-distributed producing and consuming applications
- 4.1 BACKGROUND
- 4.2 REQUIREMENT

OpenNESS 19.12 Design

Openness released 19.12 on December 21 2019 and this new release has removed the deployment mode ( kubernetes + NTS ). Two modes is supported now: Native deployment Mode (which is based on pure docker/libvirt) and Infrastructure Mode (which is based on kube-ovn), below are the brief summary of the difference of these 2 modes:

Functionality	Native Deployment Mode	Infrastructure Deployment Mode
Usage Scenarios	On-Premises Edge	Network Edge
Infrastructure	Virtualization base: docker/libvirt Orchestration: OpenNESS controller Network: docker network (container) + NTS (through new added KNI interface)	Orchestration: Kubernetes Network: kube-ovn CNI
Micro-Services in OpenNESS Controller	Web UI: controller UI Edge Node/Edge application lifecycle management Core Network Configuration Telemetry	Core Network Configuration: Configure the access network (e.g., LTE/CUPS, 5G) control plane Telemetry
Micro-Services in OpenNESS Node	EAA: application/service registration, authentication etc. ELA/EVA/EDA: used by controller to configure host interfaces, network policy (used by NTS), create/destroy application etc. DNS: for client to access MS in edge node NTS: traffic steering	EAA: application/service registration, authentication etc. EIS(Edge Interface Service), looks to be similar with providernet implemented in ovs4nfv k8s CNI DNS: for client to access MS in edge node
Application on-boarding	OpenNESS Controller Web UI or Restful API	Kubernetes (e.g. Kubectl apply -f application.yaml) Note: unlike 19.09, No UI used to on-board application
Edge node interface configuration	ELA (Edge LifeCycle Agent, Implemented by OpenNESS) – Configurated by OpenNESS controller	EIS (Edge Interface Service, which is an kubectl extension to configurate edge node host network adapter), use e.g. kubectl interfaceservice attach $NODE_NAME $PCI_ADDRESS
Traffic Policy configuration	EDA (Edge Dataplane Agent, Implemented by OpenNESS) – Configurated by OpenNESS controller	Kubenetes Network Policy CRD e.g. kubectl apply -f network_policy.yml Note: unlike 19.09, No UI used to configure policy
DataPlane Service	NTS (Implemented based on DPDK in OpenNESS) to provide additional KNI interface for container	kube-ovn + Network policy

Gap Analysis for Integrating OpenNESS with ICN

Network Policy

Network policy and DNS is used for traffic steering. Network policy is used for restrict access among services but NOT “proactively” forward the traffic, While the OpenNESS DNS service can help “redirect” the external client’s traffic to the edge application service。

By default, in a Network Edge environment, all ingress traffic is blocked (services running inside of deployed applications are not reachable) and all egress traffic is enabled (pods are able to reach the internet). The following NetworkPolicy definition is used:

Default network policy: block all ingress

apiVersion: networking.k8s.io/v1
metadata:
  name: block-all-ingress
  namespace: default        # selects default namespace
spec:
  podSelector: {}           # matches all the pods in the default namespace
  policyTypes:
  - Ingress
  ingress: []               # no rules allowing ingress traffic = ingress blocked

Admin can enable access to certain service by applying a NetworkPolicy CRD. For example:

1. To deploy a Network Policy allowing ingress traffic on port 5000 (tcp and udp) from 192.168.1.0/24 network to OpenVINO consumer application pod, create the following specification file for this Network Policy:

Admin defined network policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: openvino-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      name: openvino-cons-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
    ports:
    - protocol: TCP
      port: 5000
    - protocol: UDP
      port: 5000

2. Create the Network Policy:
kubectl apply -f network_policy.yml

DNS

DNS service can help “redirect” the external client’s traffic to the edge application service. This gap analysis is to investigate whether OpenNESS DNS can be used for ICN traffic steering or not.

OpenNESS provides DNS server which provides the microsevice’s ip address based on FQDN. OpenNESS extends kubectl utility with kubectl edgedns cmd to set/delete DNS entry. For example，

define a file with below content: openvino-dns.json
{
"record_type":"A",
"fqdn":"openvino.openness",
"addresses":["10.16.0.10"]
}
Then use below command to add an entry in OpenNESS DNS server:
kubectl edgedns set <edge_node_host_name> openvino-dns.json