[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                           H. Okita
Internet-Draft                                              M. Yoshizawa
Intended status: Informational                             Hitachi, Ltd.
Expires: April 28, 2011                                 October 25, 2010


              Virtual Network Management Information Model
                      draft-okita-ops-vnetmodel-03

Abstract

   Virtual switches on server virtualization platforms cause a problem
   in managing data center networks containing several hundred switches.
   Accordingly, a management information model for the network structure
   of data center 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 an
   example of the XML-based data model that is implemented according to
   the proposed information model.

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 April 28, 2011.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Okita & Yoshizawa        Expires April 28, 2011                 [Page 1]


Internet-Draft      Virtual Network Information Model       October 2010


   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.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  System Architecture Requirements . . . . . . . . . . . . .  6
     2.3.  Requirements for Virtual Network Management
           Information Model  . . . . . . . . . . . . . . . . . . . .  8
   3.  Relationships to Existing MIBs . . . . . . . . . . . . . . . .  9
     3.1.  Relationships to LLDP-MIB  . . . . . . . . . . . . . . . .  9
     3.2.  Relationships to ENTITY-MIB  . . . . . . . . . . . . . . .  9
   4.  Proposals of Virtual Network Management Information Model  . . 11
     4.1.  TargetedNetwork Object . . . . . . . . . . . . . . . . . . 11
     4.2.  PhysicalNetwork Object . . . . . . . . . . . . . . . . . . 12
     4.3.  VirtualNetwork Object  . . . . . . . . . . . . . . . . . . 14
     4.4.  Id Object  . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  XML-based Implementation of the Proposed Information Model . . 18
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26



















Okita & Yoshizawa        Expires April 28, 2011                 [Page 2]


Internet-Draft      Virtual Network Information Model       October 2010


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 data center
   networks therefore have to use multiple management systems for
   managing the whole data center 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 a data center
   containing virtual switches.  Section 2 describes the model
   requirements, Section 3 describes the relationships to the existing
   MIBs, Section 4 defines the model, and Section 5 evaluates the model.

























Okita & Yoshizawa        Expires April 28, 2011                 [Page 3]


Internet-Draft      Virtual Network Information Model       October 2010


2.  Requirements

2.1.  Problem Statement

   Virtual switches cause a difficulty in managing data center networks.
   They expand the data center network into the server virtualization
   platforms.  Therefore, to manage the whole network structure of data
   center networks, network operators have to manage virtual switches in
   addition to physical switches.

   To manage these virtual and physical switches, 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 data center network management system.


































Okita & Yoshizawa        Expires April 28, 2011                 [Page 4]


Internet-Draft      Virtual Network Information Model       October 2010


                       +-----------+
                       |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 ||
   |     +-------+|
   +--------------+


       Figure 1: Overview of a data center network management system

   This conventional management architecture causes the following two
   problems which increase the operation time taken by operators of the
   data center 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.

   To solve these problems and save the operation time for data center
   networks, the following two requirements must be met.




Okita & Yoshizawa        Expires April 28, 2011                 [Page 5]


Internet-Draft      Virtual Network Information Model       October 2010


   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.

2.2.  System Architecture Requirements

   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 & Yoshizawa        Expires April 28, 2011                 [Page 6]


Internet-Draft      Virtual Network Information Model       October 2010


                     +-----------+     +-----------+
                     |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 & Yoshizawa        Expires April 28, 2011                 [Page 7]


Internet-Draft      Virtual Network Information Model       October 2010


   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.

2.3.  Requirements for Virtual Network Management Information Model

   This document focuses on an information model for the virtual-network
   management information described in the previous section.  The
   requirements for the information model are listed below.  These
   requirements arise from the two problems stated above.

   1.  Connection Information: The proposed model should represent a
       connection between virtual switches, a connection between
       physical switches, and a connection between a virtual switch and
       a physical switch in the target network.

   2.  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 & Yoshizawa        Expires April 28, 2011                 [Page 8]


Internet-Draft      Virtual Network Information Model       October 2010


3.  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.

3.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.3 for the virtual network management information model.

3.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 & Yoshizawa        Expires April 28, 2011                 [Page 9]


Internet-Draft      Virtual Network Information Model       October 2010


   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.3 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.3 for the virtual network management information model.


























Okita & Yoshizawa        Expires April 28, 2011                [Page 10]


Internet-Draft      Virtual Network Information Model       October 2010


4.  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.3.  The model is an abstract-information model independent from
   encoding schemes and management protocols.  The model is written in
   Unified Modeling Language (UML) [UML] .

4.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 3 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.5)
    |                   |0...n
    |                   |
    |                   |1
    |                  <>
    |            +---------------+
    +------------|PhysicalNetwork|------Physical network related objects
            0..* +---------------+      (Figure.4)




Okita & Yoshizawa        Expires April 28, 2011                [Page 11]


Internet-Draft      Virtual Network Information Model       October 2010


    Figure 3: Class diagram of the proposed virtual-network management
                             information model

4.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 & Yoshizawa        Expires April 28, 2011                [Page 12]


Internet-Draft      Virtual Network Information Model       October 2010


   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 4 shows an abstract class diagram of the objects related to
   the physical network.














Okita & Yoshizawa        Expires April 28, 2011                [Page 13]


Internet-Draft      Virtual Network Information Model       October 2010


   +---------------+
   |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 4: Class diagram of physical-network-related objects

4.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 & Yoshizawa        Expires April 28, 2011                [Page 14]


Internet-Draft      Virtual Network Information Model       October 2010


   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 5 shows an abstract class diagram of the objects related to
   the virtual network.





Okita & Yoshizawa        Expires April 28, 2011                [Page 15]


Internet-Draft      Virtual Network Information Model       October 2010


   +---------------+
   |TargetedNetwork|
   +---------------+
          <>
           |1            0..*  +--------------+
           +-------------------|VirtualNetwork|
                               +--------------+
                                    <>
           +----------------+        |1
           |VirtualNodeGroup|        |
           +----------------+        |
               1..* |  <>            |
                    |   |1           |
                    |   +----------+ |
                    |         1..* | |0..*
                    |          +-----------+
                    |          |VirtualNode|
                    |          +-----------+
                    |               <>
                    |                |1
                    |                |
                    |                |0..*
                    |          +---------+         +-------+
                    |          |Virtual  |-------<>|Virtual|
                   1|          |Interface|2   0..1 |Link   |
                   <>          +---------+         +-------+
             +------------+
             |PhysicalNode|
             +------------+


        Figure 5: Class diagram of virtual-network-related objects

4.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 & Yoshizawa        Expires April 28, 2011                [Page 16]


Internet-Draft      Virtual Network Information Model       October 2010


   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 & Yoshizawa        Expires April 28, 2011                [Page 17]


Internet-Draft      Virtual Network Information Model       October 2010


5.  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-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 & Yoshizawa        Expires April 28, 2011                [Page 18]


Internet-Draft      Virtual Network Information Model       October 2010


     <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 & Yoshizawa        Expires April 28, 2011                [Page 19]


Internet-Draft      Virtual Network Information Model       October 2010


         <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 & Yoshizawa        Expires April 28, 2011                [Page 20]


Internet-Draft      Virtual Network Information Model       October 2010


       <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 & Yoshizawa        Expires April 28, 2011                [Page 21]


Internet-Draft      Virtual Network Information Model       October 2010


6.  Summary

   This document proposes a management information model for a virtual
   network in a data center network.  This information model can
   represent the network structure of a virtual network composed of
   virtual switches and physical switches.  It can also represent the
   mapping between the virtual switch and the physical switch.

   The network management system, which manages virtual-network
   management information according to the proposed information model,
   reduced VLAN configuration time by 35%.  This result demonstrates
   that the virtual-network management information model is effective in
   reducing the management time of a data center network containing
   virtual switches.

   The proposed management information model does not contain
   implementation specifications.  Therefore, to implement the
   information model, developers have to select an encoding scheme and a
   management protocol for transporting management information data.
   For example, developers can use SNMP and MIB specified in the
   Internet-standard management framework [RFC3410] or an XML
   [W3C.REC-xml] -based management framework [RFC3535]





























Okita & Yoshizawa        Expires April 28, 2011                [Page 22]


Internet-Draft      Virtual Network Information Model       October 2010


7.  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 & Yoshizawa        Expires April 28, 2011                [Page 23]


Internet-Draft      Virtual Network Information Model       October 2010


8.  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 & Yoshizawa        Expires April 28, 2011                [Page 24]


Internet-Draft      Virtual Network Information Model       October 2010


9.  References

9.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.

   [UML]      OMG, "Unified Modeling Language", September 2002,
              <http://www.omg.org/technology/documents/formal/uml.htm>.

9.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]
              Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
              "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
              xml, October 2000, <http://www.w3.org/TR/REC-xml>.









Okita & Yoshizawa        Expires April 28, 2011                [Page 25]


Internet-Draft      Virtual Network Information Model       October 2010


Authors' Addresses

   Hideki Okita
   Central Research Laboratory, Hitachi, Ltd.
   292 Yoshida-cho, Totsuka
   Yokohama, Kanagawa  244-0817
   Japan

   Phone: +81-45-860-2155
   Fax:   +81-45-860-2113
   Email: hideki.okita.pf@hitachi.com


   Masahiro Yoshizawa
   Central Research Laboratory, Hitachi, Ltd.
   292 Yoshida-cho, Totsuka
   Yokohama, Kanagawa  244-0817
   Japan

   Phone: +81-45-860-2138
   Fax:   +81-45-860-2113
   Email: masahiro.yoshizawa.bt@hitachi.com





























Okita & Yoshizawa        Expires April 28, 2011                [Page 26]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/