< draft-xia-sdnrg-nemo-language-01.txt		draft-xia-sdnrg-nemo-language-02.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: April 30, 2015 S. Hares		Expires: November 5, 2015 S. Hares
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	October 27, 2014		May 4, 2015
	NEMO (NEtwork MOdeling) Language		NEMO (NEtwork MOdeling) Language
	draft-xia-sdnrg-nemo-language-01		draft-xia-sdnrg-nemo-language-02
	Abstract		Abstract
	The North-Bound Interface (NBI), located between the control plane		The North-Bound Interface (NBI), located between the control 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 intent based		proposes the NEtwork MOdeling (NEMO) language which is intent based
	interface with novel language fashion. Concept, model and syntax are		interface with novel language fashion. Concept, model and syntax are
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 April 30, 2015.		This Internet-Draft will expire on November 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. The NEMO Language Specifications . . . . . . . . . . . . . . 6		5. The NEMO Language Specifications . . . . . . . . . . . . . . 6
	5.1. Network Model of the NEMO Language . . . . . . . . . . . 6		5.1. Network Model of the NEMO Language . . . . . . . . . . . 6
	5.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. NEMO Language Overview . . . . . . . . . . . . . . . . . 8		5.3. NEMO Language Overview . . . . . . . . . . . . . . . . . 8
	5.4. Model Definition . . . . . . . . . . . . . . . . . . . . 9		5.4. Model Definition . . . . . . . . . . . . . . . . . . . . 9
	5.4.1. Data Types . . . . . . . . . . . . . . . . . . . . . 9		5.4.1. Data Types . . . . . . . . . . . . . . . . . . . . . 9
	5.4.2. Model Definition and Description Statement . . . . . 10		5.4.2. Model Definition and Description Statement . . . . . 10
	5.5. Resource Access Statements . . . . . . . . . . . . . . . 11		5.5. Resource Access Statements . . . . . . . . . . . . . . . 11
	5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12		5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12
	5.5.2. Link Operations . . . . . . . . . . . . . . . . . . . 12		5.5.2. Connection Operations . . . . . . . . . . . . . . . . 12
	5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 13		5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 13
	5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 14		5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 14
	5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 14		5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 14
	5.6.2. Policy Behavior . . . . . . . . . . . . . . . . . . . 14		5.6.2. Policy Behavior . . . . . . . . . . . . . . . . . . . 14
	5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 17		5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 17
	5.7. Connection Management Statements . . . . . . . . . . . . 17		5.7. Connection Management Statements . . . . . . . . . . . . 17
	5.8. Transaction Statements . . . . . . . . . . . . . . . . . 18		5.8. Transaction Statements . . . . . . . . . . . . . . . . . 18
	6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 18		6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	express user intent and 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		To implement such an NBI design, we can learn from the successful
	case of SQL (Structured Query Language), which simplified the		case of SQL (Structured Query Language), which simplified the
	complicated data operation to a unified and intuitive way in the form		complicated data operation to a unified and intuitive way in the form
	of language. Applications do not care about the way of data storage		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 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		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		simple and intuitive, and can be embedded in applications. So what
	we need for the network NBI is a set of "network domain SQL".		we need for the network NBI is a set of "network domain SQL".
	[I-D.sdnrg-service-description-language] describe the requirements		[I-D.xia-sdnrg-service-description-language] describe the
	for a service description language and the design considerations.		requirements for a service description language and the design
			considerations.
	This document will introduce an intent based NBI with novel language		This document will introduce an intent based NBI with novel language
	fashion.		fashion.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] when they appear in ALL CAPS. When these words are not in		[RFC2119] when they appear in ALL CAPS. When these words are not in
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 14 ¶
	Network user also "user" for short, is the network administrator or		Network user also "user" for short, is the network administrator or
	operator.		operator.
	3. Requirements for the Intent Based NBI Language		3. Requirements for the Intent Based NBI Language
	An intent based NBI language design contains following features:		An intent based NBI language design contains following features:
	o Express user intent		o Express user intent
	To simply the operation, applications or users can use the NBI		To simplify 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 description of network		With the NBI, the application or user can description of network
	demand in a generic way, so that any platform or system can get		demand in a generic way, so that any platform or system can get
	the identical knowledge and consequently execute to the same		the identical knowledge and consequently execute to the same
	result. Any low-level and device/vendor specific configurations		result. Any low-level and device/vendor specific configurations
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	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 the NBI language should be declarative rather than		operators. So the NBI language should be declarative rather than
	imperative.		imperative.
	4. Related work		4. Related work
	YANG [RFC6020] is a data modeling language used to model		YANG [RFC6020] is a data modeling language used to model
	configuration and state data manipulated by the Network Configuration		configuration and state data manipulated by the Network Configuration
	Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls, and		Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls, and
	NETCONF notifications. Although it is extensible for more data		NETCONF notifications.
	modeling in addition to NETCONF, YANG is not capable of describing
	high level network requirements, such as SLA (Service Level
	Agreement). YANG is designed for north-bound interfaces of the
	device, which is also the south-bound of the controller. It is not
	proper to model the north-bound interface of the controller, aka the
	NBI. Moreover, the YANG is not capable of describing the service
	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. YANG and UML all focus on syntax
	and cannot be embedded in network applications. UML is appropriate		specification which formulate grammatical structure of NBI language,
	to describe the model behind the NBI language not the NBI itself.		however, they do not have the ability to express users' real
			semantics. NBI language should facilitate users to express their own
			intent explicitly, instead of general complying with grammar syntax.
			So YANG and UML is appropriate 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.
	Nick McKeown from Stanford University proposed the SFNet [TSFNet],		Nick McKeown from Stanford University proposed the SFNet [TSFNet],
	which translated the high level network demand to the underlying		which translated the high level network demand to the underlying
	controller interfaces. By concealing the low level network details,		controller interfaces. By concealing the low level network details,
	the controller simplified the operation of resource, flow, and		the controller simplified the operation of resource, flow, and
	information for applications. The SFNet is used for the SDN		information for applications. The SFNet is used for the SDN
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	5.1. Network Model of the NEMO Language		5.1. Network Model of the NEMO Language
	Behind the NEMO language, there is a set of basic network models		Behind the NEMO language, there is a set of basic network models
	abstracting the network demands from the top down according to the		abstracting the network demands from the top down according to the
	service requirement. Those demands can be divided into two types:		service requirement. Those demands can be divided into two types:
	the demand for network resources and the demands for network		the demand for network resources and the demands for network
	behaviors.		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		connection 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. Users can construct their own
			topology or network traffic arbitrarily with these basic objects
			without considering about real physical topology. In addition, NEMO
			Engine also has the ability of obtaining available resources
			automatically as operation objects when users don't define them.
	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 two types
	of node		of node
	* The forwarding node (FN) only deals with L2/3 forwarding. It		* The function node (FN) provides network services or forwarding
	forwards packets according to the forwarding table and modifies		with user concern, such as, firewall, load balance, vrouter,
	packet heads.		etc.
	* The processing node (PN) provides L4-7 network services, and
	will modify the body of packets.
	* The logical node (LN) describes a set of network elements and		* The business node (BN) describes a set of network elements and
	their links, such as subnet, autonomous system, and internet.		their connections, such as subnet, autonomous system, and
	It conceals the internal topology and exposes properties as one		internet. It conceals the internal topology and exposes
	entity. It also enables iteration, i.e., a network entity may		properties as one entity. It also enables iteration, i.e., a
	include other network entities.		network entity may include other network entities.
	o Link model: describes the connectivity between node entities.		o Connection model: describes the connectivity between node
			entities. This connection is not limited at the connectivity
			between single entity and single entity, but it also can express
			the connectivity between single entity and multiply entities, or
			multiply entities and multiply entities.
	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 7, line 23 ¶		skipping to change at page 7, line 28 ¶
	get the response when a request is sent out.		get the response when a request is sent out.
	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 "when <condition>, to execute <action>, with
	applied to any entity.		<constraint>", and can be applied to any entity. But some of
			policy elements can be omitted according to users' requirement.
	5.2. Notation		5.2. Notation
	The syntactic notation used in this specification is an extended		The syntactic notation used in this specification is an extended
	version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF,		version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF,
	each syntactic element of the language is defined by means of a		each syntactic element of the language is defined by means of a
	production rule. This defines the element in terms of a formula		production rule. This defines the element in terms of a formula
	consisting of the characters, character strings, and syntactic		consisting of the characters, character strings, and syntactic
	elements that can be used to form an instance of it. The version of		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:		BNF used in this specification makes use of the following symbols:
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 38 ¶
	Introduces ordinary English text. This is used when the definition		Introduces ordinary English text. This is used when the definition
	of a syntactic element is not expressed in BNF.		of a syntactic element is not expressed in BNF.
	5.3. NEMO Language Overview		5.3. NEMO Language Overview
	NEMO language provides 5 classes of commands: model definition,		NEMO language provides 5 classes of commands: model definition,
	resource access, behavior, connection management, transaction to		resource access, behavior, connection management, transaction to
	facilitate the user intent description.		facilitate the user intent description.
	<NEMO_cmd> := <model_definition_cmd> | <resource_access_cmd> |		<NEMO_cmd> := <model_definition_cmd> | <resource_access_cmd> |
	<behavior_cmd>		<behavior_cmd>
	<model_definition_cmd> := <node_definition> | <link_difinition> |		<model_definition_cmd> := <node_definition> | <connection_difinition> |
	<action_deifinition> | <model_description>		<action_deifinition> | <model_description>
	<resource_access_cmd> := <node_cu> | <node_del> | <link_cu> |		<resource_access_cmd> := <node_cu> | <node_del> | <connection_cu> |
	<link_del> | <flow_cu> | <flow_del>		<connection_del> | <flow_cu> | <flow_del>
	<behavior_cmd> := <query_cmd> | <policy_cu> | <policy_del> |		<behavior_cmd> := <query_cmd> | <policy_cu> | <policy_del> |
	<notification_cu> | <notification_del>		<notification_cu> | <notification_del>
	<connection_mgt_cmd> := <connect_cmd> | <disconnect_cmd>		<connection_mgt_cmd> := <connect_cmd> | <disconnect_cmd>
	<transaction_cmd> := <transaction_begin> | <transaction _end>		<transaction_cmd> := <transaction_begin> | <transaction _end>
	NEMO language provides limited number of key words to enables network		NEMO language provides limited number of key words to enables network
	users/applications to describe their intent. The key words supported		users/applications to describe their intent. The key words supported
	by the language are as follows:		by the language are as follows:
	<key_word> := Boolean | Integer | String | Date | UUID | EthAddr |		<key_word> := Boolean | Integer | String | Date | UUID | EthAddr |
	IPPrefix | NodeModel | LinkModel | FlowModel |		IPPrefix | NodeModel | ConnectionModel | FlowModel |
	ActionModel | Description | Porperty | Node | Link|		ActionModel | Description | Porperty | Node | Connection|
	Flow | No | EndNodes | Type | NW | Match | List |		Flow | No | EndNodes | Type | NW | Match | List |
	Range| Query | From | Notification | Listener |		Range| Query | From | Notification | Listener |
	Policy | ApplyTo | Priority | Condition | Action |		Policy | ApplyTo | Priority | Condition | Action |
	Connect | Disconnect | Address | Port | Transaction |		Connect | Disconnect | Address | Port | Transaction |
	Commit		Commit
	5.4. Model Definition		5.4. Model Definition
	5.4.1. Data Types		5.4.1. Data Types
	NEMO language provides several build-in data types:		NEMO language provides several build-in data types:
	Boolean This data type is used for simple flags that track true/		Boolean This data type is used for simple flags that track true/
	false conditions. There are only two possible values: true and		false conditions. There are only two possible values: true and
	false. The Boolean literal is represented by the token <boolean>.		false. The Boolean literal is represented by the token <boolean>.
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	UUID A string in the form of Universally Unique IDentifier		UUID A string in the form of Universally Unique IDentifier
	[RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A		[RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A
	typical usage of the UUID is to identify network entities,		typical usage of the UUID is to identify network entities,
	policies, actions and so on. The UUID literal is represented by		policies, actions and so on. The UUID literal is represented by
	the token <UUID>.		the token <UUID>.
	EthAddr A string in the form of MAC address, e.g.		EthAddr A string in the form of MAC address, e.g.
	"00:00:00:00:00:01". The EthAddr literal is represented by the		"00:00:00:00:00:01". The EthAddr literal is represented by the
	token <eth_addr>.		token <eth_addr>.
	IPPrefix A string in the form of IP address, e.g. "10.0.1.1". The		IPPrefix A string in the form of IP address, e.g. "192.0.2.1". The
	mask can be used in the IP address description, e.g.		mask can be used in the IP address description, e.g.
	"10.0.1.0/24". The IPPrefix literal is represented by the token		"192.0.2.0/24". The IPPrefix literal is represented by the token
	<ip_prefix>.		<ip_prefix>.
	The token <data_type> can be defined as follows:		The token <data_type> can be defined as follows:
	<data_type> := Boolean | Integer | String | Date | UUID |		<data_type> := Boolean | Integer | String | Date | UUID |
	EthAddr | IPPrefix		EthAddr | IPPrefix
	And a generic <data_type> literal is represented by the token <value>		And a generic <data_type> literal is represented by the token <value>
	<value> := <boolean> | <integer> | <string> | <date> | <UUID> |		<value> := <boolean> | <integer> | <string> | <date> | <UUID> |
	<eth_addr> | <ip_ prefix>		<eth_addr> | <ip_ prefix>
	5.4.2. Model Definition and Description Statement		5.4.2. Model Definition and Description Statement
	In addition to default build-in network models, NEMO language		In addition to default build-in network models, NEMO language
	facilitates users to define new model types.		facilitates users to define new model types.
	The token <naming> is a string that must start with a letter and		The token <naming> is a string that MUST start with a letter and
	followed by any number of letters and digits. More specific naming		followed by any number of letters and digits. More specific naming
	can be defined as follows:		can be defined as follows:
	<node_type> := <naming> !!type name of the node model		<node_type> := <naming> !!type name of the node model
	<link_type> := <naming> !!type name of the link model		<connection_type> := <naming> !!type name of the connection model
	<flow_type> := <naming> !!type name of the flow model		<flow_type> := <naming> !!type name of the flow model
	<entity_type> := <node_type> | <link_type> | <flow_type>		<entity_type> := <node_type> | <connection_type> | <flow_type>
	<action_type> := <naming> !!type name of the action model		<action_type> := <naming> !!type name of the action model
	<model_type> := <entity_type> | <action_type>		<model_type> := <entity_type> | <action_type>
	<property_name> := <naming> !!name of the property in a model		<property_name> := <naming> !!name of the property in a model
	The <node_definition> statement is used to create a node model:		The <node_definition> statement is used to create a node model:
	<node_definition> := NodeModel <node_type>		<node_definition> := NodeModel <node_type>
	Property { <data_type> : <property_name> };		Property { <data_type> : <property_name> };
	The NodeModel specifies a new node type.		The NodeModel specifies a new node type.
	skipping to change at page 10, line 48 ¶		skipping to change at page 10, line 48 ¶
	pairs to specify properties for the new node type. Since belonging		pairs to specify properties for the new node type. Since belonging
	network is the intrinsic property for a node model, there is no need		network is the intrinsic property for a node model, there is no need
	to redefine the belonging network in the property list.		to redefine the belonging network in the property list.
	Example:		Example:
	NodeModel "DPI" Property String : "name", Boolean : "is_enable"; The		NodeModel "DPI" Property String : "name", Boolean : "is_enable"; The
	statement generates a new node model named DPI with two properties,		statement generates a new node model named DPI with two properties,
	"name" and "is_enable".		"name" and "is_enable".
	The <link_definition> statement is used to create a link model:		The <connection_definition> statement is used to create a connection
			model:
	<link_definition> := LinkModel <link_type>		<connection_definition> := ConnectionModel <connection_type>
	Property { <data_type> : <property_name> };		Property { <data_type> : <property_name> };
	The LinkModel specifies a new link type.		The ConnectionModel specifies a new connection type.
	The Property is followed by a list of "<data_type> : <property_name>"		The Property is followed by a list of "<data_type> : <property_name>"
	pairs to specify properties for the new link type. Since end nodes		pairs to specify properties for the new connection type. Since end
	are intrinsic properties for a link model, there is no need to		nodes are intrinsic properties for a connection model, there is no
	redefine the end nodes in the property list.		need to redefine the end nodes in the property list.
	The <flow_definition> statement is used to create a flow model:		The <flow_definition> statement is used to create a flow model:
	<flow_definition> := FlowModel <flow_type>		<flow_definition> := FlowModel <flow_type>
	Property { <data_type> : <property_name> };		Property { <data_type> : <property_name> };
	The FlowModel specifies a new flow type.		The FlowModel specifies a new flow type.
	The Property is followed by a list of "<data_type> : <property_name>"		The Property is followed by a list of "<data_type> : <property_name>"
	pairs to specify fields for the new flow type. The		pairs to specify fields for the new flow type. The
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	The keyword Description is follow by a model type name. The		The keyword Description is follow by a model type name. The
	description of the queried model will return from the language		description of the queried model will return from the language
	engine.		engine.
	5.5. Resource Access Statements		5.5. Resource Access Statements
	In NEMO language, each resource entity instance is identified by a		In NEMO language, each resource entity instance is identified by a
	<UUID>. We use the following token to indicate the identifier given		<UUID>. We use the following token to indicate the identifier given
	to the resource entity instance.		to the resource entity instance.
	<node_id> := <naming> !! name to identify the node instance		<node_id> := <naming> !! name to identify the node instance
	<link_id> := <naming> !! name to identify the link instance		<connection_id> := <naming> !! name to identify the connection instance
	<flow_id> := <naming> !! name to identify the flow instance		<flow_id> := <naming> !! name to identify the flow instance
	<entity_id> := <node_id>|<link_id>|<flow_id>		<entity_id> := <node_id>|<connection_id>|<flow_id>
	5.5.1. Node Operations		5.5.1. Node Operations
	The <node_cu> statement is used to create or update a node instance:		The <node_cu> statement is used to create or update a node instance:
	<node_cu> := Node <node_id> Type <node_type>		<node_cu> := Node <node_id> Type <node_type>
	NW <node_id>		NW <node_id>
	[Property {<property_name>: <value>}];		[Property {<property_name>: <value>}];
	The Node is followed by a user specified <node_id>. If the <node_id>		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.		is new in the system, a new node will be created automatically.
	Otherwise, the corresponding node identified by <node_id> will be		Otherwise, the corresponding node identified by <node_id> will be
	updated with the following information.		updated with the following information.
	The Type specifies the type of the node to operate.		The Type specifies the type of the node to operate.
	The NW specifies the dependence where the node is located.		The NW specifies the dependence where the node is located.
	The Property is an optional keyword followed by a list of		The Property is an optional keyword followed by a list of
	"<property_name>: <value>" pairs. Multiple "<property_name>:		"<property_name>: <value>" pairs. Multiple "<property_name>:
	<value>" pairs are separated by commas. The <property_name> must be		<value>" pairs are separated by commas. The <property_name> MUST be
	selected from the property definition of the corresponding node		selected from the property definition of the corresponding node
	definition.		definition.
	Node "switch-1"		Node "Headquater"
	Type "switch"		Type "logicnw"
	NW "LN-1"		NW "LN-1"
	Property "ip_version" : 4;		Property "location" : "Beijing";
	The statement creates a switch type node that is located in the		The statement creates a switch type node that is located in the
	logical network "LN-1".		logical network "LN-1".
	The <node_del> statement is used to delete a node instance:		The <node_del> statement is used to delete a node instance:
	<node_del> := No Node <node_id>;		<node_del> := No Node <node_id>;
	The No Node is to delete a node in user's network.		The No Node is to delete a node in user's network.
	5.5.2. Link Operations		5.5.2. Connection Operations
	The <link_cu> statement is used to create or update a link:		The <connection_cu> statement is used to create or update a
			connection:
	<link_cu> := Link <link_id>		<connection_cu> := Connection <connection_id>
	EndNodes <node_id>, <node_id>		EndNodes <node_id>, <node_id>
	[Property {<property_name>: <value>}];		[Property {<property_name>: <value>}];
	The Link is followed by a user specified <link_id>. If the <link_id>		The Connection is followed by a user specified <connection_id>. If
	is new in the system, a new link will be created automatically.		the <connection_id> is new in the system, a new connection will be
			created automatically. Otherwise, the corresponding connection
	Otherwise, the corresponding link identified by the <link_id> will be		identified by the <connection_id> will be updated with the following
	updated with the following information.		information.
	The EndNodes specifies the two end nodes, identified by "<node_type>		The EndNodes specifies the two end nodes, identified by "<node_type>
	: <node_id>", of a link. The Property is an optional keyword		: <node_id>", of a connection. The Property is an optional keyword
	followed by a list of "<property_name>: <value>" pairs. Multiple		followed by a list of "<property_name>: <value>" pairs. Multiple
	"<property_name>: <value>" pairs are separated by commas. The		"<property_name>: <value>" pairs are separated by commas. The
	<property_name> must be selected from the property definition of the		<property_name> MUST be selected from the property definition of the
	corresponding link definition.		corresponding connection definition.
	Example:		Example:
	Link "link-1"		Connection "connection-1"
	EndNodes "S1", "S2"		EndNodes "S1", "S2"
	Property "bandwidth" : 1000, "delay" : 40;		Property "bandwidth" : 1000, "delay" : 40;
	The statement creates a link between two nodes, and sets the link		The statement creates a connection between two nodes, and sets the
	property.		connection property.
	The <link_del> statement is used to delete a node instance:		The <connection_del> statement is used to delete a node instance:
	<link_del> := No Link <link_id>;		<connection_del> := No Connection <connection_id>;
	The No Link is to delete a link in user's network.		The No Connection is to delete a connection in user's network.
	5.5.3. Flow Operations		5.5.3. Flow Operations
	The <flow_cu> statement is used to create or update a flow:		The <flow_cu> statement is used to create or update a flow:
	<flow_cu> := Flow <flow_id> Match {<property_name>: <value>		<flow_cu> := Flow <flow_id> Match {<property_name>: <value>
	| Range (<value>, <value>)		| Range (<value>, <value>)
	| List({<value>})}		| List({<value>})}
	The Flow is followed by a user defined <flow_id>. If the <flow_id>		The Flow is followed by a user defined <flow_id>. If the <flow_id>
	skipping to change at page 14, line 6 ¶		skipping to change at page 14, line 6 ¶
	also provides two keywords to assist the expression of values:		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		o The List is used to store a collection of data with the same data
	type.		type.
	o The Range is used to express a range of values.		o The Range is used to express a range of values.
	Example:		Example:
	Flow "flow-1"		Flow "flow-1"
	Match "src_ip" : Range ("192.168.1.1", "192.168.1.243");		Match "src_ip" : Range ("192.0.2.1", "192.0.2.243");
	The statement describes a flow with the source IP address ranging		The statement describes a flow with the source IP address ranging
	from 192.168.1.1 to 192.168.1.243.		from 192.0.2.1 to 192.0.2.243.
	The <link_del> statement is used to delete a flow instance:		The <flow_del> statement is used to delete a flow instance:
	<flow_del> := No Flow <flow_id>;		<flow_del> := No Flow <flow_id>;
	The No Flow is to delete a flow in user's network.		The No Flow is to delete a flow in user's network.
	5.6. Behavior Statements		5.6. Behavior Statements
	5.6.1. Query Behavior		5.6.1. Query Behavior
	The query statement is to retrieve selected data from specified model		The query statement is to retrieve selected data from specified model
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	In NEMO language, each policy instance is identified by a <naming>		In NEMO language, each policy instance is identified by a <naming>
	<policy_id> := <naming> !! name to identify the policy instance		<policy_id> := <naming> !! name to identify the policy instance
	Create and update a policy		Create and update a policy
	<policy_cu> := Policy <policy_id> ApplyTo <entity_id>		<policy_cu> := Policy <policy_id> ApplyTo <entity_id>
	Priority <integer>		Priority <integer>
	[Condition {<expression>}]		[Condition {<expression>}]
	Action {<action_type> : {<value>}};		Action {<action_type> : {<value>}}
			[Constraint {<expression>}];
	The Policy is followed by a user defined <policy_id>. If the		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		<policy_id> is new in the system, a new policy will be created
	automatically. Otherwise, the corresponding notification identified		automatically. Otherwise, the corresponding notification identified
	by the <policy_id> will be updated with the following information.		by the <policy_id> will be updated with the following information.
	The ApplyTo specifies the entity to which the policy will apply.		The ApplyTo specifies the entity to which the policy will apply.
	The Priority specifies the globe priority of the policy in the tenant		The Priority specifies the globe priority of the policy in the tenant
	name space. The <value> with lower number has a higher priority,		name space. The <value> with lower number has a higher priority,
	i.e. priority 0 holds the highest priority.		i.e. priority 0 holds the highest priority.
	The Condition is an optional keyword follow by an expression. It		The Condition is an optional keyword follow by an expression. It
	tells your program to execute the following actions only if a		tells your program to execute the following actions only if a
	particular test described by the expression evaluates to true. A		particular test described by the expression evaluates to true. And
	NEMO language expression is a construct made up of variables,		users also can define which objects won't need to execute these
			actions with Constraint.
			A NEMO language expression is a construct made up of variables,
	operators, and method invocations, which are constructed according to		operators, and method invocations, which are constructed according to
	the syntax of the language and evaluates to a single value. NEMO		the syntax of the language and evaluates to a single value. NEMO
	language supports many operators to facilitate the construction of		language supports many operators to facilitate the construction of
	expressions. Assume variable A holds 10 and variable B holds 0,		expressions. Assume variable A holds 10 and variable B holds 0,
	then:		then:
	+----------+----------------------------------------------+---------+		+----------+----------------------------------------------+---------+
	| Operator | Description | Example |		| Operator | Description | Example |
	+----------+----------------------------------------------+---------+		+----------+----------------------------------------------+---------+
	| && | Called Logical AND operator. If both the | (A && |		| && | Called Logical AND operator. If both the | (A && |
	skipping to change at page 16, line 48 ¶		skipping to change at page 16, line 48 ¶
	+----------+----------------------------------------------+---------+		+----------+----------------------------------------------+---------+
	The Action specifies the execution when conditions meet.		The Action specifies the execution when conditions meet.
	Example:		Example:
	Policy "policy-1"		Policy "policy-1"
	ApplyTo "flow-1"		ApplyTo "flow-1"
	Priority 100		Priority 100
	Condition ("time">"18:00") || ("time"<"21:00")		Condition ("time">"18:00") || ("time"<"21:00")
	Action "gothrough" : List( "switch-1" , "switch-2");		Action "gothrough" : "backup_connection";
	The statement creates a policy which indicates the flow to go through		The statement creates a policy which indicates the flow to go through
	two specified switches from 18:00 to 21:00.		backup connection from 18:00 to 21:00.
	Delete a policy:		Delete a policy:
	<policy_del> := No Policy <policy_id>;		<policy_del> := No Policy <policy_id>;
	The No Policy is to delete a policy in user's network.		The No Policy is to delete a policy in user's network.
	5.6.3. Notification Behavior		5.6.3. Notification Behavior
	In NEMO language, each notification instance is identified by a		In NEMO language, each notification instance is identified by a
	skipping to change at page 18, line 42 ¶		skipping to change at page 18, line 42 ¶
	a transaction. The code between the two key words will be		a transaction. The code between the two key words will be
	interpreted as a transaction and executed by the NEMO language		interpreted as a transaction and executed by the NEMO language
	engine.		engine.
	6. The NEMO Language Examples		6. The NEMO Language Examples
	An enterprise with geographically distributed headquarter and branch		An enterprise with geographically distributed headquarter and branch
	sites has the requirement to dynamically balance the backup traffic.		sites has the requirement to dynamically balance the backup traffic.
	In order to implement this scenario, the virtual WAN tenant creates		In order to implement this scenario, the virtual WAN tenant creates
	two routers, and generates two links with different SLA to carry		two logicnw, and generates two connections with different SLA to
	diverse service flows. One link has 100M bandwidth with less than		carry diverse service flows. One connection has 100M bandwidth with
	50ms delay, which is used for normal traffic. And the other link has		less than 50ms delay, which is used for normal traffic. And the
	40G bandwidth with less than 400ms delay, which is used for backup		other connection has 40G bandwidth with less than 400ms delay, which
	traffic after work (from 19:00 to 23:00). With self defined flow		is used for backup traffic after work (from 19:00 to 23:00). With
	policy, the tenant can manage the link load balancing conveniently.		self defined flow policy, the tenant can manage the connection load
			balancing conveniently.
	Real-time Link		Real-time Connection
	+-------------+		+--------------------+
	10.0.1.0/24 | | 20.0.1.0/24		192.0.2.0/24 198.51.100.0/24
	+---------+ +----+ +----+ +-------------+		+---------+ +-------------+
	| Branch |------| R1 | | R2 |------| Headquarter |		| Branch |------------------| Headquarter |
	+---------+ +----+ +----+ +-------------+		+---------+ +-------------+
	| |		| |
	+-------------+		+--------------------+
	Broadband Link		Broadband Connection
	The detailed operation and code are shown as follows.		The detailed operation and code are shown as follows.
	o Step1: Create two virtual switch nodes in the WAN		o Step1: Create two virtual logicnw nodes in the WAN
	Node "R1"		Node "Branch"
	Type "router"		Type "logicnw"
	NW "LN-1"		NW "LN-1"
	Property "ip_version" : 4;		Property "ipv4Prefix" : 192.0.2.0/24;
	Node "R2"		Node "Headquarter"
	Type "router"		Type "logicnw"
	NW "LN-1"		NW "LN-1"
	Property "ip_version" : 4;		Property "ipv4Prefix" : 198.51.100.0/24;
	o Step2: Connect the two virtual nodes with two virtual links with		o Step2: Connect the two virtual nodes with two virtual connections
	different SLA.		with different SLA.
	Link "broadband_link"		Connection "broadband_connection"
	EndNodes "R1", "R2"		EndNodes "Branch", "Headquater"
	Property "bandwidth" : 40000, "delay" : 400;		Property "bandwidth" : 40000, "delay" : 400;
	Link "realtime_link"		Connection "realtime_connection"
	EndNodes "R1", "R2"		EndNodes "Branch", "Headquater"
	Property "bandwidth" : 100, "delay" : 50;		Property "bandwidth" : 100, "delay" : 50;
	o Step3: Indicate the flow to be operated.		o Step3: Indicate the flow to be operated.
	Flow "flow_all"		Flow "flow_all"
	Match "src_ip" : "10.0.1.0/24", "dst_ip": "10.0.1.0/24";		Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.0/24";
	Flow "flow_backup"		Flow "flow_backup"
	Match "src_ip" : "10.0.1.0/24", "dst_ip": "20.0.1.0/24",		Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.0/24",
	"port": 55555;		"port": 55555;
	o Step4: Apply policies to corresponding flows.		o Step4: Apply policies to corresponding flows.
	P1:		P1:
	Policy "policy4all"		Policy "policy4all"
	ApplyTo "flow_all"		ApplyTo "flow_all"
	Priority 200		Priority 200
	Action "forward_to": "realtime_link";		Action "forward_to": "realtime_connection";
	P2:		P2:
	Policy "policy4backup"		Policy "policy4backup"
	ApplyTo "flow_backup"		ApplyTo "flow_backup"
	Priority 100		Priority 100
	Condition ("time">"19:00:00") || ("time"<"23:00:00")		Condition ("time">"19:00:00") || ("time"<"23:00:00")
	Action "forward_to": "broadband_link";		Action "forward_to": "broadband_connection";
	7. Security Considerations		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.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. 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, Yali Zhang and Wenyang Lei.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	10. 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.xia-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-02 (work in
	progress", July 2014.		progress), May 2015.
	[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.
	skipping to change at page 21, line 25 ¶		skipping to change at page 21, line 25 ¶
	[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.		[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "Network Configuration Protocol (NETCONF)", RFC		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	6241, June 2011.		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
	P.R. China		P.R. China
	Email: xiayinben@huawei.com		Email: xiayinben@huawei.com
End of changes. 70 change blocks.
	140 lines changed or deleted		150 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/