Network Working Group D. Shytyi
Internet-Draft Ecole Polytechnique/Telecom ParisTech
Intended status: Informational L. Beylier
Expires: March 21, 2019 SFR/ALTICE
L. IANNONE
Telecom ParisTech
September 17, 2018

Virtualization YANG Servise Model (VYSM)
draft-shytyi-netmod-vysm-00.txt

Abstract

This document provides a specification of the Network Function Virtualization (NFV) YANG service model. The NFV service module serves as a base framework for managing an universal Customer-Premises Equipment (uCPE) NFV subsystem from the Orchestrator.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 21, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

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). The uCPE - is x86 universal harware (whitebox) that has a hypervisor. In other words, uCPE is a host that may run multiple Virtual Machines with guest OSs. Each Guest OS may represent a Physical Network Function. To manage from an Orchestrator the Network Function Virtualization Infrastructure inside the uCPE, the VNF YANG service model (VYSM) was developed.

2. Terminology

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.

3. NFV service module Tree Diagram overview

This section provides an overview of of the NFV service MAY be made with "pyang" utility. The figure below presents the Tree diagram of the NFV service module.

            
module: ietf-nfv-service
    +--rw virtualization* [name]
       +--rw name          string
       +--rw device*       string
       +--rw links* [link]
       |  +--rw link    string
       +--rw interfaces* [interface]
       |  +--rw interface    string
       |  +--rw ports* [port]
       |     +--rw port    string
       |     +--rw link?   -> ../../../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?        string
          +--rw cpu?        string
          +--rw storages* [id]
             +--rw id          string
             +--rw location?   string
	
          

4. Specification of the NFV service model

This section presents the specification of the NFV service model.

            
<CODE BEGINS> file "ietf-nfv-service@2018-07-01.yang"
module ietf-nfv-service {

  namespace "urn:ietf:params:xml:ns:yang:nfv-service";
  prefix nfv-service;
	organization 
		"Ecole Polytechnique/Telecom ParisTech/SFR";
 	contact 
		"Dmytro Shytyi
		EMail:ietf.dmytro@shytyi.net";
	description
		"This is a Network Function Virtualization (NFV) YANG 
		service model.";	
	revision 2018-07-01 {
		description 
		"Initial revision.";
		reference 
        "draft-shytyi-netmod-vysm-00";
	}

  list virtualization {
    key name;
    leaf name {
		type string;
  		description "Name of the instance of the service";
    }

    // may replace this with other ways of refering to the devices.
    leaf-list device {
		type string;
		description "List of the devices in available in the
		orchestrator";
    }
	
  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 interfaces{
		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 "Name 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 string;
			description "Amount of memory to allocate for
			the Guest OS";
		}
		leaf cpu{
			type string;
			description "Amount of cpus to allocate for the
			Guest OS";
		}
		list storages{
			key id;
			leaf id{
				type string;
				description "Name of the Storage";
			}
			leaf location{
				type string;
				description "External location where
				the image is saved.";
			}
			description "Virtual storge of the image 
			for the Virtual Machine";
		}
		description "Set of the Virtual Machines configured 
		on the universal Customer-Premises Equipment";
	}
	description "This is an RFS skeleton service";
  }
  }
}
<CODE ENDS>
   	
          

5. Security Considerations

At this time, no security considerations are addressed by this memo.

6. IANA Considerations

No request to IANA at this time.

7. Acknowledgements

At this time, no acknowledgements are addressed by this memo.

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

Authors' Addresses

Dmytro Shytyi Ecole Polytechnique/Telecom ParisTech Paris area , Ile-de-France France EMail: ietf.dmytro@shytyi.net URI: http://dmytro.shytyi.net https://shytyi.net
Laurent Beylier SFR/ALTICE Paris area , Ile-de-France France
LUIGI IANNONE Telecom ParisTech Paris , Ile-de-France France