Internet DRAFT - draft-iijima-ngo-vlandatamodel
draft-iijima-ngo-vlandatamodel
Network Working Group T. Iijima
Internet-Draft Y. Atarashi
Intended status: Informational H. Kimura
Expires: March 2, 2008 M. Kitani
Alaxala Networks Corp.
H. Okita
Central Research Laboratory,
Hitachi, Ltd.
August 30, 2007
VLAN data model for NETCONF
draft-iijima-ngo-vlandatamodel-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Iijima, et al. Expires March 2, 2008 [Page 1]
Internet-Draft VLAN data model for NETCONF August 2007
Abstract
Data models are to be discussed within the NETCONF framework shortly.
We devised data model of VLAN and moreover developed a network
configuration application using the data model. This document
introduces the data model which we developed so that it facilitates
discussion of data model under which NETCONF protocol should run.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Data modeling for NETCONF . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposal to the INTAP/OSMIC . . . . . . . . . . . . . . . . . 4
3. Data model over NETCONF . . . . . . . . . . . . . . . . . . . 5
4. VLAN data model . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Class diagram of VLAN data model . . . . . . . . . . . . . 6
4.2. XML schema of VLAN data model . . . . . . . . . . . . . . 7
4.3. Application using VLAN data model . . . . . . . . . . . . 9
4.4. Request message from configuration application . . . . . . 10
4.5. Reply message from network device . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Iijima, et al. Expires March 2, 2008 [Page 2]
Internet-Draft VLAN data model for NETCONF August 2007
1. Introduction
1.1. Data modeling for NETCONF
Data modeling of configuration data of each network function is
necessary in order to achieve interoperability among NETCONF
entities. For that purpose, we devised VLAN data model and moreover
developed a network configuration application using that data model.
In addition to that, we proposed it to Japanese standardization body
and it was approved as a standard. Interoperability test using our
data model among multi vendors will be held in a near future.
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2].
1.3. Motivation
This document opens our data model to public so that it facilitates
discussion of data model by which NETCONF configures each network
device. This document is aiming to be accepted as a reference to the
NETCONF data model.
Iijima, et al. Expires March 2, 2008 [Page 3]
Internet-Draft VLAN data model for NETCONF August 2007
2. Proposal to the INTAP/OSMIC
We proposed our VLAN data model to the INTAP/OSMIC, Japanese
standardization body. And it was adopted as standard data model
after a thorough discussion. Now that the data models we defined are
approved by INTAP/OSMIC, we can utilize this data model and conduct
interoperability experiment with other vendors.
INTAP is an association established in 1985, based on the provisions
of Article 34 of Japan's Civil Law Act, and approved by the then
Ministry of International Trade and Industry, in order to conduct and
promote R&D, surveys and publicity activities. Through those
activities, the association seeks to stimulate the progress of
information technologies, which should contribute to the formation of
a healthy information society.
OSMIC is one of the sub-committees of INTAP and mainly in charge of
interoperability. OSMIC's activity is to implement and evaluate
interoperability among implementations of multi vendors. After we
proposed our VLAN data model to OSMIC, it started verification
whether or not our data model rightly satisfy implementer's needs.
Participating vendors will implement and conduct interoperability
test shortly. The data model is expected to be refined by taking the
outcome into consideration and promotion activities will follow.
Iijima, et al. Expires March 2, 2008 [Page 4]
Internet-Draft VLAN data model for NETCONF August 2007
3. Data model over NETCONF
NETCONF's architecture is provided in Figure 1. As this figure
shows, layer of operation, RPC, and application protocol have been
standardized. However, content layer, which is the configuration
data exchanged over NETCONF protocol, has been left out from NETCONF
standardization process. In order to achieve interoperability among
NETCONF entities, data modeling of configuration data is necessary.
Layer Example
+-------------+ +-----------------------------+
| Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Operations | | <get-config>, <edit-config> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| RPC | | <rpc>, <rpc-reply> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+
Figure 1: NETCONF architecture
Iijima, et al. Expires March 2, 2008 [Page 5]
Internet-Draft VLAN data model for NETCONF August 2007
4. VLAN data model
In this section, we provide VLAN data model which we developed. The
data model was originally designed in a style of UML(Unified Modeling
Language) class diagram. But, due to the paper limitation, we listed
just highly simplified class diagram.
4.1. Class diagram of VLAN data model
Figure 2 shows the highly simplified class diagram of VLAN data
model.
+---------------------------------------------------+
| VLAN |
| |
+---------------------------------------------------+
<>
|
|
+---------------------------------------------------+
| AssortmentPort |
| |
+---------------------------------------------------+
A A A A A
| | | | |
| | | | |
+--------+ +-----------+ +----------+ +----------+ +----------+
| Tagged | | Protocol | | MacBased | | IpSubnet | | Untagged |
| Port | | BasedPort | | Port | | Port | | Port |
| | | | | | | | | |
+--------+ +-----------+ +----------+ +----------+ +----------+
<>:association (has-a)
A :inheritance (is-a)
Figure 2: VLAN's class diagram
VLAN class has AssortmentPort class as well as some variables such as
VLAN ID. And AssortmentPort class is used by being inherited as
TaggedPort, ProtocolBasedPort, MacBasedPort, IpSubnetPort, and
UntaggedPort class. If one particular VLAN ID is used for Tag VLAN
and Port VLAN, the port information is set in the Tagged Port class
and the Untagged port class. And VLAN class which contains the
TaggedPort and the UntaggedPort class is configured and the
configured data are sent over the NETCONF protocol.
Iijima, et al. Expires March 2, 2008 [Page 6]
Internet-Draft VLAN data model for NETCONF August 2007
4.2. XML schema of VLAN data model
From the class diagram depicted in the previous section, VLAN's XML
schema can be generated. The configuration data are sent in a style
conforming to this XML schema.
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="onapi-datamodel_1.1"
targetNamespace="urn:net:alaxala:oan:onapi:commons:netmod:1.1"
xmlns:ncp="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:nm1_0="urn:net:alaxala:oan:onapi:commons:netmod:1.0"
xmlns:nm1_1="urn:net:alaxala:oan:onapi:commons:netmod:1.1">
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="netconf-base_1.0.xsd"/>
<xs:import namespace="urn:net:alaxala:oan:onapi:commons:netmod:1.0" schemaLocation="onapi-datamodel_1.0.xsd" />
<xs:complexType name="TaggedPortType">
<xs:complexContent>
<xs:extension base="nm1_1:AssortmentPortType">
<xs:sequence>
<xs:element name="TransTag" type="xs:integer" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="AssortmentPortType">
<xs:sequence>
<xs:element ref="nm1_0:PortId" minOccurs="0" maxOccurs="unbounded"></xs:element>
<xs:element name="Type" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ProtocolBasedPortType">
<xs:complexContent>
<xs:extension base="nm1_1:AssortmentPortType">
<xs:sequence>
<xs:element name="Protocol" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="MacBasedPortType">
<xs:complexContent>
<xs:extension base="nm1_1:AssortmentPortType">
<xs:sequence>
<xs:element name="MacAddress" type="nm1_0:MacAddress" maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:extension>
Iijima, et al. Expires March 2, 2008 [Page 7]
Internet-Draft VLAN data model for NETCONF August 2007
</xs:complexContent>
</xs:complexType>
<xs:complexType name="IpSubnetPortType">
<xs:complexContent>
<xs:extension base="nm1_1:AssortmentPortType">
<xs:sequence>
<xs:element name="SubNet" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="UntaggedPortType">
<xs:complexContent>
<xs:extension base="nm1_1:AssortmentPortType">
<xs:sequence />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="LogicalIF" type="nm1_0:LogicalIFType"/>
<xs:element name="TaggedPort" type="nm1_1:TaggedPortType"></xs:element>
<xs:element name="ProtocolBasedPort" type="nm1_1:ProtocolBasedPortType"/>
<xs:element name="MacBasedPort" type="nm1_1:MacBasedPortType"/>
<xs:element name="IpSubnetPort" type="nm1_1:IpSubnetPortType"/>
<xs:element name="UntaggedPort" type="nm1_1:UntaggedPortType"/>
<xs:element name="Vlans">
<xs:complexType>
<xs:sequence>
<xs:element ref="nm1_1:Vlan" maxOccurs="unbounded" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Vlan" type="nm1_1:VlanType"></xs:element>
<xs:complexType name="VlanType">
<xs:sequence>
<xs:element ref="nm1_0:VlanId"></xs:element>
<xs:element name="VlanName" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:LogicalIF" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:TaggedPort" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:ProtocolBasedPort" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:MacBasedPort" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:IpSubnetPort" minOccurs="0" maxOccurs="1" />
<xs:element ref="nm1_1:UntaggedPort" minOccurs="0" maxOccurs="1" />
</xs:sequence>
<xs:attribute name="operation" type="ncp:editOperationType" />
</xs:complexType>
<xs:simpleType name="VlanIdType">
<xs:restriction base="xs:integer">
Iijima, et al. Expires March 2, 2008 [Page 8]
Internet-Draft VLAN data model for NETCONF August 2007
<xs:minInclusive value="1"/>
<xs:maxInclusive value="4095"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
4.3. Application using VLAN data model
We developed a configuration application which exchanges NETCONF
messages conforming to XML schema listed in the previous section.
Figure 3 depicts the image of the configuration application we
developed.
The video server is connected to the network device on VLAN 100.
User A and B are connected to the network device at port 0/7 and port
0/11 respectively. When an operator allows user A and B to watch
video stream from video server, the operator runs configuration
application which sends NETCONF request message and sets port 0/7 and
port 0/11 to join VLAN 100.
+---------------+ +--------+
| Configuration | | Video |
| Application | | Server |
+---------------+ +--------+
| ^ |
| | |
NETCONF request/reply VLAN100
| | |
v | |
+--------------------+
| Network |
| Device |
+--------------------+
Port 0/7 Port 0/11
| |
| |
| |
+--------+ +--------+
| User A | | User B |
| | | |
+--------+ +--------+
Figure 3: Application using VLAN data model
Iijima, et al. Expires March 2, 2008 [Page 9]
Internet-Draft VLAN data model for NETCONF August 2007
4.4. Request message from configuration application
The request message sent from the configuration application to
network device, which conforms to the XML schema listed in 4.2, is
shown below.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc message-id="395">
<edit-config xsi:type="ns1:editConfigType" xmlns:ns1="urn:ietf:params:xml:ns:netconf:base:1.0">
<target>
<running xmlns=""></running>
</target>
<config>
<ns2:Vlans xmlns:ns2="urn:net:alaxala:oan:onapi:commons:netmod:1.0">
<ns2:Vlan operation="delete">
<VlanId xmlns="">100</VlanId>
<VlanName xmlns="">VLAN0100</VlanName>
<UntaggedPort xmlns="">
<PortId>port 0/7</PortId>
<PortId>port 0/11</PortId>
<Type>UNTAGGED_PORT</Type>
</UntaggedPort>
</ns2:Vlan>
</ns2:Vlans>
</config>
</edit-config>
</rpc>
</rpc>
</soapenv:Body>
</soapenv:Envelope>
Figure 4: Request message from configuration application
4.5. Reply message from network device
When the request message was successfully accepted, a message listed
in Figure 5, which is also conforming to the XML schema, is sent from
the network device to configuration application.
Iijima, et al. Expires March 2, 2008 [Page 10]
Internet-Draft VLAN data model for NETCONF August 2007
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-reply message-id="395">
<ok/>
</rpc-reply>
</rpc-reply>
</soapenv:Body>
</soapenv:Envelope>
Figure 5: Reply message from network device
Iijima, et al. Expires March 2, 2008 [Page 11]
Internet-Draft VLAN data model for NETCONF August 2007
5. Security Considerations
When we exchange NETCONF messages based on the data model we
proposed, security should be taken care of. WS-Security can achieve
secure data transportation by utilizing XML Signature, XML Encryption
mechanism.
Iijima, et al. Expires March 2, 2008 [Page 12]
Internet-Draft VLAN data model for NETCONF August 2007
6. IANA Considerations
This document has no actions for IANA.
Iijima, et al. Expires March 2, 2008 [Page 13]
Internet-Draft VLAN data model for NETCONF August 2007
7. References
7.1. Normative References
[1] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
7.2. Informative References
[2] Bradner, S. , "Key words for use in RFCs to Indicate
Requirement Levels" , BCP 14 , RFC 2119 , March 1997 .
[3] Sperberg-McQueen, C. , Bray, T. , and J. Paoli , "XML 1.0
Recommendation" , World Wide Web Consortium FirstEdition REC-
xml-19980210 , February 1998 ,
<http://www.w3.org/TR/1998/REC-xml-19980210> .
[4] "Interoperability Technology Association for Information
Processing(INTAP), Japan" .
<http://www.net.intap.or.jp/e/>
[5] "Open Systems Management Industry Collaboration(OSMIC)".
<http://www.net.intap.or.jp/e/3-6.html>
Iijima, et al. Expires March 2, 2008 [Page 14]
Internet-Draft VLAN data model for NETCONF August 2007
Authors' Addresses
Iijima Tomoyuki
Alaxala Networks Corp.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1200
Fax: +81-44-549-1272
Email: tomoyuki.iijima@alaxala.com
Yoshifumi Atarashi
Alaxala Networks Corp.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1200
Fax: +81-44-549-1272
Email: atarashi@alaxala.net
Hiroyasu Kimura
Alaxala Networks Corp.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1200
Fax: +81-44-549-1272
Email: h-kimura@alaxala.com
Iijima, et al. Expires March 2, 2008 [Page 15]
Internet-Draft VLAN data model for NETCONF August 2007
Makoto Kitani
Alaxala Networks Corp.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1200
Fax: +81-44-549-1272
Email: makoto.kitani@alaxala.com
Hideki Okita
Central Research Laboratory, Hitachi, Ltd.
1-280 Higashi-Koigakubo
Kokubunji, Tokyo 185-8601
Japan
Phone: +81-42-323-1111
Fax: +81-42-327-7868
Email: hideki.okita.pf@hitachi.com
Iijima, et al. Expires March 2, 2008 [Page 16]
Internet-Draft VLAN data model for NETCONF August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Iijima, et al. Expires March 2, 2008 [Page 17]
