Internet DRAFT - draft-okita-ops-vnetmodel
draft-okita-ops-vnetmodel
Network Working Group H. Okita
Internet-Draft M. Yoshizawa
Intended status: Informational T. Suzuki
Expires: January 17, 2013 T. Iijima
Hitachi, Ltd.
July 16, 2012
Virtual Network Management Information Model
draft-okita-ops-vnetmodel-07
Abstract
Virtual switches on server virtualization platforms cause a problem
in managing networks in data center and between data centers
containing several hundred switches. Accordingly, a management
information model for the networks containing virtual switches is
proposed. The proposed model consists of a physical layer (which
represents connections between physical switches) and a virtual layer
(which represents connections between virtual switches). These
layers also represent the association of the virtual switch with the
corresponding physical switch. This document also provides
implementation examples of proposed information model in XML and
Yang.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Okita, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Virtual Network Information Model July 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Virtual Network Management System . . . . . . . . . . . . . . 7
4. Power Saving Use Case . . . . . . . . . . . . . . . . . . . . 10
5. Requirements for Virtual Network Management Information
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Relationships to Existing MIBs . . . . . . . . . . . . . . . . 13
6.1. Relationships to LLDP-MIB . . . . . . . . . . . . . . . . 13
6.2. Relationships to ENTITY-MIB . . . . . . . . . . . . . . . 13
7. Proposals of Virtual Network Management Information Model . . 15
7.1. TargetedNetwork Object . . . . . . . . . . . . . . . . . . 15
7.2. PhysicalNetwork Object . . . . . . . . . . . . . . . . . . 16
7.3. VirtualNetwork Object . . . . . . . . . . . . . . . . . . 18
7.4. Id Object . . . . . . . . . . . . . . . . . . . . . . . . 20
8. XML-based Implementation of the Proposed Information Model . . 22
9. YANG Module for Virtual Network Information Model . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Okita, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Virtual Network Information Model July 2012
1. Introduction
In data center networks, a virtual switch on a server virtualization
platform works as a virtual network element [VEB] [EVB-PAR] [PE-PAR]
. The virtual switch connects multiple virtual machines on the same
server virtualization platform and connects these virtual machines to
external physical switches.
Virtual switches, however, cause a problem in managing data center
networks because, mainly, a virtual switch and a physical switch
require different management systems. Operators of networks
therefore have to use multiple management systems for managing the
whole network.
To avoid this management difficulty, an integrated network management
system (NMS) is effective. The integrated NMS collects and stores
virtual-network management information that describes network
structure of a managed target network. It then displays or transmits
this management information as a response to a request from operators
or other NMSs.
The purpose of this document is to provide a management information
model that represents the network structure of the whole network
including data centers containing virtual switches. Section 2
describes the problem statement, Section 3 describes the necessity of
a virtual network management system, Section 4 describes power saving
use case, Section 5 describes requrements for the information model,
Section 6 describes the relationships to the existing MIBs, Section 7
defines the propsed information model, Section 8 describes an XML
Schema based data model of the information model, Section 9 describes
a Yang module of the information model.
Okita, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Virtual Network Information Model July 2012
2. Problem Statement
Virtual switches cause a difficulty in managing networks including
data centers. They expand the data center network into the server
virtualization platforms. Therefore, to manage the whole networks,
network operators have to manage virtual switches in addition to
physical switches.
To manage these virtual and physical switches, the operators have to
use multiple management interfaces. Specifically, to manage virtual
switches, they have to use a specific management system for the
server virtualization platform that the target virtual switches are
created on. Moreover, to manage physical switches, they use a
network management system. Figure 1 shows an architectural overview
of a conventional network management system.
+-----------+
|User Client|
+-----------+
|
V
+-----------+ +---------+
|User Client| |Other NMS|
+-----------+ +---------+
| | | |
| +-------------+ |
| +------------+ | |
V V V V
+--------------+ +-----------------+
|Server | |Traditional |
|Virtualization| |Network |
|Management | |Management |
|System | |System (NMS) |
+--------------+ +-----------------+
| | |
V V V
+--------------+ +-------+ +-------+
|Server | |Network| |Network|
|Virtualization| |Switch | |Switch |
|Platform | +-------+ +-------+
|+--+ +-------+|
||VM| |Virtual||
|+--+ |Switch ||
| +-------+|
+--------------+
Okita, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Virtual Network Information Model July 2012
Figure 1: Overview of a network management system
This conventional management architecture causes the following
problems which increase the operation time taken by operators of the
networks and thus increase operational costs.
1. When operators want to examine the network structure of a virtual
network containing virtual switches, they have to access multiple
management systems.
2. When operators want to examine the mapping of a virtual network
to corresponding physical components, they have to access
multiple management systems.
3. When operators want to configure a data center network according
to a VM migration in the data center, they have to access
multiple management systems.
4. When operators want to configure a network among data centers
according to a VM migration over the data centers, they have to
access multiple management systems.
5. When operators want to configure multi-layer networks for a
power-saving cloud system consisting of multiple data centers and
networks, they have to access multiple management systems.
To solve these problems and save the operation time for the networks,
the following requirements must be met.
1. The data center network should provide an integrated management
system that enables operators to get network structure
information about virtual network.
2. The data center network should provide an integrated management
system that enables operators to get mapping information about
virtual switches and their underlying physical platforms.
3. The data center network should provide an integrated management
system that enables operators to configure the data center
network including virtual switches.
4. The network including data centers should provide an integrated
management system that enables operators to configure the whole
network including virtual networks.
5. The network including data centers should provide an integrated
management system that enables operators to configure multi-layer
networks including not only physical networks but also virtual
Okita, et al. Expires January 17, 2013 [Page 5]
Internet-Draft Virtual Network Information Model July 2012
networks.
Okita, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Virtual Network Information Model July 2012
3. Virtual Network Management System
A system architecture that effectively satisfies the above-described
requirements is proposed in the following.
An integrated network management system (NMS) effectively reduces the
network operation time needed for managing virtual switches and
physical switches. It is referred to as a VNMS (Virtual Network
Management System.) It integrates multiple existing management
interfaces into a single interface. Operators can thus reduce their
operation time.
The VNMS manages device connectivity in the managed target network.
To perform this task, it stores network management information about
configured virtual networks in the target network.
Figure 2 shows an overview of the system architecture of the target
system. The virtual-network management information about the VNMS is
based on the proposed model .
Okita, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Virtual Network Information Model July 2012
+-----------+ +-----------+
|User Client| |User Client|
+-----------+ +-----------+
| |
V V
+-----------+ +---------------+ +---------------+
|User Client| |Traditional NMS| |Traditional NMS|
+-----------+ +---------------+ +---------------+
| | |
= NMI = NMI = NMI
| | +------------+
+----------------------------------+
|Virtual Network Management System |
| +-----------------------------+ |
| |Virtual Network | |
| |Management Information | |
| |(based on the proposed model)| |
| +-----------------------------+ |
+----------------------------------+
| | |
= DMI = DMI = DMI
| | |
+--------------+ +-------+ +-------+
|Server | |Network| |Network|
|Virtualization| |Switch | |Switch |
|Platform | +-------+ +-------+
|+--+ +-------+|
||VM| |Virtual||
|+--+ |Switch ||
| +-------+|
+--------------+
Figure 2: Overview of system architecture
The following three types of elements exist around this VNMS.
o User clients or traditional NMS
o Network switches
o Server virtualization platforms
The user client or network application uses management information
about device connections in the managed network. The network
switches are virtualized as multiple virtual switches. Moreover, the
server virtualization platforms are virtualized as multiple virtual
machines and internal virtual switches. A set of virtual switches
Okita, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Virtual Network Information Model July 2012
and virtual machines forms a virtual system for a user.
Among the elements described above, we define the following two
management interfaces.
o Network Management Interface (NMI)
o Device Management Interface (DMI)
The network management interface (NMI) is set between the network
application and the VNMS. This interface is used by the VNMS to
transport virtual-network management information to network
applications in response to their request.
Datamodels provide the definition and format of the virtual-network
management information transported on the NMI. The definition
describes an encoding scheme and an underlying transport protocol.
The VNMS may use, for example, SNMP (Simple Network Management
Protocol) and MIB (Management Information Base) specified in the
Internet-standard management framework[RFC3410] or an XML-based
management framework[RFC3535] as the datamodel.
The device-management interface (DMI) is set between the VNMS and
network devices, which include the server virtualization platforms
and network switches. The DMI is used by the VNMS to query
management information about a target device. This interface is
device specific and not standardized by this document.
Okita, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Virtual Network Information Model July 2012
4. Power Saving Use Case
One of use cases for the virtual network managament system (VNMS) is
an optimization of the VMs' location for power saving as shown in
Figure 3. The example system is composed of the VNMS, multiple data
centers consisting of many servers, an inter data center network, and
a network application.
When the network application optimizes the VMs' location, one or more
VMs are needed to be relocated between the servers in the multiple
data centers. To execute that, the network application needs to know
the current situations of the whole network including the data center
networks. In addition, it needs to configure the network to meet
conditions for the relocated VMs.
In this case, if there is no common interface for the network
management, the network application needs to use many traditional
interfaces for the configuration of networks. However, in the
proposed model, it needs to only access the VNMS for getting the
current network configurations and for managing the whole network
including the data center networks through the NMI.
Okita, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Virtual Network Information Model July 2012
+------------------------------------------------------+
| Network Application |
| (Optimization of VM Location) |
+------------------------------------------------------+
|
|
= NMI
|
|
+------------------------------------------------------+
| Virtual Network Management System (VNMS) |
| +-----------------------------------------+ |
| |Virtual Network Management Information | |
| |(based on the proposed model) | |-------+
| +-----------------------------------------+ | |
+------------------------------------------------------+ |
| | | |
| | | |
| | | |
= DMI = DMI = DMI = DMI
| | | |
| | | |
+----------------+ +----------------+ +----------------+ +----------+
| Data Center | | Data Center | | Data Center | | Inter-DC |
| | | | | | | Network |
|+--------------+| |+--------------+| |+--------------+| |+--------+|
||Server || ||Server || ||Server || || ||
||+--+ +-------+|| ||+--+ +-------+|| ||+--+ +-------+|| ||Network ||
|||VM| |Virtual||| |||VM| |Virtual||| |||VM| |Virtual||| || Switch||
||+--+ |Switch ||| ||+--+ |Switch ||| ||+--+ |Switch ||| || ||
|| +-------+|| || +-------+|| || +-------+|| || ||
|+--------------+| |+--------------+| |+--------------+| |+--------+|
+----------------+ +----------------+ +----------------+ +----------+
Figure 3: VM Location Optimization for Power Saving
Okita, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Virtual Network Information Model July 2012
5. Requirements for Virtual Network Management Information Model
This document focuses on an information model for the virtual-network
management information described in the section 3. The requirements
for the information model are listed below. These requirements arise
from the problems stated in the previous sections.
1. Physical Resource Information: The proposed model should be able
to represent the physical resources available on the target
network. Those resources include several physical network
devices, for example, network switches, routers. And, they also
include server virtualization platforms.
2. Physical Hierarchy Information: The proposed model should be able
to represent the hierarchy of physical resources in the target
network. For example, the relationship between a chassis of a
network switch and its network interface cards should be
represented.
3. Physical Connection Information: The proposed model should
represent a connection among physical switches and physical
servers in the target network.
4. Virtual Resource Information: The proposed model should be able
to represent the virtual resources available on the target
network. Those resources include several virtual devices, for
example, virtualized switches and virtual switches on the server
virtualization platforms. And, they also include virtual
machines on server virtualization platforms.
5. Virtual Connection Information: The proposed model should
represent a connection between virtual switches and virtual
machines in the target network.
6. Virtual-Physical Mapping Information: The proposed model should
represent mapping of a virtual switch to the physical server that
the virtual switch is created on.
Okita, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Virtual Network Information Model July 2012
6. Relationships to Existing MIBs
A lot of RFCs about MIBs have been published from the IETF. These
existing MIBs provide each information models implicitly. For
avoiding inventing the wheel, we researched relationships between the
requirements for the virtual network management information model and
existing MIBs.
6.1. Relationships to LLDP-MIB
Protocols for network topology discovery like Link Layer Discovery
Protocol (LLDP) use some of MIB modules. These MIB modules are used
to describe link state information in the managed network. For
example, the LLDP-MIB [IEEE.802-1AB.2005] standardized as IEEE
Standard 802.1AB supports this function.
The LLDP-MIB can be used to describe a connection between neighboring
layer-2 MAC bridges. In the LLDP-MIB, there is an lldpRemTable which
contains one or more rows per physical network connection. The row
contains a chassis ID, a port ID, a port description, and system
information for each neighboring layer-2 MAC bridge.
As described above, the LLDP-MIB can be used to describe the
connection information between physical entities like physical
switches. However, the LLDP-MIB cannot be used to describe the
connection information between logical entities. Thus, it cannot be
used to describe the connection information between a virtual switch
and a virtual machine on the same physical server. Moreover, it
cannot be used to describe the connection information between a
virtual switch and an external physical switch.
As the result, the LLDP-MIB does not satisfy the first requirement in
section 2 for the virtual network management information model.
6.2. Relationships to ENTITY-MIB
The ENTITY-MIB [RFC2737] was published by the IETF entmib WG. It can
be used to represent a single SNMP agent which supports multiple
instances of one MIB. For example, a single physical switch having a
single SNMP agent can support multiple instances of a bridge with the
ENTITY-MIB.
The ENTITY-MIB can be used to describe following two types of
information.
One is mapping information between logical entities and physical
entities on one network element. The information can be represented
by the entLPMappingTable and the entAliasMappingTable in the
Okita, et al. Expires January 17, 2013 [Page 13]
Internet-Draft Virtual Network Information Model July 2012
entityMapping group. For example, these tables support logical
entities which contain OSPF instances and 802.1d bridges. Moreover,
these tables support physical entities which contain bridge ports,
backplanes and chassis.
Another is information about hierarchy relationship among physical
entities. The information can be represented by the
entPhysicalContainsTable in the entityMapping group. The
entPhysicalContainsTable contains simple mapping information between
'container' entity and 'containee' entity. For example, a chassis is
a 'container' entity. Its bridge ports and its backplane are
'containee' entities.
As described above, the ENTITY-MIB can be used to describe the
mapping information between logical entities and physical entities.
Therefore, the ENTITY-MIB satisfies the second requirement in section
2 for the virtual network management information model.
However, the ENTITY-MIB cannot be used to describe the connection
information between logical entities. For example, it is impossible
to describe connection information between virtual switches with the
ENTITY-MIB.
As the result, the ENTITY-MIB does not satisfy the first requirement
in section 2 for the virtual network management information model.
Okita, et al. Expires January 17, 2013 [Page 14]
Internet-Draft Virtual Network Information Model July 2012
7. Proposals of Virtual Network Management Information Model
This section defines the proposed virtual-network management
information model, which is an object-oriented information model.
The model can satisfy both of the requirements included in section 2.
The model is an abstract-information model independent from encoding
schemes and management protocols. The model is written in Unified
Modeling Language (UML) [UML] .
7.1. TargetedNetwork Object
The proposed model starts with a TargetedNetwork object. This object
represents the overall network. In the network, two types of network
exist: a physical network and a virtual network. In the proposed
model, a PhysicalNetwork object represents a physical network, and a
VirtualNetwork object represents a virtual network. To represent
this structure, the TargetedNetwork object has one or multiple
references to PhysicalNetwork objects and VirtualNetwork objects.
Furthermore, the PhysicalNetwork object and the VirtualNetwork have a
reference between them. Since a physical network can create multiple
virtual networks, the PhysicalNetwork object can have multiple
references to corresponding VirtualNetwork objects. On the contrary,
the VirtualNetwork object has only one reference to the
PhysicalNetwork object, since the virtual network is created on the
specific physical network.
Figure 4 shows a class diagram of the proposed virtual-network
management information model containing the TargetedNetwork object,
PhysicalNetwork objects, and VirtualNetwork objects.
+---------------+
|TargetedNetwork|
+---------------+
<> <>
|1 |1 +---------------+
| +--------|VirtualNetwork |------Virtual network related objects
| 0..* +---------------+ (Figure.6)
| |0...n
| |
| |1
| <>
| +---------------+
+------------|PhysicalNetwork|------Physical network related objects
0..* +---------------+ (Figure.5)
Okita, et al. Expires January 17, 2013 [Page 15]
Internet-Draft Virtual Network Information Model July 2012
Figure 4: Class diagram of the proposed virtual-network management
information model
7.2. PhysicalNetwork Object
To represent the structure of a physical network, the proposed model
defines the following six types of managed objects under the
TargetedNetwork object.
o PhysicalNetwork
o PhysicalNode
o PhysicalNodeGroup
o PhysicalInterface
o PhysicalInterfaceGroup
o PhysicalLink
PhysicalNetwork:
This object represents an actual network composed of actual
devices. This object aggregates zero or more PhysicalNode
objects.
PhysicalNode:
This object represents an actual device in a physical network.
The actual device is a server, a server virtualization
platform, or a network switch. The object has an association
with a PhysicalNetwork object. It also has an association with
a PhysicalNodeGroup object when the actual device is a member
of a group of devices. It also aggregates zero or more
PhysicalInterface objects. The PhysicalNode object can contain
one "Configurations" object, which stores configuration data of
the device represented by the PhysicalNode object. The
Configurations object contains, for example, virtual LAN (VLAN)
configuration, link aggregation (LAG) configuration or server
virtualization configuration. Although this memo defines the
Configurations object as a child object of the PhysicalNode
object, defining the model for the configuration information is
out of scope of this memo. The main reason is that the model
of the Configurations object differs from one device to
another.
Okita, et al. Expires January 17, 2013 [Page 16]
Internet-Draft Virtual Network Information Model July 2012
PhysicalNodeGroup:
This object represents a set of multiple actual devices. For
example, this object represents the chassis of a blade server,
which includes multiple server blades and multiple network
switches. This object aggregates one or more PhysicalNode
objects.
PhysicalInterface:
This object represents an actual network interface of an actual
device. The network interface is a port of a network interface
card equipped in a server or a port of a network switch. The
object also represents an internal network interface used to
connect a server blade and an internal switch in a blade
server. This object has an association with a PhysicalNode
object. This object also has an association with a
PhysicalInterfaceGroup object when the network interface is a
port of the line card represented by the PhysicalInterfaceGroup
object. This object also has an association with a
PhysicalLink object when the network interface is connected to
another network interface by an actual network cable.
PhysicalInterfaceGroup:
This object represents a set of actual network interfaces. For
example, it represents a network interface card or a network
switch's line card (which is equipped with multiple ports). It
aggregates one or more PhysicalInterface objects.
PhysicalLink:
This object represents an actual network cable used to connect
two actual network interfaces. For example, it represents a
generic Ethernet cable. It also represents an internal
connection between a server blade and an internal switch in a
blade server. This object aggregates two PhysicalInterface
objects.
Figure 5 shows an abstract class diagram of the objects related to
the physical network.
Okita, et al. Expires January 17, 2013 [Page 17]
Internet-Draft Virtual Network Information Model July 2012
+---------------+
|TargetedNetwork|
+---------------+
<>
|1 0..* +---------------+
+------------------|PhysicalNetwork|
+---------------+
<>
+-----------------+ |1
|PhysicalNodeGroup| |
+-----------------+ |
<> |
0..1 | |
+---------------+ |
0..* | |0..*
+------------+1 +--------------+
|PhysicalNode|------|Configurations|
+------------+ 0..1+--------------+
<>
+----------------------+ |1
|PhysicalInterfaceGroup| |
+----------------------+ |
<> |
0..1 | |
+-------------+ |
0..* | |0..*
+---------+ +--------+
|Physical |-------<>|Physical|
|Interface|2 0..1 |Link |
+---------+ +--------+
Figure 5: Class diagram of physical-network-related objects
7.3. VirtualNetwork Object
To represent the structure of a virtual network, the proposed model
defines the following five types of managed objects under the
TargetedNetwork object.
o VirtualNetwork
o VirtualNode
o VirtualNodeGroup
o VirtualInterface
Okita, et al. Expires January 17, 2013 [Page 18]
Internet-Draft Virtual Network Information Model July 2012
o VirtualLink
VirtualNetwork:
This object represents a virtual network composed of multiple
virtual network devices, including not only actual devices but
also virtual devices. It aggregates zero or more VirtualNode
objects.
VirtualNode:
This object represents a virtual network device in a virtual
network. Examples of the virtual devices are virtual switches
and virtual machines on a server virtualization platform.
Other examples are virtual-router functions configured on a
router. The object has an association with a VirtualNetwork
object and a VirtualNodeGroup object.
VirtualNodeGroup:
This object represents a set of virtual devices that are
created from the same actual device. It aggregates one or more
VirtualNode objects. It also has an association with a
PhysicalNode object, which represents an actual device.
VirtualInterface:
This object represents a virtual network interface of a virtual
device. An example of such an interface is a virtual network-
interface card (VNIC) of a virtual machine on a server
virtualization platform. This object has an association with a
VirtualNode object. This object also has an association with a
VirtualLink object when the virtual network interface is
connected to another virtual network interface by a virtual
network link.
VirtualLink:
This object represents a virtual network link used to connect
two virtual network interfaces. For example, it represents a
connection between a virtual machine and a virtual switch
created on a server virtualization platform. This object
aggregates two VirtualInterface objects.
The relationship between the VirtualNetwork, the VirtualNode, the
VirtualInterface, and this VirtualLink object is almost the same as
the relationship between the PhysicalNetwork, the PhysicalNode, the
PhysicalInterface, and the PhysicalLink object.
Figure 6 shows an abstract class diagram of the objects related to
the virtual network.
Okita, et al. Expires January 17, 2013 [Page 19]
Internet-Draft Virtual Network Information Model July 2012
+---------------+
|TargetedNetwork|
+---------------+
<>
|1 0..* +--------------+
+-------------------|VirtualNetwork|
+--------------+
<>
+----------------+ |1
|VirtualNodeGroup| |
+----------------+ |
1..* | <> |
| |1 |
| +----------+ |
| 1..* | |0..*
| +-----------+
| |VirtualNode|
| +-----------+
| <>
| |1
| |
| |0..*
| +---------+ +-------+
| |Virtual |-------<>|Virtual|
1| |Interface|2 0..1 |Link |
<> +---------+ +-------+
+------------+
|PhysicalNode|
+------------+
Figure 6: Class diagram of virtual-network-related objects
7.4. Id Object
All objects except the TargetedNetwork object must contain each "id"
object which stores an identifier (ID). The ID must be unique within
the group formed by the same type of objects associated with the same
parent object as following.
o PhysicalNetwork object ID is unique within a TargetedNetwork
object.
o PhysicalNodeGroup object ID is unique within a PhysicalNetwork
object.
o PhysicalNode object ID is unique within a PhysicalNetwork object.
Okita, et al. Expires January 17, 2013 [Page 20]
Internet-Draft Virtual Network Information Model July 2012
o PhysicalInterface object ID is unique within a PhysicalNode
object.
o PhysicalInterfaceGroup object ID is unique within a PhysicalNode
object.
o PhysicalLink object ID is unique within a PhysicalNetwork object.
o VirtualNetwork object ID is unique within a TargetedNetwork
object.
o VirtualNode object ID is unique within a VirtualNetwork object.
o VirtualInterface object ID is unique within a VirtualNode object.
o VirtualLink object ID is unique within a VirtualNetwork object
Okita, et al. Expires January 17, 2013 [Page 21]
Internet-Draft Virtual Network Information Model July 2012
8. XML-based Implementation of the Proposed Information Model
This section shows an example data model that is created according to
the proposed information model described above. This example data
model is intended to help readers check the feasibility of the
proposed information model. Thus, this section will be removed when
the proposed information model is fixed.
This example data model is defined as an XML[W3C.REC-xml-20081126]-
based data model. Therefore, it is represented as an XML tree, which
has an "targetedNetwork" element as its top node. In this XML tree,
each class in the proposed information model is mapped to an XML
element and located hierarchically.
Because of the difference between UML and XML, several new objects
exist in the example XML data model. For example, a "physicalLinks"
element appeared under a "physicalNetwork" element in order to
aggregate multiple "physicalLink" elements. To represent the
reference to one of these "physicalLink" elements, a String-type
"linkId" element appears in a "physicalInterface" element.
The XML below shows the definition of the example data model written
in W3C XML Schema.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.hitachi.com/vnetmodel-0.1"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vnm="http://www.hitachi.com/vnetmodel-0.1">
<xs:element name="targetedNetwork"
type="vnm:targetedNetworkType"></xs:element>
<xs:complexType name="targetedNetworkType">
<xs:sequence>
<xs:element name="physicalNetwork"
type="vnm:physicalNetworkType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="virtualNetwork"
type="vnm:virtualNetworkType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
</xs:complexType>
Okita, et al. Expires January 17, 2013 [Page 22]
Internet-Draft Virtual Network Information Model July 2012
<xs:complexType name="physicalNetworkType">
<xs:sequence>
<xs:element name="physicalNodeGroup"
type="vnm:physicalNodeGroupType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="physicalNode" type="vnm:physicalNodeType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="physicalLinks" type="vnm:physicalLinksType"
maxOccurs="1" minOccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="physicalNodeGroupType">
<xs:sequence>
<xs:element name="physicalNode" type="vnm:physicalNodeType"
maxOccurs="unbounded" minOccurs="0"></xs:element>
<xs:element name="physicalNodeGroup"
type="vnm:physicalNodeGroupType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="physicalNodeType">
<xs:sequence>
<xs:element name="physicalInterface"
type="vnm:physicalInterfaceType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="physicalInterfaceGroup"
type="vnm:physicalInterfaceGroupType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="configurations" type="xs:anyType"
maxOccurs="1" minOccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="physicalLinksType">
Okita, et al. Expires January 17, 2013 [Page 23]
Internet-Draft Virtual Network Information Model July 2012
<xs:sequence>
<xs:element name="physicalLink" type="vnm:physicalLinkType"
maxOccurs="unbounded" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="physicalInterfaceType">
<xs:sequence>
<xs:element name="linkId" type="xs:string"
maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="physicalInterfaceGroupType">
<xs:sequence>
<xs:element name="physicalInterfaceId" type="xs:string"
maxOccurs="unbounded" minOccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="physicalLinkType">
<xs:sequence>
<xs:element name="physicalInterface" type="xs:string"
maxOccurs="2" minOccurs="2"></xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="virtualNetworkType">
<xs:sequence>
<xs:element name="virtualNode" type="vnm:virtualNodeType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="virtualNodeGroup"
type="vnm:virtualNodeGroupType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element name="virtualLinks" type="vnm:virtualLinksType"
maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
</xs:complexType>
Okita, et al. Expires January 17, 2013 [Page 24]
Internet-Draft Virtual Network Information Model July 2012
<xs:complexType name="virtualNodeGroupType">
<xs:sequence>
<xs:element name="virtualNodeId" type="xs:string"
maxOccurs="unbounded" minOccurs="1">
</xs:element>
<xs:element name="physicalNodeId" type="xs:string"
maxOccurs="1" minOccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="virtualLinksType">
<xs:sequence>
<xs:element name="virtualLink" type="vnm:virtualLinkType"
maxOccurs="unbounded" minOccurs="1"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="virtualNodeType">
<xs:sequence>
<xs:element name="virtualInterface"
type="vnm:virtualInterfaceType"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="virtualLinkType">
<xs:attribute name="id" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:complexType name="virtualInterfaceType">
<xs:sequence>
<xs:element name="linkId" type="xs:string"
maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string"></xs:attribute>
<xs:attribute name="type" type="xs:string"></xs:attribute>
</xs:complexType>
<xs:element name="NewElement" type="xs:string"></xs:element>
</xs:schema>
Okita, et al. Expires January 17, 2013 [Page 25]
Internet-Draft Virtual Network Information Model July 2012
9. YANG Module for Virtual Network Information Model
The YANG module of the data model is written by using the
YANG[RFC6020] and the complex-type extension[RFC6095] and is
specified as follows:
module vnetmodel {
namespace "urn:ietf:params:xml:ns:vnetmodel-config";
prefix "vnetm";
import ietf-yang-types {prefix "yang";}
import ietf-complex-types {prefix "ct";}
organization "OPSAWG";
contact "toshiaki.suzuki.cs@hitachi.com";
description "YANG Module for Virtual Network Information Model";
revision 2011-10 {
description " Version of draft-okita-ops-vnetmodel-05
Change in -05:
- Yang Data Model is added";
}
ct:complex-type OriginalObject {
description "Parameters for original object";
leaf id { type string; }
}
ct:complex-type TargetedNetwork {
description "Parameters for targeted network";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
ct:instance-list physicalNetwork {
ct:instance-type PhysicalNetwork;
}
ct:instance-list virtualNetwork {
ct:instance-type VirtualNetwork;
}
}
ct:complex-type PhysicalNetwork {
description "Parameters for physical network";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
Okita, et al. Expires January 17, 2013 [Page 26]
Internet-Draft Virtual Network Information Model July 2012
ct:instance-list physicalNodeGroup {
ct:instance-type PhysicalNodeGroup;
}
ct:instance-list physicalNode {
ct:instance-type PhysicalNode;
}
leaf-list physicalLinks {
type instance-identifier {
ct:instance-type PhysicalLinks ;
}
}
}
ct:complex-type PhysicalNodeGroup {
description "Parameters for physical node group";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
leaf type { type string; }
ct:instance-list physicalNode {
ct:instance-type PhysicalNode;
}
ct:instance-list physicalNodeGroup {
ct:instance-type PhysicalNodeGroup;
}
}
ct:complex-type PhysicalNode {
description "Parameters for physical node";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
leaf type { type string; }
leaf-list physicalInterface {
type instance-identifier {
ct:instance-type PhysicalInterface;
}
}
leaf-list physicalInterfaceGroup {
type instance-identifier {
ct:instance-type PhysicalInterfaceGroup;
}
}
leaf-list configurations {
type instance-identifier {
ct:instance-type Configulations;
}
}
Okita, et al. Expires January 17, 2013 [Page 27]
Internet-Draft Virtual Network Information Model July 2012
}
ct:complex-type Configulations {
description "Parameters for configulations";
ct:extends OriginalObject;
ct:abstract true;
}
ct:complex-type PhysicalLinks {
description "Parameters for physical links";
ct:extends OriginalObject;
leaf-list physicalLink {
type instance-identifier {
ct:instance-type PhysicalLink;
}
}
}
ct:complex-type PhysicalInterface {
description "Parameters for physical interface";
ct:extends OriginalObject;
leaf id { type string; }
leaf type { type string; }
leaf-list linkId { type string; }
}
ct:complex-type PhysicalInterfaceGroup {
description "Parameters for physical interface group";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
leaf type { type string; }
leaf-list physicalInterfaceId { type string; }
}
ct:complex-type PhysicalLink {
description "Parameters for physical link";
ct:extends OriginalObject;
leaf id { type string; }
leaf type { type string; }
leaf-list physicalInterface { type string; }
}
ct:complex-type VirtualNetwork {
description "Parameters for virtual network";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
Okita, et al. Expires January 17, 2013 [Page 28]
Internet-Draft Virtual Network Information Model July 2012
leaf-list virtualNode {
type instance-identifier {
ct:instance-type VirtualNode;
}
}
ct:instance-list virtualNodeGroup {
ct:instance-type VirtualNodeGroup;
}
leaf-list virtualLinks {
type instance-identifier {
ct:instance-type VirtualLinks ;
}
}
}
ct:complex-type VirtualNodeGroup {
description "Parameters for virtual node group";
ct:extends OriginalObject;
ct:abstract true;
leaf id { type string; }
leaf type { type string; }
leaf-list virtualNodeID { type string; }
leaf-list physicalNodeID { type string; }
}
ct:complex-type VirtualLinks {
description "Parameters for virtual links";
ct:extends OriginalObject;
leaf-list virtualInterface {
type instance-identifier {
ct:instance-type VirtualLink ;
}
}
}
ct:complex-type VirtualNode {
description "Parameters for virtual node";
ct:extends VirtualNetwork;
ct:abstract true;
leaf id { type string; }
leaf type { type string; }
leaf-list virtualInterface {
type instance-identifier {
ct:instance-type VirtualInterface;
}
}
}
Okita, et al. Expires January 17, 2013 [Page 29]
Internet-Draft Virtual Network Information Model July 2012
ct:complex-type VirtualLink {
description "Parameters for virtual link";
ct:extends OriginalObject;
leaf id { type string; }
}
ct:complex-type VirtualInterface {
description "Parameters for virtual interface";
ct:extends OriginalObject;
leaf id { type string; }
leaf type { type string; }
leaf-list linkId { type string; }
}
}
Okita, et al. Expires January 17, 2013 [Page 30]
Internet-Draft Virtual Network Information Model July 2012
10. Security Considerations
The virtual-network management information as defined in this
document provides administrative information about a data center
network. This information could be used to aid an attack on the
network.
It is assumed that accesses to the data defined in this document are
subject to appropriate access control in the network management
system.
Okita, et al. Expires January 17, 2013 [Page 31]
Internet-Draft Virtual Network Information Model July 2012
11. IANA Considerations
The document does not request any IANA action, since the proposed
model is an abstract information model. However, a concrete data
model based on this information model should request IANA actions if
necessary.
Okita, et al. Expires January 17, 2013 [Page 32]
Internet-Draft Virtual Network Information Model July 2012
12. References
12.1. Normative References
[IEEE.802-1AB.2005]
"Local Area Networks and Metropolitan Area Networks:
Station and Media Access Control Connectivity Discovery",
IEEE Standard 802.1AB, May 2005.
[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)",
RFC 2737, December 1999.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG
with Language Abstractions", RFC 6095, March 2011.
[UML] OMG, "Unified Modeling Language", September 2002,
<http://www.omg.org/technology/documents/formal/uml.htm>.
12.2. Informative References
[EVB-PAR] Congdon, P., "Edge Virtual Bridging Draft PAR",
September 2009, <http://www.ieee802.org/1/files/public/
docs2009/new-congdon-evb-PAR5c-0909-v1.pdf>.
[PE-PAR] Pelissier, J., "Port Extension Draft PAR Proposal",
September 2009, <http://www.ieee802.org/1/files/public/
docs2009/new-pelissier-portextension-par5c-0909.pdf>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[VEB] Ganga, I., "Virtual Ethernet Bridging in Server end
stations", September 2008, <http://www.ieee802.org/1/
files/public/docs2008/
new-dcb-ganga-virtual-bridging-in-server-end-stations-
0908.pdf>.
[W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Maler, E., Paoli, J.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
Okita, et al. Expires January 17, 2013 [Page 33]
Internet-Draft Virtual Network Information Model July 2012
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
Okita, et al. Expires January 17, 2013 [Page 34]
Internet-Draft Virtual Network Information Model July 2012
Authors' Addresses
Hideki Okita
Central Research Laboratory, Hitachi, Ltd.
292 Yoshida-cho
Totsuka-ku, Yokohama, Kanagawa 244-0817
Japan
Phone: +81-45-860-2142
Email: hideki.okita.pf@hitachi.com
Masahiro Yoshizawa
Central Research Laboratory, Hitachi, Ltd.
292 Yoshida-cho
Totsuka-ku, Yokohama, Kanagawa 244-0817
Japan
Phone: +81-45-860-2142
Email: masahiro.yoshizawa.bt@hitachi.com
Toshiaki Suzuki
Central Research Laboratory, Hitachi, Ltd.
292 Yoshida-cho
Totsuka-ku, Yokohama, Kanagawa 244-0817
Japan
Phone: +81-45-860-2177
Email: toshiaki.suzuki.cs@hitachi.com
Tomoyuki Iijima
Central Research Laboratory, Hitachi, Ltd.
292 Yoshida-cho
Totsuka-ku, Yokohama, Kanagawa 244-0817
Japan
Phone: +81-45-860-2156
Email: tomoyuki.iijima.fg@hitachi.com
Okita, et al. Expires January 17, 2013 [Page 35]
