A YANG Module for uCPE management.
SFR
Paris
Ile-de-France
France
ietf.dmytro@shytyi.net
https://dmytro.shytyi.net
SFR
Paris
Ile-de-France
France
laurent.beylier@sfr.com
Telecom ParisTech
Paris
Ile-de-France
France
luigi.iannone@telecom-paristech.fr
Internet
Network Working Group
ucpe, service, yang, model, nso
This document provides a YANG data model for uCPE management (VYSM) and
definition of the uCPE equipment. The YANG Service Model serves as a
base framework for managing an universal Customer-Premises Equipment
(uCPE) subsystem. The model can be used by a Network Service
Orchestrator.
Network Function Virtualization is a technology that allows to
virtualize the network services running on dedicaded hardware. This
technology became a base for universal Customer-Premises Equipment
(uCPE). This document defines the uCPE as harware with x86 capabilities
that has a hypervisor. In other words, uCPE is a host that may run
multiple Virtual Machines with guest OSs, where each Guest OS may
represent a Physical Network Function. This document presents the YANG
Service Model (VYSM) to manage from an Orchestrator the infrastructure
inside the uCPE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Link - is an entity that enables link layer communication of nodes.
Port - node connector to the link.
NE - Network Element.
NSYM - Network Service Yang Module.
VYSM - VNF YANG Service Model.
Firstly, this document defines the platform that is controlled
with VYSM - universal CPE (uCPE). The uCPE as harware with x86
capabilities that is generally running Linux distibution with
additinal virtualisation layer. Virtualization layer provides
virtual compute, virtual storage and virtual network resources.
Each VNF runnning in the uCPE requires the amount of virtual
resources (for example: 4 vCPUs, 4GB RAM, 40GB storege, 4
vPorts). VNFs MAY be interconnected between each other and
physical ports via Virtual Networks. Topology construction and
VM lifecycle management is allowed via high level interface
(Configuration can be done in the same transaction). The figure
below presents the uCPE architecture.
The next elements can be managed in the uCPE:
Virtual Network Funcitons:
Number of assigned vCPUs.Size of allocated RAM.VNF day0 config (bootstrap).vLinks that are attached to the VNF.Virtual Switches:
vLinks that are attached to the vSW.Virtual Links(vLinks).Physical Ports of the uCPE.uCPE replaces multiple types of equipment (Node#1 - Node#5) with 1 unit by virtualizing them as Virtual Network Functions on the top of NFVIs:
uCPE falicitates the interconnection between the Network Funtions (NF) as interconnection between NF is performed via virtual links(that is part of the uCPE management). That meens that no need to hire technichian to cable the equipment, it could be done via orchestrator.
uCPE falicitates the 0day configuration of the VNFs as its 0day configuration can be putted remotely.
uCPE supports a Virtual Network Funcitons of different type:
SD-WANvRouter(vCPE)vFirewallvLB(vLoad Balancer)vCGNAT(vCarrier Grade NAT)virtual WAN OptimistaionvWireless LAN controllerOther...
The VNF in the uCPE could be a vRouter or vFirewall or an
SD-WAN that is not a default part of virtual network resources
of the uCPE. Multiple VNFs MAY be instantiated in the uCPE.
With support of links and swithes, VNFs MAY participate a
service chains. Example of service chains (Note that virtual
switch "vs(WAN)" connected to LAN ports and vSW(WAN) is
connected to WAN ports):
vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(LAN).vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN).vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service1)-l3-vFirewall-l4-vSW(Service2)-l5-SD-WAN-l6-vSW(LAN).vSW(WAN)-l1-SDWAN-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN).
Secondly, this document defines and classifies the VYSM as Network Service YANG Module(NSYM) layer component RFC 8199. Thus it inherits the characteristics of the NSYM Layer.
VYSM is a modeled representation of the specific service requirements. It provides abstraction of services configuration and operations
that MAY be implemented in Network Elemets (NEs). Thus VYSM does not describe all configuration to be performed on the devices, but provides
the configuration that is required for the "Network Service to Network Element(s)" decomposition process RFC 8199.
Example of the decomposition is presented in the figure below.
The Network Service YANG module exposes the configuration commands via the Northbound interfaces
of the orchestrator. Therefore the set of the commands modeled in the VYSM can be inputed via Notrhbound interfaces(for example CLI).
In the example the command "vm VNF1" is passed via Northbound interface to the orchestrator. It defines the virtual machine name.
Further the same configuration MAY be transormed to the one or multiple Network Element payloads (for example xml for NETCONF) that carry an equivalent of commands such as "nf nf-name VNF1"
This section provides an overview of the Service YANG Model (VSYM) that
MAY be made with "pyang" utility. The figure below presents the tree
diagram of VYSM.
../../../links/link
+--rw switches* [switch]
| +--rw switch string
| +--rw ports* [port]
| +--rw port string
| +--rw name? string
| +--rw link? -> ../../../links/link
+--rw vms* [vm]
+--rw vm string
+--rw ports* [port]
| +--rw port string
| +--rw name? string
| +--rw link? -> ../../../links/link
+--rw ram? uint64
+--rw cpu? uint64
+--rw storages* [id]
| +--rw id string
| +--rw location? string
+--rw day0-config
+--rw location? string
+--rw day0-var-path? string
+--rw variable* [name]
+--rw name string
+--rw value? string
]]>
This section presents the specification of the VYSM.
file "ietf-ucpe@2019-10-28.yang"
module ietf-ucpe {
namespace "urn:ietf:params:xml:ns:yang:ietf-ucpe";
prefix ietf-ucpe;
organization
"SFR";
contact
"Dmytro Shytyi
EMail:ietf.dmytro@shytyi.net";
description
"This is a Network Function Virtualization (NFV) YANG
service model.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2019-10-28 {
description
"Yang model with vPorts assigned to the interfaces";
reference
"draft-shytyi-opsawg-vysm-05";
}
revision 2019-10-19 {
description
"Yang model was cleaned. Interfaces added";
reference
"draft-shytyi-opsawg-vysm-04";
}
revision 2019-09-16 {
description
"Added 0day config for VNFs.
Yang model modified according
to the received comments.";
reference
"draft-shytyi-opsawg-vysm-00";
}
revision 2018-01-07 {
description
"Initial revision.";
reference
"draft-shytyi-netmod-vysm-01";
}
list ucpe {
key "name";
leaf name {
type string;
description
"ID of uCPE where
a service is instantiated";
}
list links {
key "link";
leaf link {
type string;
description
"Name of the virtual link from the pool
of the links";
}
description
"Pool of the virtual links that connect VMs and
Interfaces";
}
list phyInterfaces {
key "interface";
leaf interface {
type string;
description
"Name of physical interface";
}
list ports {
key "port";
leaf port {
type string;
description
"Name of the connector";
}
leaf link {
type leafref {
path "../../../links/link";
}
description
"Link that is connected to
the port via connector";
}
description
"Set of the connectors the
physical interface has";
}
description
"Set of physical interfaces";
}
list switches {
key "switch";
leaf switch {
type string;
description
"Name of the forwarding domain";
}
list ports {
key "port";
leaf port {
type string;
description
"Name of the connector";
}
leaf name {
type string;
description
"Name of the
subconnector";
}
leaf link {
type leafref {
path "../../../links/link";
}
description
"Link that is connected to the
switch via port";
}
description
"Set of the connectors the
forwarding domain has";
}
description
"Set of the forwarding domains";
}
list vms {
key "vm";
leaf vm {
type string;
description
"ID of the Virtual Machine";
}
list ports {
key "port";
leaf port {
type string;
description
"Name of the connector";
}
leaf name {
type string;
description
"Name of
the subconnector";
}
leaf link {
type leafref {
path "../../../links/link";
}
description
"Link that connects the
VM with a switch or Interface
via connector";
}
description
"Set of Virtual Machine connectors";
}
leaf ram {
type uint64;
description
"Size of RAM to allocate for
the Guest OS";
}
leaf cpu {
type uint64;
description
"Number of vCPUs to
allocate for the Guest OS";
}
list storages {
key "id";
leaf id {
type string;
description
"Number of
vDisk attached to the VM";
}
leaf location {
type string;
description
"External location where
the image (ex.qcow2) is saved.";
}
description
"Virtual storge/vDisk
attached to the Virtual Machine";
}
container day0-config {
leaf location {
type string;
description
"0day configuration location";
}
leaf day0-var-path {
type string;
description
"path of the file
that contains the 0day variables";
}
list variable {
key "name";
leaf name {
type string;
description
"variable name";
}
leaf value {
type string;
description
"variable value";
}
description
"list of variables";
}
description
"0day configuration:init config";
}
description
"Set of the Virtual Machines configured
on the universal Customer-Premises Equipment";
}
description
"This is an uCPE management service";
}
}
]]>
The XML example below presents the configuration of
the next service in the uCPE, where: vSW(LAN),
vSW(WAN), vSW(Service) - virtual switches;
l1,l2,l3,l4 - virtual links; VMs represent PNFs
(Physical Network Fuctions) that could be bootstrapped
with 0day config/license.
ucpe1
l1
l2
l3
l4
lan10l2p10
l2
service10l3p10
l3
11l4p10
l4
wan10
l1
VNF-vCPE1l1p1
l1
2l4p2
l4
204821http://192.168.2.1/vCPE-x86.qcow2https://192.168.2.1/vCPE-day0.iso/config.romhostnameIETF-vCPEipaddress192.168.1.2 255.255.255.0VNF-vFirewall1l3p1
l3
2l2p2
l2
204821http://192.168.2.1/vFirewall-x86.qcow2https://192.168.2.1/vFirewall-day0.iso/config.romhostnamevFirewallipaddress192.168.1.3 255.255.255.0
]]>
At this time, no security considerations are addressed by this
memo.
No request to IANA at this time.
The authors would like to thank:
Mahesh Jethanandani.Robert Varga.Bill Wu.Joe Clarke.Tom Petch.Martin Bjorklund.Schönwälder Jürgen.
for their valuable comments.