< draft-xia-sdnrg-nemo-language-02.txt		draft-xia-sdnrg-nemo-language-03.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: November 5, 2015 S. Hares		Expires: April 16, 2016 S. Hares
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	May 4, 2015		October 14, 2015
	NEMO (NEtwork MOdeling) Language		NEMO (NEtwork MOdeling) Language
	draft-xia-sdnrg-nemo-language-02		draft-xia-sdnrg-nemo-language-03
	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 November 5, 2015.		This Internet-Draft will expire on April 16, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements for the Intent Based NBI Language . . . . . . . 4		3. Requirements for the Intent Based NBI Language . . . . . . . 4
	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 . . . . . . . . . . . . . . . 12
	5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12		5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12
	5.5.2. Connection Operations . . . . . . . . . . . . . . . . 12		5.5.2. Connection Operations . . . . . . . . . . . . . . . . 13
	5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 13		5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 14
	5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 14		5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 15
	5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 14		5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 16
	5.6.2. Policy Behavior . . . . . . . . . . . . . . . . . . . 14		5.6.2. Operation Behavior . . . . . . . . . . . . . . . . . 16
	5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 17		5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 19
	5.7. Connection Management Statements . . . . . . . . . . . . 17		5.7. Transaction Statements . . . . . . . . . . . . . . . . . 20
	5.8. Transaction Statements . . . . . . . . . . . . . . . . . 18		6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 20
	6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		10. Informative References . . . . . . . . . . . . . . . . . . . 22
	10. Informative References . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	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
	architecture design, and does not go into the NBI design.		architecture design, and does not go into the NBI design.
	Jennifer from Princeton University designed the Frenetic [Frenetic]		Jennifer Rexford from Princeton University designed the Frenetic
	based on the OpenFlow protocol. It is an advanced language for flow		[Frenetic] based on the OpenFlow protocol. It is an advanced
	programming, and systematically defines the operating model and mode		language for flow programming, and systematically defines the
	for the flow. However, the network requirement from the service is		operating model and mode for the flow. However, the network
	not only the flow operations, but also includes operations of		requirement from the service is not only the flow operations, but
	resource, service conditions, and service logic.		also includes operations of resource, service conditions, and service
			logic.
	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.
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	* The function node (FN) provides network services or forwarding		* The function node (FN) provides network services or forwarding
	with user concern, such as, firewall, load balance, vrouter,		with user concern, such as, firewall, load balance, vrouter,
	etc.		etc.
	* The business node (BN) describes a set of network elements and		* The business node (BN) describes a set of network elements and
	their connections, such as subnet, autonomous system, and		their connections, such as subnet, autonomous system, and
	internet. It conceals the internal topology and exposes		internet. It conceals the internal topology and exposes
	properties as one entity. It also enables iteration, i.e., a		properties as one entity. It also enables iteration, i.e., a
	network entity may include other network entities.		network entity may include other network entities.
	o Connection model: describes the connectivity between node		o Connection model: describes the connectivity network resource
	entities. This connection is not limited at the connectivity		between node entities. With Connection model, user could apply
	between single entity and single entity, but it also can express		for link resources between nodes and user can assign specific
	the connectivity between single entity and multiply entities, or		bandwidth for them. Connection constructs the foundation of
	multiply entities and multiply entities.		communication, namely, the necessary condition for communications
			between nodes is there are available resources between them. By
			default, the communication is allowed if there are direct
			connections between them. The Connection is not limited to the
			connectivity between single entity and single entity, but it can
			also 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. The Flow model together with the associated operations
			describe reachability of specific traffic between nodes in the
			virtual network, which is different from the connection resource
			between nodes.
	Network behavior includes the information and control operations.		Network behavior includes the information aquisition and the control
			operations.
	The information operation provides two methods to get the network		The NEMO language provides two methods to get the network information
	information for users.		for users.
	o Query: a synchronous mode to get the information, i.e., one can		o Query: a synchronous mode to get the information, i.e., one can
	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 operations to control the network.
	o Policy: control the behavior of specific entities by APP, such as		o Operation: control the behavior of specific entities by APP, such
	flow policy, node policy. All the policies follow the same		as flow operation, node operation. All the operations follow the
	pattern "when <condition>, to execute <action>, with		same pattern "when <condition>, do <action>, with <constraint>",
	<constraint>", and can be applied to any entity. But some of		and can be applied to any entity. But some of operation elements
	policy elements can be omitted according to users' requirement.		can be omitted according to users' requirement. Operation has the
			similar meaning with policy in some sense which also emphasizes
			the dynamic adjustment of objects.
	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 40 ¶		skipping to change at page 9, line 7 ¶
	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> | <connection_difinition> |		<model_definition_cmd> := <node_definition> | <connection_definition> |
	<action_deifinition> | <model_description>		<action_definition> | <model_description>
	<resource_access_cmd> := <node_cu> | <node_del> | <connection_cu> |		<resource_access_cmd> := <node_create> | <node_import> |<node_update> |
	<connection_del> | <flow_cu> | <flow_del>		<node_del> | <connection_create> |
	<behavior_cmd> := <query_cmd> | <policy_cu> | <policy_del> |		<connection_update> | <connection_del> |
	<notification_cu> | <notification_del>		<flow_create> | <flow_update> | <flow_del>
	<connection_mgt_cmd> := <connect_cmd> | <disconnect_cmd>		<behavior_cmd> := <query_cmd> | <operation_create> | <operation_update>
			| <operation_del> | <notification_create> |
			<notification_update> | <notification_del>
	<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 | ConnectionModel | FlowModel |		IPPrefix | NodeModel | ConnectionModel | FlowModel |
	ActionModel | Description | Porperty | Node | Connection|		ActionModel | Description | Porperty | Node | Connection|
	Flow | No | EndNodes | Type | NW | Match | List |		Flow | EndNodes | Type | Contain | Match | List |
	Range| Query | From | Notification | Listener |		Range| Query | From | Notification | Listener |
	Policy | ApplyTo | Priority | Condition | Action |		Operation | Target | Priority | Condition | Action |
	Connect | Disconnect | Address | Port | Transaction |		Transaction | Commit | CREATE | IMPORT | UPDATE | DELETE
	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 10, line 33 ¶		skipping to change at page 10, line 47 ¶
	<connection_type> := <naming> !!type name of the connection 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> | <connection_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.
	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 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 <connection_definition> statement is used to create a connection		The <connection_definition> statement is used to create a connection
	model:		model:
	<connection_definition> := ConnectionModel <connection_type>		<connection_definition> := ConnectionModel <connection_type>
	Property { <data_type> : <property_name> };		Property { <data_type> : <property_name> };
	The ConnectionModel specifies a new connection 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 connection type. Since end		pairs to specify properties for the new connection type. Since end
	nodes are intrinsic properties for a connection model, there is no		nodes are intrinsic properties for a connection model, there is no
	need to 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
	<action_definition> statement is used to create an action model:		<action_definition> statement is used to create an action model:
	<action_definition> := ActionModel <action_type>		<action_definition> := ActionModel <action_type>
	Property { <data_type> : <property_name> };		Property { <data_type> : <property_name> };
	The ActionModel specifies a new action type.		The ActionModel specifies a new action 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 action.		pairs to specify properties for the new action.
	NEMO language also supports querying the description of a defined		NEMO language also supports querying the description of a defined
	model by using the <model_description> statement:		model by using the <model_description> statement:
	<model_description> := Description <model_type>;		<model_description> := Description <model_type>;
			The keyword Description is followed 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		<naming> which MUST be unique. We use the following token to
	to the resource entity instance.		indicate the identifier given to the resource entity instance.
	<node_id> := <naming> !! name to identify the node instance		<node_id> := <naming> !! name to identify the node instance
	<connection_id> := <naming> !! name to identify the connection 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>|<connection_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:		NEMO model defines basic method for the node instances, and uses
			intuitive keyword to indicate the specific method. User could
			create, import, update and delete a node instance.
	<node_cu> := Node <node_id> Type <node_type>		The <node_create> statement is used to create or update a node
	NW <node_id>		instance:
	[Property {<property_name>: <value>}];
	The Node is followed by a user specified <node_id>. If the <node_id>		<node_create> := CREATE Node <node_id> Type <node_type>
	is new in the system, a new node will be created automatically.		[Contain {<node_id>}]
	Otherwise, the corresponding node identified by <node_id> will be		[Property {<property_name>: <value>}];
	updated with the following information.
			The <node_import> statement is used to import an existing external
			node instance:
			<node_import> := IMPORT Node <node_id> Type <node_type>
			[Contain {<node_id>}]
			[Property {<property_name>: <value>}];
			The <node_update> statement is used to update an existing node
			instance:
			<node_update> := UPDATE Node <node_id>
			[Contain {<node_id>}]
			[Property {<property_name>: <value>}];
			In all the above three statements, the Node is followed by a user
			specified <node_id>. According to the method, system will take
			corresponding action for the node instance. If the method is CREATE
			or IMPORT and the <node_id> is new in the system, a new node will be
			created automatically. If the method is UPDATE and the <node_id>
			exists in the system, 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 Type specifies the type of the node to operate.
	The NW specifies the dependence where the node is located.		The Contain is an optional keyword specifying the internal nodes
			which are included in this node instance.
	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 "Headquater"		An example of creating a node instance is as follows:
	Type "logicnw"
	NW "LN-1"
	Property "location" : "Beijing";
	The statement creates a switch type node that is located in the		CREATE Node Headquarter
	logical network "LN-1".		Type l3group
			Contain LN-1
			Property location : "Beijing";
			The statement creates a layer 3 virtual network which contains a
			predefined node "LN-1". The l3 virtual network is located in
			Beijing.
	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> := DELETE Node <node_id>;
	The No Node is to delete a node in user's network.		The DELETE Node is to delete a node in user's network.
	5.5.2. Connection Operations		5.5.2. Connection Operations
	The <connection_cu> statement is used to create or update a		NEMO model defines basic method for the connection instances, and use
	connection:		intuitive keyword to indicate the specific method. User could
			create, update and delete a connection instance.
	<connection_cu> := Connection <connection_id>		The <connection_create> statement is used to create a connection:
	EndNodes <node_id>, <node_id>
	[Property {<property_name>: <value>}];		<connection_create> := CREATE Connection <connection_id>
			Type <connection_type>
			EndNodes <node_id>, <node_id>
			[Property {<property_name>: <value>}];
			The <connection_update> statement is used to update a connection:
			<connection_create> := UPDATE Connection <connection_id>
			[EndNodes {<node_id>}, {<node_id>}]
			[Property {<property_name>: <value>}];
	The Connection is followed by a user specified <connection_id>. If		The Connection is followed by a user specified <connection_id>. If
	the <connection_id> is new in the system, a new connection will be		the method is CREATE and the <connection_id> is new in the system, a
	created automatically. Otherwise, the corresponding connection		new connection will be created automatically. If the method is
	identified by the <connection_id> will be updated with the following		UPDATE and the <connection_id> exists in the system, the
	information.		corresponding connection identified by the <connection_id> will be
			updated with the following information.
	The EndNodes specifies the two end nodes, identified by "<node_type>		The Type specifies the type of the connection to use. For example
	: <node_id>", of a connection. The Property is an optional keyword		there will be point to point connection, or point to multiple points
	followed by a list of "<property_name>: <value>" pairs. Multiple		connection.
	"<property_name>: <value>" pairs are separated by commas. The
	<property_name> MUST be selected from the property definition of the
	corresponding connection definition.
	Example:		The EndNodes specifies the end nodes of a connection. For each
			connection there will be left nodes and right nodes stand for the two
			ends.
	Connection "connection-1"		The Property is an optional keyword followed by a list of
	EndNodes "S1", "S2"		"<property_name>: <value>" pairs. Multiple "<property_name>:
	Property "bandwidth" : 1000, "delay" : 40;		<value>" pairs are separated by commas. The <property_name> MUST be
			selected from the property definition of the corresponding connection
			definition.
			An example of creating a connection instance is as follows:
			CREATE Connection connection-1
			Type p2p
			EndNodes S1, S2
			Property bandwidth : 1000, delay : 40;
	The statement creates a connection between two nodes, and sets the		The statement creates a connection between two nodes, and sets the
	connection property.		connection property.
	The <connection_del> statement is used to delete a node instance:		The <connection_del> statement is used to delete a connection
			instance:
	<connection_del> := No Connection <connection_id>;		<connection_del> := DELETE Connection <connection_id>;
	The No Connection is to delete a connection in user's network.		The DELETE 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:		NEMO model defines basic method for the flow instances, and use
			intuitive keyword to indicate the specific method. User could
			create, update and delete a flow instance.
	<flow_cu> := Flow <flow_id> Match {<property_name>: <value>		The <flow_create> statement is used to create a flow:
	| Range (<value>, <value>)
	| List({<value>})}
	The Flow is followed by a user defined <flow_id>. If the <flow_id>		<flow_create> := CREATE Flow <flow_id>
	is new in the system, a new flow will be created automatically.		Match {<property_name>: <value>
	Otherwise, the corresponding flow identified by the <flow_id> will be		| Range (<value>, <value>)
	updated with the following information.		| List({<value>})}
			The <flow_update> statement is used to update a flow:
			<flow_update> := UPDATE Flow <flow_id>
			Match {<property_name>: <value>
			| Range (<value>, <value>)
			| List({<value>})}
			The Flow is followed by a user defined <flow_id>. If the method is
			CREATE and the <flow_id> is new in the system, a new flow identifier
			will be created automatically. If the method is UPDATE and the
			<flow_id> exists in the system, 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		The Match specifies a flow by indicate match fields. NEMO language
	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:		An example of creating a flow instance is as follows:
	Flow "flow-1"		CREATE Flow flow-1
	Match "src_ip" : Range ("192.0.2.1", "192.0.2.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.0.2.1 to 192.0.2.243.		from 192.0.2.1 to 192.0.2.243.
	The <flow_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> := DELETE Flow <flow_id>;
	The No Flow is to delete a flow in user's network.		The DELETE 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
	object.		object.
	The <query_statement> generate a query:		The <query_statement> generate a query:
	<query_cmd> := Query {<property_name>}		<query_cmd> := Query {<property_name>}
	From {<entity_id>|<policy_id>}		From {<entity_id>|<operation_id>}
	The Query is followed by one or more <property_name>s which are		The Query is followed by one or more <property_name>s which are
	defined properties of the object to be queried.		defined properties of the object to be queried.
	The From is followed by the one or more queried objects. NENO		The From is followed by the one or more queried objects. NENO
	language support query operation to network entities and the policy.		language support query operation to network entities and the policy.
	5.6.2. Policy Behavior		5.6.2. Operation Behavior
	In NEMO language, each policy instance is identified by a <naming>		NEMO model defines basic method for the operation instances, and use
			intuitive keyword to indicate the specific method. User could
			create, update and delete a operation instance.
	<policy_id> := <naming> !! name to identify the policy instance		In NEMO language, each operation instance is identified by a <naming>
			which MUST be unique.
			<operation_id> := <naming> !! name to identify the operation instance
	Create and update a policy		Create and update a policy
	<policy_cu> := Policy <policy_id> ApplyTo <entity_id>		<operation_create> := CREATE Operation <operation_id>
	Priority <integer>		Target <entity_id>
	[Condition {<expression>}]		Priority <integer>
	Action {<action_type> : {<value>}}		[Condition <expression>]
	[Constraint {<expression>}];		Action {<action_type> : {<value>}};
	The Policy is followed by a user defined <policy_id>. If the		<operation_update> := UPDATE Operation <operation_id>
	<policy_id> is new in the system, a new policy will be created		[Target <entity_id>]
	automatically. Otherwise, the corresponding notification identified		[Priority <integer>]
	by the <policy_id> will be updated with the following information.		[Condition <expression>]
			[Action {<action_type> : {<value>}}];
	The ApplyTo specifies the entity to which the policy will apply.		The Operation is followed by a user defined <operation_id>. If the
			method is CREATE and the <operation_id> is new in the system, a new
			operation will be created automatically. If the method is UPDATE and
			the <operation_id> exists in the system, the corresponding operation
			identified by the<operation_id> will be updated with the following
			information.
	The Priority specifies the globe priority of the policy in the tenant		The Target specifies the entity to which the operation will apply.
	name space. The <value> with lower number has a higher priority,
	i.e. priority 0 holds the highest priority.		The Priority specifies the globe priority of the operation 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		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. And		particular test described by the expression evaluates to true. And
	users also can define which objects won't need to execute these		users also can define which objects won't need to execute these
	actions with Constraint.		actions with Constraint.
	A NEMO language expression is a construct made up of variables,		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
	skipping to change at page 16, line 42 ¶		skipping to change at page 18, line 42 ¶
	| < | Checks if the value of left operand is less | (A < B) |		| < | Checks if the value of left operand is less | (A < B) |
	| | than the value of right operand, if yes then | is |		| | than the value of right operand, if yes then | is |
	| | condition becomes true. | true. |		| | condition becomes true. | true. |
	| <= | Checks if the value of left operand is less | (A <= |		| <= | Checks if the value of left operand is less | (A <= |
	| | than or equal to the value of right operand, | B) is |		| | than or equal to the value of right operand, | B) is |
	| | if yes then condition becomes true. | true. |		| | if yes then condition becomes true. | true. |
	+----------+----------------------------------------------+---------+		+----------+----------------------------------------------+---------+
	The Action specifies the execution when conditions meet.		The Action specifies the execution when conditions meet.
	Example:		An example of creating anoperation is as follows:
	Policy "policy-1"		CREATE Operation operation-1
	ApplyTo "flow-1"		Target flow-1
	Priority 100		Priority 100
	Condition ("time">"18:00") || ("time"<"21:00")		Condition (time>"18:00") || (time<"21:00")
	Action "gothrough" : "backup_connection";		Action redirect : "backup_connection";
	The statement creates a policy which indicates the flow to go through		The statement creates an operation which indicates the flow to go
	backup connection from 18:00 to 21:00.		through backup connection from 18:00 to 21:00.
	Delete a policy:		Delete an operation:
	<policy_del> := No Policy <policy_id>;		<operation_del> := DELETE Operation <operation_id>;
	The No Policy is to delete a policy in user's network.		The DELETE Operation 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
	<naming>		<naming>
	<notification_id> := <naming> !! name to identify the notification		<notification_id> := <naming> !! name to identify the notification
	instance		instance
	Create and update a notification		Create and update a notification
	<notification_cu> := Notification <notification_id>		<notification_create> := CREATE Notification <notification_id>
	[(Query {<property_name>}		[(Query {<property_name>}
	From {<entity_id>})]		From {<entity_id>})]
	Condition {<expression>}		Condition {<expression>}
	Listener <callbackfunc>;		Listener <callbackfunc>;
			<notification_update> := UPDATE 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 is followed by a user defined <notification_id>. If
	the <notification_id> is new in the system, a new notificaiton will		the method is CREATE and the <notification_id> is new in the system,
	be created automatically. Otherwise, the corresponding notification		a new notification will be created automatically. If the method is
	identified by the <notification_id> will be updated with the		UPDATE and the <notification_id> exists in the system, the
	following information.		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 Query clause is nested in the notification statement to indicate
	the information acquisition.		the information acquisition.
	The Condition clause is the same as in policy statement, which		The Condition clause is the same as in operation statement, which
	triggers the notification.		triggers the notification.
	The Listener specifies the callback function that is used to process		The Listener specifies the callback function that is used to process
	the notification.		the notification.
	Delete a notification:		Delete a notification:
	<notification_del> := No Notification <notification_id>;		<notification_del> := DELETE Notification <notification_id>;
			The DELETE Notification is to delete a notification in user's
	The No Notification is to delete a notification in user's network.		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		5.7. Transaction Statements
	<transaction_begin> := Transaction		<transaction_begin> := Transaction
	<transaction_end> := Commit		<transaction_end> := Commit
	The keywords Transaction and Commit are used to tag begin and end of		The keywords Transaction and Commit are used to tag begin and end of
	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 logicnw, and generates two connections with different SLA to		two logicnw, and generates two connections with different SLA to
	carry diverse service flows. One connection has 100M bandwidth with		carry diverse service flows. One connection has 100M bandwidth with
	less than 50ms delay, which is used for normal traffic. And the		less than 50ms delay, which is used for normal traffic. And the
	other connection has 40G bandwidth with less than 400ms delay, which		other connection has 40G bandwidth with less than 400ms delay, which
	is used for backup traffic after work (from 19:00 to 23:00). With		is used for backup traffic after work (from 19:00 to 23:00). With
	self defined flow policy, the tenant can manage the connection load		self defined flow operations, the tenant can manage the connection
	balancing conveniently.		load balancing conveniently.
	Real-time Connection		Real-time Connection
	+--------------------+		+--------------------+
	192.0.2.0/24 198.51.100.0/24		192.0.2.0/24 198.51.100.0/24
	+---------+ +-------------+		+---------+ +-------------+
	| Branch |------------------| Headquarter |		| Branch |------------------| Headquarter |
	+---------+ +-------------+		+---------+ +-------------+
	| |		| |
	+--------------------+		+--------------------+
	Broadband Connection		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 logicnw nodes in the WAN		o Step1: Create two virtual logicnw nodes in the WAN
	Node "Branch"		CREATE Node Branch
	Type "logicnw"		Type l2group
	NW "LN-1"		Property ipv4Prefix : 192.0.2.0/24;
	Property "ipv4Prefix" : 192.0.2.0/24;
	Node "Headquarter"		CREATE Node Headquarter
	Type "logicnw"		Type l2group
	NW "LN-1"		Property ipv4Prefix : 198.51.100.0/24;
	Property "ipv4Prefix" : 198.51.100.0/24;
	o Step2: Connect the two virtual nodes with two virtual connections		o Step2: Connect the two virtual nodes with two virtual connections
	with different SLA.		with different SLA.
	Connection "broadband_connection"		CREATE Connection broadband_connection
	EndNodes "Branch", "Headquater"		EndNodes Branch, Headquater
	Property "bandwidth" : 40000, "delay" : 400;		Property bandwidth : 40000, delay : 400;
	Connection "realtime_connection"		CREATE Connection realtime_connection
	EndNodes "Branch", "Headquater"		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"		CREATE Flow flow_all
	Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.0/24";		Match src_ip : "192.0.2.0/24", dst_ip: "198.51.100.0/24";
	Flow "flow_backup"		CREATE Flow flow_backup
	Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.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"		CREATE Operation operation4all
	ApplyTo "flow_all"		Target flow_all
	Priority 200		Priority 200
	Action "forward_to": "realtime_connection";		Action redirect: "realtime_connection";
	P2:		P2:
	Policy "policy4backup"		CREATE Operation operation4backup
	ApplyTo "flow_backup"		Target 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_connection";		Action redirect: "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.
	skipping to change at page 21, line 6 ¶		skipping to change at page 22, line 30 ¶
	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-02 (work in		draft-xia-sdnrg-service-description-language-02 (work in
	progress), May 2015.		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,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[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.		DOI 10.17487/RFC2629, June 1999,
			<http://www.rfc-editor.org/info/rfc2629>.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122, July		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	2005.		DOI 10.17487/RFC4122, July 2005,
			<http://www.rfc-editor.org/info/rfc4122>.
	[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		DOI 10.17487/RFC6020, October 2010,
			<http://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	Bierman, "Network Configuration Protocol (NETCONF)", RFC		and A. Bierman, Ed., "Network Configuration Protocol
	6241, June 2011.		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<http://www.rfc-editor.org/info/rfc6241>.
	[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
End of changes. 83 change blocks.
	218 lines changed or deleted		286 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/