< draft-xia-sdnrg-nemo-language-00.txt		draft-xia-sdnrg-nemo-language-01.txt >
	SDNRG Y. Xia, Ed.		SDNRG Y. Xia, Ed.
	Internet-Draft S. Jiang, Ed.		Internet-Draft S. Jiang, Ed.
	Intended status: Standards Track T. Zhou, Ed.		Intended status: Standards Track T. Zhou, Ed.
	Expires: January 5, 2015 S. Hares		Expires: April 30, 2015 S. Hares
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	July 4, 2014		October 27, 2014
	NEMO (NEtwork MOdeling) Language		NEMO (NEtwork MOdeling) Language
	draft-xia-sdnrg-nemo-language-00		draft-xia-sdnrg-nemo-language-01
	Abstract		Abstract
	The North-Bound Interface (NBI), located between the network control		The North-Bound Interface (NBI), located between the control plane
	plane and the applications, is essential to enable the application		and the applications, is essential to enable the application
	innovations and nourish the eco-system of SDN.		innovations and nourish the eco-system of SDN.
	While most of the NBIs are provided in the form of API, this document		While most of the NBIs are provided in the form of API, this document
	proposes the NEtwork MOdeling (NEMO) language which is anther NBI		proposes the NEtwork MOdeling (NEMO) language which is intent based
	fashion. Concept, model and syntax are introduced in the document.		interface with novel language fashion. Concept, model and syntax are
			introduced in the document.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 5, 2015.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Related work . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Requirements for the Intent Based NBI Language . . . . . . . 4
	4. The NEMO Language overview . . . . . . . . . . . . . . . . . 5		4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Network Model of the NEMO Language . . . . . . . . . . . 5		5. The NEMO Language Specifications . . . . . . . . . . . . . . 6
	4.2. Primitives . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. Network Model of the NEMO Language . . . . . . . . . . . 6
	5. The NEMO Language Examples . . . . . . . . . . . . . . . . . 9		5.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5.3. NEMO Language Overview . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5.4. Model Definition . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		5.4.1. Data Types . . . . . . . . . . . . . . . . . . . . . 9
	9. Informative References . . . . . . . . . . . . . . . . . . . 10		5.4.2. Model Definition and Description Statement . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		5.5. Resource Access Statements . . . . . . . . . . . . . . . 11
			5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12
			5.5.2. Link Operations . . . . . . . . . . . . . . . . . . . 12
			5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 13
			5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 14
			5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 14
			5.6.2. Policy Behavior . . . . . . . . . . . . . . . . . . . 14
			5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 17
			5.7. Connection Management Statements . . . . . . . . . . . . 17
			5.8. Transaction Statements . . . . . . . . . . . . . . . . . 18
			6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 18
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
			10. Informative References . . . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	While SDN (Software Defined Network) is becoming one of the most		While SDN (Software Defined Network) is becoming one of the most
	important directions of network evolution, the essence of SDN is to		important directions of network evolution, the essence of SDN is to
	make the network more flexible and easy to use. The North-Bound		make the network more flexible and easy to use. The North-Bound
	Interface (NBI), located between the control plane and the		Interface (NBI), located between the control plane and the
	applications, is essential to enable the application innovations and		applications, is essential to enable the application innovations and
	nourish the eco-system of SDN by abstracting the network		nourish the eco-system of SDN by abstracting the network
	capabilities/information and opening the abstract/logic network to		capabilities/information and opening the abstract/logic network to
	applications.		applications.
	The NBI is usually provided in the form of API (Application		The NBI is usually provided in the form of API (Application
	Programming Interface). Different vendors provide self-defined API		Programming Interface). Different vendors provide self-defined API
	sets. Each API set, such as OnePK from Cisco and OPS from Huawei,		sets. Each API set, such as OnePK from Cisco and OPS from Huawei,
	often contains hundreds of specific APIs. Diverse APIs without		often contains hundreds of specific APIs. Diverse APIs without
	consistent style are hard to remember and use, and nearly impossible		consistent style are hard to remember and use, and nearly impossible
	to be standardized.		to be standardized.
	Most of those APIs are designed by network domain experts, who are		In addition, most of those APIs are designed by network domain
	used to thinking from the network system perspective. The interface		experts, who are used to thinking from the network system
	designer does not know how the users will use the device and exposes		perspective. The interface designer does not know how the users will
	information details as much as possible. It enables better control		use the device and exposes information details as much as possible.
	of devices, but leaves huge burden of selecting useful information to		It enables better control of devices, but leaves huge burden of
	users without well training. Since the NBI is used by network users,		selecting useful information to users without well training. Since
	a more appropriate design is to think from the user perspective and		the NBI is used by network users, a more appropriate design is to
	abstract the network from the top down.		express user intent and abstract the network from the top down.
			To implement such an NBI design, we can learn from the successful
			case of SQL (Structured Query Language), which simplified the
			complicated data operation to a unified and intuitive way in the form
			of language. Applications do not care about the way of data storage
			and data operation, but to describe the demand for the data storage
			and operation and then get the result. As a data domain DSL, SQL is
			simple and intuitive, and can be embedded in applications. So what
			we need for the network NBI is a set of "network domain SQL".
	[I-D.sdnrg-service-description-language] describe the requirements		[I-D.sdnrg-service-description-language] describe the requirements
	for a service description language and the design considerations.		for a service description language and the design considerations.
	A top-down NBI design contains following features:		This document will introduce an intent based NBI with novel language
			fashion.
			2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119] when they appear in ALL CAPS. When these words are not in
			ALL CAPS (such as "should" or "Should"), they have their usual
			English meanings, and are not to be interpreted as [RFC2119] key
			words.
			Network service also "service" for short, is the service logic that
			contains network operation requirements;
			Network APP also "APP" for short, is the application to implement
			the network service;
			Network user also "user" for short, is the network administrator or
			operator.
			3. Requirements for the Intent Based NBI Language
			An intent based NBI language design contains following features:
	o Express user intent		o Express user intent
	To simplify the operation, applications or users can use the NBI		To simply the operation, applications or users can use the NBI
	directly to describe their requirements for the network without		directly to describe their requirements for the network without
	taking care of the implementation. All the parameters without		taking care of the implementation. All the parameters without
	user concern will be concealed by the NBI.		user concern will be concealed by the NBI.
	o Platform independent		o Platform independent
	With the NBI, the application or user can describe network demand		With the NBI, the application or user can description of network
	in a generic way, so that any platform or system can get the		demand in a generic way, so that any platform or system can get
	identical knowledge and consequently execute to the same result.		the identical knowledge and consequently execute to the same
	Any low-level and device/vendor specific configurations and		result. Any low-level and device/vendor specific configurations
	dependencies should be avoided.		and dependencies should be avoided.
	o Intuitive domain specific language (DSL) for network		o Intuitive Domain Specific Language (DSL) for network
	The expression of the DSL should be human-friendly and be easily		The expression of the DSL should be human-friendly and be easily
	understood by network operators. DSL should be directly used by		understood by network operators. DSL should be directly used by
	the system.		the system.
	o Privilege control		o Privilege control
	Every application or user is authorized within a specific network		Every application or user is authorized within a specific network
	domain, which can be physical or virtual. While different network		domain, which can be physical or virtual. While different network
	domains are isolated without impact, the application or user may		domains are isolated without impact, the application or user may
	have access to all the resource and capabilities within its		have access to all the resource and capabilities within its
	domain. The user perception of the network does not have to be		domain. The user perception of the network does not have to be
	the same as the network operators. The proposed NEtwork MOdeling		the same as the network operators. The NBI language works on the
	(NEMO) language works on the user's view so the users can create		user's view so the users can create topologies based on the
	topologies based on the resources the network-operators allow them		resources the network-operators allow them to have.
	to have.
	o Declarative style		o Declarative style
	As described above, NEMO language is designed to help defining		As described above, the NBI language is designed to help defining
	service requirement to network, detailed configurations and		service requirement to network, detailed configurations and
	instructions performed by network devices are opaque to network		instructions performed by network devices are opaque to network
	operators. So NEMO language should be declarative rather than		operators. So the NBI language should be declarative rather than
	imperative.		imperative.
	To implement such an NBI design, we can learn from the successful		4. Related work
	case of SQL (Structured Query Language), which simplified the
	complicated data operation to a unified and intuitive way in the form
	of language. Applications do not care about the way of data storage
	and data operation, but to describe the demand for the data storage
	and operation and then get the result. As a data domain DSL, SQL is
	simple and intuitive, and can be embedded in applications. So what
	we need for the network NBI is a set of "network domain SQL".
	2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] when they appear in ALL CAPS. When these words are not in
	ALL CAPS (such as "should" or "Should"), they have their usual
	English meanings, and are not to be interpreted as [RFC2119] key
	words.
	Network service also "service" for short, is the service logic that
	contains network operation requirements;
	Network APP also "APP" for short, is the application to implement
	the network service;
	Network user also "user" for short, is the network administrator or
	operator.
	3. Related work
	YANG is a data modeling language used to model configuration and		YANG [RFC6020] is a data modeling language used to model
	state data manipulated by the Network Configuration Protocol		configuration and state data manipulated by the Network Configuration
	(NETCONF), NETCONF remote procedure calls, and NETCONF notifications		Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls, and
	[RFC6020]. Although it is extensible for more data modeling in		NETCONF notifications. Although it is extensible for more data
	addition to NETCONF, YANG is not capable of describing high level		modeling in addition to NETCONF, YANG is not capable of describing
	network requirements, such as SLA (Service Level Agreement). YANG is		high level network requirements, such as SLA (Service Level
	designed for north-bound interfaces of the device, which is also the		Agreement). YANG is designed for north-bound interfaces of the
	south-bound of the controller. It is not proper to model the north-		device, which is also the south-bound of the controller. It is not
	bound interface of the controller, aka the NBI. Moreover, the YANG		proper to model the north-bound interface of the controller, aka the
	is not capable of describing the service processing logic, which		NBI. Moreover, the YANG is not capable of describing the service
	typically includes transition of conditions and states.		processing logic, which typically includes transition of conditions
			and states.
	UML (Unified Modeling Language) is a powerful modeling language,		UML (Unified Modeling Language) is a powerful modeling language,
	which is domain agnostic. It is hard to describe the network demand,		which is domain agnostic. It is hard to describe the network demand,
	and cannot be embedded in network applications. UML is appropriate		and cannot be embedded in network applications. UML is appropriate
	to describe the model behind the NBI language not the NBI itself.		to describe the model behind the NBI language not the NBI itself.
	With the emergence of the SDN concept, it is a consensus to simplify		With the emergence of the SDN concept, it is a consensus to simplify
	the network operation, which leads to many cutting-edge explorations		the network operation, which leads to many cutting-edge explorations
	in the academic area.		in the academic area.
	skipping to change at page 5, line 26 ¶		skipping to change at page 6, line 5 ¶
	In the book [PBNM], John Strassner defined the policy concept and		In the book [PBNM], John Strassner defined the policy concept and
	proposed the formal description for network operations by using the		proposed the formal description for network operations by using the
	policy. The method for querying network information is absent in the		policy. The method for querying network information is absent in the
	book. Virtual tenant network and operations to the tenant network		book. Virtual tenant network and operations to the tenant network
	are not considered.		are not considered.
	All these investigations direct to the future SDN that use simple and		All these investigations direct to the future SDN that use simple and
	intuitive interfaces to describe the network demands without complex		intuitive interfaces to describe the network demands without complex
	programming.		programming.
	4. The NEMO Language overview		5. The NEMO Language Specifications
	NEMO language is a domain specific language (DSL) based on		NEMO language is a domain specific language (DSL) based on
	abstraction of network models and conclusion of operation patterns.		abstraction of network models and conclusion of operation patterns.
	It provides NBI fashion in the form of language. With limited number		It provides NBI fashion in the form of language. Instead of tons of
	of key words and expressions, NEMO language defines the entity and		abstruse APIs, with limited number of key words and expressions, NEMO
	capability models for users with different view of network		language enables network users/applications to describe their demands
	abstraction, and enables network users/applications to describe their		for network resources, services and logical operations in an
	demands for network resources, services and logical operations in an		intuitive way. And finally the NEMO language description can be
	intuitive expression. And finally the NEMO language description can		explained and executed by a language engine.
	be explained and executed by a language engine.
	4.1. Network Model of the NEMO Language		5.1. Network Model of the NEMO Language
	Behind the NEMO language, there is a set of meta-models abstracting		Behind the NEMO language, there is a set of basic network models
	the network demands from the top down according to the service		abstracting the network demands from the top down according to the
	requirement. Those demands can be divided into two types: the demand		service requirement. Those demands can be divided into two types:
	for network resources and the demands for network behaviors.		the demand for network resources and the demands for network
			behaviors.
	The network resource is composed of three kinds of entities: node,		The network resource is composed of three kinds of entities: node,
	link and flow. Each entity contains property and statistic		link and flow. Each entity contains property and statistic
	information. With a globally unique identifier, the network entity		information. With a globally unique identifier, the network entity
	is the basic object for operation.		is the basic object for operation.
	o Node model: describes the entity with the capability of packet		o Node model: describes the entity with the capability of packet
	processing. According to the functionality, there are three types		processing. According to the functionality, there are three types
	of node		of node
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 47 ¶
	* The processing node (PN) provides L4-7 network services, and		* The processing node (PN) provides L4-7 network services, and
	will modify the body of packets.		will modify the body of packets.
	* The logical node (LN) describes a set of network elements and		* The logical node (LN) describes a set of network elements and
	their links, such as subnet, autonomous system, and internet.		their links, such as subnet, autonomous system, and internet.
	It conceals the internal topology and exposes properties as one		It conceals the internal topology and exposes properties as one
	entity. It also enables iteration, i.e., a network entity may		entity. It also enables iteration, i.e., a network entity may
	include other network entities.		include other network entities.
	o Link model: describes the connectivity between node entities.		o Link model: describes the connectivity between node entities.
	According to the forwarding capability, links are usually divided
	into layer 2 and layer 3 types
	o Flow model: describes a sequence of packets with certain common		o Flow model: describes a sequence of packets with certain common
	characters, such as source/destination IP address, port, and		characters, such as source/destination IP address, port, and
	protocol. From the northbound perspective, flow is the special		protocol. From the northbound perspective, flow is the special
	traffic with user concern, which may be per device or across many		traffic with user concern, which may be per device or across many
	devices. So the flow characters also include ingress/egress node,		devices. So the flow characters also include ingress/egress node,
	and so on.		and so on.
	Network behavior includes the information and control operations.		Network behavior includes the information and control operations.
	skipping to change at page 6, line 50 ¶		skipping to change at page 7, line 24 ¶
	o Notification: an asynchronous mode to get the information, i.e.,		o Notification: an asynchronous mode to get the information, i.e.,
	with one request, one or multiple responses will be sent to the		with one request, one or multiple responses will be sent to the
	subscriber automatically whenever trigger conditions meet.		subscriber automatically whenever trigger conditions meet.
	The NEMO language uses policy to describe the control operation.		The NEMO language uses policy to describe the control operation.
	o Policy: control the behavior of specific entities by APP, such as		o Policy: control the behavior of specific entities by APP, such as
	flow policy, node policy. All the policies follow the same		flow policy, node policy. All the policies follow the same
	pattern "with <condition>, to execute <action>", and can be		pattern "with <condition>, to execute <action>", and can be
	applied to any entity		applied to any entity.
	4.2. Primitives		5.2. Notation
	The primitives of NEMO language are derived from the network model,		The syntactic notation used in this specification is an extended
	and fall into four categories.		version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF,
			each syntactic element of the language is defined by means of a
			production rule. This defines the element in terms of a formula
			consisting of the characters, character strings, and syntactic
			elements that can be used to form an instance of it. The version of
			BNF used in this specification makes use of the following symbols:
	a. Resource access primitives		< >
	Node/UnNode entity_id Type {FN|PN|LN}		Angle brackets delimit character strings that are the names of
	Owner node_id		syntactic elements.
	Properties key1 ,value1
	Node/UnNode: create/delete a node		::=
	Entity id: system allocated URI for the node entity
	Type: Node type of FN (forwarding node), PN (processing node)
	or LN (logical node)
	Owner: since the node can be nested, this primitive figures
	out which node the new one belongs to
	Properties: other properties to describe the node in the form of
	(key, value).
	Link/UnLink entity_id Endnodes (node1_id,node2_id)		The definition operator. This is used in a production rule to
	SLA key,value		separate the element defined by the rule from its definition. The
	Properties key1 ,value1		element being defined appears to the left of the operator and the
			formula that defines the element appears to the right.
	Link/UnLink: create/delete a link.		[ ]
	Entity id: system allocated URI for the link entity
	Endnodes: two end-node IDs of the link
	SLA: SLA description for the link
	Properties: other properties to describe the link in the form of
	(key, value).
	Flow/UnFlow entity_id Match/UnMatch key1, value1|		Square brackets indicate optional elements in a formula. The portion
	Range(value, value) |		of the formula within the brackets may be explicitly specified or may
	Mask(value, value)		be omitted.
	Properties key1 ,value1
	Flow/UnFlow: create/delete a flow.		{ }
	Match/UnMatch: create/delete match items for the flow
	Range: describe the range of the value
	Mask: use mask to describe a range of the value
	Properties: other properties to describe the flow in the form of
	(key, value).
	b. Behavior primitives		Braces group elements in a formula. The portion of the formula
	Query key Value {value}		within the braces shall be explicitly specified.
	From entity_id
	Query: generate a synchronously query		|
	key: the parameter name to be queried
	Value: the return value for the query
	From: the entity to be queried (define entity_id).
	Policy/UnPolicy policy_id Appliesto entity_id		The alternative operator. The vertical bar indicates that the
	Condition {expression}		portion of the formula following the bar is an alternative to the
	Action {"forwardto"|"drop"|"gothrough"|		portion preceding the bar. If the vertical bar appears at a position
	"bypass"|"guaranteeSLA"|"Set"|		where it is not enclosed in braces or square brackets, it specifies a
	"Packetout"|Node|UnNode|Link|Unlink}		complete alternative for the element defined by the production rule.
			If the vertical bar appears in a portion of a formula enclosed in
			braces or square brackets, it specifies alternatives for the contents
			of the innermost pair of such braces or brackets.
	Policy/UnPolicy: create/delete a policy		!!
	Appliesto: apply the policy to an entity
	Condition: condition to execute the policy
	Action: actions to be executed when conditions are met
	Notification/UnNotification entity_id On key		Introduces ordinary English text. This is used when the definition
	Every period		of a syntactic element is not expressed in BNF.
	RegisterListener
	callbackfunc
	Notification/UnNotification: create/delete a notification for an		5.3. NEMO Language Overview
	entity
	On: the notification will monitor the state change of a
	parameter identified by the "key"
	Every: time period at which to report the state
	RegisterListener: the callback function that is used to process the
	notification.
	c. Connection management primitives		NEMO language provides 5 classes of commands: model definition,
			resource access, behavior, connection management, transaction to
			facilitate the user intent description.
	Connect conn_id Address ip_address		<NEMO_cmd> := <model_definition_cmd> | <resource_access_cmd> |
	Port port_num		<behavior_cmd>
	Disconnect conn_id		<model_definition_cmd> := <node_definition> | <link_difinition> |
			<action_deifinition> | <model_description>
			<resource_access_cmd> := <node_cu> | <node_del> | <link_cu> |
			<link_del> | <flow_cu> | <flow_del>
			<behavior_cmd> := <query_cmd> | <policy_cu> | <policy_del> |
			<notification_cu> | <notification_del>
			<connection_mgt_cmd> := <connect_cmd> | <disconnect_cmd>
			<transaction_cmd> := <transaction_begin> | <transaction _end>
	Connect: set up a connection to the controller		NEMO language provides limited number of key words to enables network
	Address: IP address of the controller to connect to		users/applications to describe their intent. The key words supported
	Port: port of the controller to connect to		by the language are as follows:
	Disconnect: disconnect to the controller.
	d. Transaction primitives		<key_word> := Boolean | Integer | String | Date | UUID | EthAddr |
	Transaction		IPPrefix | NodeModel | LinkModel | FlowModel |
	Commit		ActionModel | Description | Porperty | Node | Link|
			Flow | No | EndNodes | Type | NW | Match | List |
			Range| Query | From | Notification | Listener |
			Policy | ApplyTo | Priority | Condition | Action |
			Connect | Disconnect | Address | Port | Transaction |
			Commit
	Transaction: indicate the beginning of a transaction		5.4. Model Definition
	Commit: commit to execute the transaction
	5. The NEMO Language Examples		5.4.1. Data Types
	A tenant needs two connections to carry different service flows		NEMO language provides several build-in data types:
	between two datacenters.
	one connection of the tenant is 40G bandwidth with less than 400ms		Boolean This data type is used for simple flags that track true/
	delay, another connection is 100M bandwidth with less than 50ms		false conditions. There are only two possible values: true and
	delay.		false. The Boolean literal is represented by the token <boolean>.
	{		Integer A number with an integer value, within the range from
	Link Link1_id		-(2^63) to +(2^63)-1. The Integer literal is represented by the
	Endnodes (DC1_node_id, DC2_node_id)		token <integer>.
	Property "NAME","DC1_DC2_link_one","Bandwith",40G,"Delay",400ms
	Link Link2_id
	Endnodes (DC1_node_id, DC2_node_id)
	Property "NAME","DC1_DC2_link_two","Bandwith",100M,"Delay",50ms
	}
	The tenant has two types of traffic, CDN sync traffic uses high		String A sequence of characters. The string is always in the
	bandwidth connection and online game traffic uses low latency		quotation marks. The String literal is represented by the token
	connection.		<string>.
	{		Date A string in the format yyyy-mm-dd hh:mm:ss, or yyyy-mm-dd, or
	Flow flow1_id		hh:mm:ss. The Date literal is represented by the token <date>.
	Match "srcip","10.0.1.1/24","dstip","20.0.1.1/24","Port","55555"
	Property "NAME","CDN sync flow","Bidirection","true"
	Flow flow2_id
	Match "srcip","10.0.1.1/24","dstip","20.0.1.1/24","Port","56663"
	Property "NAME","online Game","Bidirection","true"
	Policy policy1_id
	Appliesto flow1_id
	Action "forwardto",link1_id
	Policy policy2_id
	Appliesto flow2_id
	Action "gothrough",link2_id
	}
	The tenant wants the online game traffic to go through WOC in		UUID A string in the form of Universally Unique IDentifier
	nighttime before it is carried by low latency connection.		[RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A
			typical usage of the UUID is to identify network entities,
			policies, actions and so on. The UUID literal is represented by
			the token <UUID>.
	{		EthAddr A string in the form of MAC address, e.g.
	Policy policy3_id		"00:00:00:00:00:01". The EthAddr literal is represented by the
	Appliesto flow2_id		token <eth_addr>.
	Condition {Time>18:00 or Time< 2:00}
	Action "gothrough",{woc_node_id ,link2_id}
	}
	6. Security Considerations		IPPrefix A string in the form of IP address, e.g. "10.0.1.1". The
			mask can be used in the IP address description, e.g.
			"10.0.1.0/24". The IPPrefix literal is represented by the token
			<ip_prefix>.
			The token <data_type> can be defined as follows:
			<data_type> := Boolean | Integer | String | Date | UUID |
			EthAddr | IPPrefix
			And a generic <data_type> literal is represented by the token <value>
			<value> := <boolean> | <integer> | <string> | <date> | <UUID> |
			<eth_addr> | <ip_ prefix>
			5.4.2. Model Definition and Description Statement
			In addition to default build-in network models, NEMO language
			facilitates users to define new model types.
			The token <naming> is a string that must start with a letter and
			followed by any number of letters and digits. More specific naming
			can be defined as follows:
			<node_type> := <naming> !!type name of the node model
			<link_type> := <naming> !!type name of the link model
			<flow_type> := <naming> !!type name of the flow model
			<entity_type> := <node_type> | <link_type> | <flow_type>
			<action_type> := <naming> !!type name of the action model
			<model_type> := <entity_type> | <action_type>
			<property_name> := <naming> !!name of the property in a model
			The <node_definition> statement is used to create a node model:
			<node_definition> := NodeModel <node_type>
			Property { <data_type> : <property_name> };
			The NodeModel specifies a new node type.
			The Property is followed by a list of "<data_type> : <property_name>"
			pairs to specify properties for the new node type. Since belonging
			network is the intrinsic property for a node model, there is no need
			to redefine the belonging network in the property list.
			Example:
			NodeModel "DPI" Property String : "name", Boolean : "is_enable"; The
			statement generates a new node model named DPI with two properties,
			"name" and "is_enable".
			The <link_definition> statement is used to create a link model:
			<link_definition> := LinkModel <link_type>
			Property { <data_type> : <property_name> };
			The LinkModel specifies a new link type.
			The Property is followed by a list of "<data_type> : <property_name>"
			pairs to specify properties for the new link type. Since end nodes
			are intrinsic properties for a link model, there is no need to
			redefine the end nodes in the property list.
			The <flow_definition> statement is used to create a flow model:
			<flow_definition> := FlowModel <flow_type>
			Property { <data_type> : <property_name> };
			The FlowModel specifies a new flow type.
			The Property is followed by a list of "<data_type> : <property_name>"
			pairs to specify fields for the new flow type. The
			<action_definition> statement is used to create an action model:
			<action_definition> := ActionModel <action_type>
			Property { <data_type> : <property_name> };
			The ActionModel specifies a new action type.
			The Property is followed by a list of "<data_type> : <property_name>"
			pairs to specify properties for the new action.
			NEMO language also supports querying the description of a defined
			model by using the <model_description> statement:
			<model_description> := Description <model_type>;
			The keyword Description is follow by a model type name. The
			description of the queried model will return from the language
			engine.
			5.5. Resource Access Statements
			In NEMO language, each resource entity instance is identified by a
			<UUID>. We use the following token to indicate the identifier given
			to the resource entity instance.
			<node_id> := <naming> !! name to identify the node instance
			<link_id> := <naming> !! name to identify the link instance
			<flow_id> := <naming> !! name to identify the flow instance
			<entity_id> := <node_id>|<link_id>|<flow_id>
			5.5.1. Node Operations
			The <node_cu> statement is used to create or update a node instance:
			<node_cu> := Node <node_id> Type <node_type>
			NW <node_id>
			[Property {<property_name>: <value>}];
			The Node is followed by a user specified <node_id>. If the <node_id>
			is new in the system, a new node will be created automatically.
			Otherwise, the corresponding node identified by <node_id> will be
			updated with the following information.
			The Type specifies the type of the node to operate.
			The NW specifies the dependence where the node is located.
			The Property is an optional keyword followed by a list of
			"<property_name>: <value>" pairs. Multiple "<property_name>:
			<value>" pairs are separated by commas. The <property_name> must be
			selected from the property definition of the corresponding node
			definition.
			Node "switch-1"
			Type "switch"
			NW "LN-1"
			Property "ip_version" : 4;
			The statement creates a switch type node that is located in the
			logical network "LN-1".
			The <node_del> statement is used to delete a node instance:
			<node_del> := No Node <node_id>;
			The No Node is to delete a node in user's network.
			5.5.2. Link Operations
			The <link_cu> statement is used to create or update a link:
			<link_cu> := Link <link_id>
			EndNodes <node_id>, <node_id>
			[Property {<property_name>: <value>}];
			The Link is followed by a user specified <link_id>. If the <link_id>
			is new in the system, a new link will be created automatically.
			Otherwise, the corresponding link identified by the <link_id> will be
			updated with the following information.
			The EndNodes specifies the two end nodes, identified by "<node_type>
			: <node_id>", of a link. The Property is an optional keyword
			followed by a list of "<property_name>: <value>" pairs. Multiple
			"<property_name>: <value>" pairs are separated by commas. The
			<property_name> must be selected from the property definition of the
			corresponding link definition.
			Example:
			Link "link-1"
			EndNodes "S1", "S2"
			Property "bandwidth" : 1000, "delay" : 40;
			The statement creates a link between two nodes, and sets the link
			property.
			The <link_del> statement is used to delete a node instance:
			<link_del> := No Link <link_id>;
			The No Link is to delete a link in user's network.
			5.5.3. Flow Operations
			The <flow_cu> statement is used to create or update a flow:
			<flow_cu> := Flow <flow_id> Match {<property_name>: <value>
			| Range (<value>, <value>)
			| List({<value>})}
			The Flow is followed by a user defined <flow_id>. If the <flow_id>
			is new in the system, a new flow will be created automatically.
			Otherwise, the corresponding flow identified by the <flow_id> will be
			updated with the following information.
			The Match specifies a flow by indicate match fields. NEMO language
			also provides two keywords to assist the expression of values:
			o The List is used to store a collection of data with the same data
			type.
			o The Range is used to express a range of values.
			Example:
			Flow "flow-1"
			Match "src_ip" : Range ("192.168.1.1", "192.168.1.243");
			The statement describes a flow with the source IP address ranging
			from 192.168.1.1 to 192.168.1.243.
			The <link_del> statement is used to delete a flow instance:
			<flow_del> := No Flow <flow_id>;
			The No Flow is to delete a flow in user's network.
			5.6. Behavior Statements
			5.6.1. Query Behavior
			The query statement is to retrieve selected data from specified model
			object.
			The <query_statement> generate a query:
			<query_cmd> := Query {<property_name>}
			From {<entity_id>|<policy_id>}
			The Query is followed by one or more <property_name>s which are
			defined properties of the object to be queried.
			The From is followed by the one or more queried objects. NENO
			language support query operation to network entities and the policy.
			5.6.2. Policy Behavior
			In NEMO language, each policy instance is identified by a <naming>
			<policy_id> := <naming> !! name to identify the policy instance
			Create and update a policy
			<policy_cu> := Policy <policy_id> ApplyTo <entity_id>
			Priority <integer>
			[Condition {<expression>}]
			Action {<action_type> : {<value>}};
			The Policy is followed by a user defined <policy_id>. If the
			<policy_id> is new in the system, a new policy will be created
			automatically. Otherwise, the corresponding notification identified
			by the <policy_id> will be updated with the following information.
			The ApplyTo specifies the entity to which the policy will apply.
			The Priority specifies the globe priority of the policy in the tenant
			name space. The <value> with lower number has a higher priority,
			i.e. priority 0 holds the highest priority.
			The Condition is an optional keyword follow by an expression. It
			tells your program to execute the following actions only if a
			particular test described by the expression evaluates to true. A
			NEMO language expression is a construct made up of variables,
			operators, and method invocations, which are constructed according to
			the syntax of the language and evaluates to a single value. NEMO
			language supports many operators to facilitate the construction of
			expressions. Assume variable A holds 10 and variable B holds 0,
			then:
			+----------+----------------------------------------------+---------+
			| Operator | Description | Example |
			+----------+----------------------------------------------+---------+
			| && | Called Logical AND operator. If both the | (A && |
			| | operands are non-zero, then the condition | B) is |
			| | becomes true. | false. |
			| || | Called Logical OR Operator. If any of the | (A || |
			| | two operands are non-zero, then the | B) is |
			| | condition becomes true. | true. |
			| ! | Called Logical NOT Operator. Use to reverses | !(A && |
			| | the logical state of its operand. If a | B) is |
			| | condition is true then Logical NOT operator | true. |
			| | will make false. | |
			| == | Checks if the values of two operands are | (A == |
			| | equal or not, if yes then condition becomes | B) is |
			| | true. | not |
			| | | true. |
			| != | Checks if the values of two operands are | (A != |
			| | equal or not, if values are not equal then | B) is |
			| | condition becomes true. | true. |
			| > | Checks if the value of left operand is | (A > B) |
			| | greater than the value of right operand, if | is not |
			| | yes then condition becomes true. | true. |
			| >= | Checks if the value of left operand is | (A >= |
			| | greater than or equal to the value of right | B) is |
			| | operand, if yes then condition becomes true. | not |
			| | | true. |
			| < | Checks if the value of left operand is less | (A < B) |
			| | than the value of right operand, if yes then | is |
			| | condition becomes true. | true. |
			| <= | Checks if the value of left operand is less | (A <= |
			| | than or equal to the value of right operand, | B) is |
			| | if yes then condition becomes true. | true. |
			+----------+----------------------------------------------+---------+
			The Action specifies the execution when conditions meet.
			Example:
			Policy "policy-1"
			ApplyTo "flow-1"
			Priority 100
			Condition ("time">"18:00") || ("time"<"21:00")
			Action "gothrough" : List( "switch-1" , "switch-2");
			The statement creates a policy which indicates the flow to go through
			two specified switches from 18:00 to 21:00.
			Delete a policy:
			<policy_del> := No Policy <policy_id>;
			The No Policy is to delete a policy in user's network.
			5.6.3. Notification Behavior
			In NEMO language, each notification instance is identified by a
			<naming>
			<notification_id> := <naming> !! name to identify the notification
			instance
			Create and update a notification
			<notification_cu> := Notification <notification_id>
			[(Query {<property_name>}
			From {<entity_id>})]
			Condition {<expression>}
			Listener <callbackfunc>;
			The Notification is followed by a user defined <notification_id>. If
			the <notification_id> is new in the system, a new notificaiton will
			be created automatically. Otherwise, the corresponding notification
			identified by the <notification_id> will be updated with the
			following information.
			The Query clause is nested in the notification statement to indicate
			the information acquisition.
			The Condition clause is the same as in policy statement, which
			triggers the notification.
			The Listener specifies the callback function that is used to process
			the notification.
			Delete a notification:
			<notification_del> := No Notification <notification_id>;
			The No Notification is to delete a notification in user's network.
			5.7. Connection Management Statements
			In NEMO language, each connection instance is identified by a
			<naming>
			<conn_id> := <naming> !! name to identify the connection instance
			Setup a connection to the NEMO language engine:
			<connet_cmd> := Connect <conn_id> Address <ip_prefix>
			Port <integer>
			The Connect is followed by a user defined <conn_id>. If the
			<conn_id> is new in the system, a new connection will be created
			automatically. Otherwise, the corresponding connection identified by
			<conn_id> will be updated with the following information.
			The Address and Prot specify the IP address and the port of the NEMO
			language engine to connect separately.
			Disconnect the connection to the NEMO language engine:
			<disconnect_cmd> := Disconnect <conn_id>
			The Disconnect is to remove the connection with an ID equals to
			<conn_id> from the NEMO language engine.
			5.8. Transaction Statements
			<transaction_begin> := Transaction
			<transaction_end> := Commit
			The keywords Transaction and Commit are used to tag begin and end of
			a transaction. The code between the two key words will be
			interpreted as a transaction and executed by the NEMO language
			engine.
			6. The NEMO Language Examples
			An enterprise with geographically distributed headquarter and branch
			sites has the requirement to dynamically balance the backup traffic.
			In order to implement this scenario, the virtual WAN tenant creates
			two routers, and generates two links with different SLA to carry
			diverse service flows. One link has 100M bandwidth with less than
			50ms delay, which is used for normal traffic. And the other link has
			40G bandwidth with less than 400ms delay, which is used for backup
			traffic after work (from 19:00 to 23:00). With self defined flow
			policy, the tenant can manage the link load balancing conveniently.
			Real-time Link
			+-------------+
			10.0.1.0/24 | | 20.0.1.0/24
			+---------+ +----+ +----+ +-------------+
			| Branch |------| R1 | | R2 |------| Headquarter |
			+---------+ +----+ +----+ +-------------+
			| |
			+-------------+
			Broadband Link
			The detailed operation and code are shown as follows.
			o Step1: Create two virtual switch nodes in the WAN
			Node "R1"
			Type "router"
			NW "LN-1"
			Property "ip_version" : 4;
			Node "R2"
			Type "router"
			NW "LN-1"
			Property "ip_version" : 4;
			o Step2: Connect the two virtual nodes with two virtual links with
			different SLA.
			Link "broadband_link"
			EndNodes "R1", "R2"
			Property "bandwidth" : 40000, "delay" : 400;
			Link "realtime_link"
			EndNodes "R1", "R2"
			Property "bandwidth" : 100, "delay" : 50;
			o Step3: Indicate the flow to be operated.
			Flow "flow_all"
			Match "src_ip" : "10.0.1.0/24", "dst_ip": "10.0.1.0/24";
			Flow "flow_backup"
			Match "src_ip" : "10.0.1.0/24", "dst_ip": "20.0.1.0/24",
			"port": 55555;
			o Step4: Apply policies to corresponding flows.
			P1:
			Policy "policy4all"
			ApplyTo "flow_all"
			Priority 200
			Action "forward_to": "realtime_link";
			P2:
			Policy "policy4backup"
			ApplyTo "flow_backup"
			Priority 100
			Condition ("time">"19:00:00") || ("time"<"23:00:00")
			Action "forward_to": "broadband_link";
			7. Security Considerations
	Because the network customers are allowed to customize their own		Because the network customers are allowed to customize their own
	services, they may bring potentially big impacts to a running IP		services, they may bring potentially big impacts to a running IP
	network. A strong user authentication mechanism is needed for the		network. A strong user authentication mechanism is needed for the
	northbound interface of the SDN controller. User authorization		northbound interface of the SDN controller. User authorization
	should be carefully managed by the network administrator to avoid any		should be carefully managed by the network administrator to avoid any
	dangerous operations and prevent any abuse of network resources.		dangerous operations and prevent any abuse of network resources.
	7. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	8. Acknowledgements		9. Acknowledgements
	The authors would like to thanks the valuable comments made by Wei		The authors would like to thanks the valuable comments made by Wei
	Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei.		Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	9. Informative References		10. Informative References
	[Frenetic]		[Frenetic]
	Foster, N., Harrison, R., Freedman, M., Monsanto, C.,		Foster, N., Harrison, R., Freedman, M., Monsanto, C.,
	Rexford, J., Story, A., and D. Walker, "Frenetic: A		Rexford, J., Story, A., and D. Walker, "Frenetic: A
	Network Programming Languages, ICFP' 11", .		Network Programming Languages, ICFP' 11", .
	[I-D.sdnrg-service-description-language]		[I-D.sdnrg-service-description-language]
	Xia, Y., Jiang, S., and S. Hares, "Requirements for a		Xia, Y., Jiang, S., and S. Hares, "Requirements for a
	Service Description Language and Design Considerations,		Service Description Language and Design Considerations,
	draft-xia-sdnrg-service-description-language-00, Work in		draft-xia-sdnrg-service-description-language-00, Work in
	skipping to change at page 11, line 8 ¶		skipping to change at page 21, line 11 ¶
	[PBNM] Strassner, J., "Policy-Based Network Management: Solutions		[PBNM] Strassner, J., "Policy-Based Network Management: Solutions
	for the Next Generation, Morgan Kaufmann Publishers Inc.		for the Next Generation, Morgan Kaufmann Publishers Inc.
	San Francisco, CA, USA.", 2003.		San Francisco, CA, USA.", 2003.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		June 1999.
			[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
			Unique IDentifier (UUID) URN Namespace", RFC 4122, July
			2005.
	[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		October 2010.
			[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
			Bierman, "Network Configuration Protocol (NETCONF)", RFC
			6241, June 2011.
	[TSFNet] Yap, K., Huang, T., Dodson, B., Lam, M., and N. McKeown,		[TSFNet] Yap, K., Huang, T., Dodson, B., Lam, M., and N. McKeown,
	"Towards Software-Friendly Networks, APSys 2010, pp:49-54,		"Towards Software-Friendly Networks, APSys 2010, pp:49-54,
	2010, New Delhi, India.", .		2010, New Delhi, India.", .
	Authors' Addresses		Authors' Addresses
	Yinben Xia (editor)		Yinben Xia (editor)
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Q14, Huawei Campus, No.156 Beiqing Road		Q14, Huawei Campus, No.156 Beiqing Road
	Hai-Dian District, Beijing, 100095		Hai-Dian District, Beijing, 100095
End of changes. 57 change blocks.
	214 lines changed or deleted		669 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/