Internet DRAFT - draft-iijima-ngo-acldatamodel
draft-iijima-ngo-acldatamodel
Network Working Group T. Iijima
Internet-Draft Y. Atarashi
Intended status: Informational H. Kimura
Expires: June 29, 2008 M. Kitani
Alaxala Networks Corp.
H. Okita
Central Research Laboratory,
Hitachi, Ltd.
December 27, 2007
ACL data model for NETCONF
draft-iijima-ngo-acldatamodel-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 June 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Iijima, et al. Expires June 29, 2008 [Page 1]
Internet-Draft ACL data model for NETCONF December 2007
Abstract
Data models are to be discussed within the NETCONF framework shortly.
We devised data model of ACL(Access Control List) 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 which NETCONF protocol carry.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Data modeling for NETCONF . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Data model over NETCONF . . . . . . . . . . . . . . . . . . . 4
3. ACL data model . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Class diagram of ACL data model . . . . . . . . . . . . . 5
3.2. ACL schema of ACL data model . . . . . . . . . . . . . . . 6
3.3. Application using ACL data model . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Iijima, et al. Expires June 29, 2008 [Page 2]
Internet-Draft ACL data model for NETCONF December 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 ACL data model and moreover
developed a network configuration application using that data model.
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 June 29, 2008 [Page 3]
Internet-Draft ACL data model for NETCONF December 2007
2. Data model over NETCONF
NETCONF's architecture is provided in Figure 1. As this figure
shows, layers 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 June 29, 2008 [Page 4]
Internet-Draft ACL data model for NETCONF December 2007
3. ACL data model
In this section, we provide ACL 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
a highly simplified class diagram.
3.1. Class diagram of ACL data model
Figure 2 shows the highly simplified class diagram of ACL data model.
+-------------------------------------------------+
| AccessList |
|+ flowId |
|+ FlowDescInfo[] |
+-------------------------------------------------+
<>
|
|
+-------------------------------------------------+
| FlowDescInfo |
|+ action |
+-------------------------------------------------+
A A A A
| | | |
| | | |
+------------+ +------------+ +------------+ +--------------+
| FlowLayer2 | | FlowLayer3 | | FlowLayer3 | | FlowLayer3V6 |
| Standard | | Standard | | Extended | | Extended |
+------------+ +------------+ +------------+ +--------------+
|+ srcMac | |+ srcIpv4 | |+ srcIpv4 | |+ srcIpv6 |
|+ dstMac | | | |+ dstIpv4 | |+ dstIpv6 |
|+ ethType | | | |+ protocol | |+ protocol |
|+ vlanId | | | |+ tos | |+ vlanId |
| | | | |+ srcPort | | |
| | | | |+ dstPort | | |
| | | | |+ ackFlag | | |
| | | | |+ synFlag | | |
| | | | |+ vlanId | | |
| | | | |+ srcIpRange| | |
| | | | |+ dstIpRange| | |
| | | | |+ srcPtRange| | |
| | | | |+ dstPtRange| | |
+------------+ +------------+ +------------+ +--------------+
<>:association (has-a)
A :inheritance (is-a)
Iijima, et al. Expires June 29, 2008 [Page 5]
Internet-Draft ACL data model for NETCONF December 2007
Figure 2: ACL's class diagram
AccessList class has FlowDescInfo class as well as some variables
such as Flow ID. And FlowDescInfo class is used by being inherited
as FlowLayer2Standard, FlowLayer3Standard, FlowLayer3Extended, and
FlowLayer3V6Extended class. If one particular Flow ID is used for
standard layer2 ACL and standard layer3 ACL, the ACL information is
set in the FlowLayer2Standard class and the FlowLayer3Standard class.
And AccessList class which contains the FlowLayer2Standard and the
FlowLayer3Standard class is configured and the configured data are
sent over the NETCONF protocol.
3.2. ACL schema of ACL data model
From the class diagram illustrated in the previous section, ACL'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:element name="FlowId" type="nm1_1:FlowIdType"></xs:element>
<xs:element name="AccessList" type="nm1_1:AccessListType"></xs:element>
<xs:element name="NumberSequenceInfo" type="nm1_1:NumberSequenceInfoType"></xs:element>
<xs:complexType name="AccessListType">
<xs:sequence>
<xs:element ref="nm1_1:FlowId"></xs:element>
<xs:element name="Remark" type="xs:string" maxOccurs="1"
minOccurs="0">
</xs:element>
<xs:element ref="nm1_1:NumberSequenceInfo" maxOccurs="1" minOccurs="0"/>
<xs:choice>
<xs:element ref="nm1_1:FlowDescInfo"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element ref="nm1_1:FlowLayer2Standard"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
Iijima, et al. Expires June 29, 2008 [Page 6]
Internet-Draft ACL data model for NETCONF December 2007
<xs:element ref="nm1_1:FlowLayer3Standard"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element ref="nm1_1:FlowLayer3v6Extended"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element ref="nm1_1:FlowLayer3Extended"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
</xs:choice>
</xs:sequence>
<xs:attribute name="operation" type="ncp:editOperationType" />
</xs:complexType>
<xs:complexType name="NumberSequenceInfoType">
<xs:sequence>
<xs:element name="StartingSeq" type="xs:integer"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="IncrementSeq" type="xs:integer"
maxOccurs="1" minOccurs="0">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FlowDescInfoType">
<xs:sequence>
<xs:element name="Sequence" type="xs:integer" maxOccurs="1" minOccurs="0"></xs:element>
<xs:element ref="nm1_1:Action" maxOccurs="1" minOccurs="0"/>
<xs:element name="AccessListInfo" type="xs:string" maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="Filter" type="nm1_1:Filter"/>
<xs:element name="Action" type="nm1_1:ActionType"/>
<xs:complexType name="ActionType">
<xs:sequence>
<xs:element ref="nm1_1:Filter" maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FlowLayer2StandardType">
<xs:complexContent>
<xs:extension base="nm1_1:FlowDescInfoType">
<xs:sequence maxOccurs="1" minOccurs="0">
<xs:element name="SourceMac" type="nm1_0:MacAddress"
maxOccurs="1" minOccurs="0">
</xs:element>
Iijima, et al. Expires June 29, 2008 [Page 7]
Internet-Draft ACL data model for NETCONF December 2007
<xs:element name="DestinationMac"
type="nm1_0:MacAddress" maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="EthernetType" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element ref="nm1_0:VlanId" maxOccurs="1"
minOccurs="0">
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="FlowLayer3StandardType">
<xs:complexContent>
<xs:extension base="nm1_1:FlowDescInfoType">
<xs:sequence>
<xs:element name="SourceIP" type="nm1_0:IPV4Address"
maxOccurs="1" minOccurs="1">
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="FlowLayer3ExtendedType">
<xs:complexContent>
<xs:extension base="nm1_1:FlowDescInfoType">
<xs:sequence>
<xs:element name="SourceIP" type="nm1_0:IPV4Address"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="DestinationIP"
type="nm1_0:IPV4Address" maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="Protocol" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="Tos" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="SourcePort" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="DestinationPort" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
Iijima, et al. Expires June 29, 2008 [Page 8]
Internet-Draft ACL data model for NETCONF December 2007
<xs:element name="AckFlag" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="SynFlag" type="xs:string"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element ref="nm1_0:VlanId" maxOccurs="1"
minOccurs="0">
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="FlowLayer3v6ExtendedType">
<xs:complexContent>
<xs:extension base="nm1_1:FlowDescInfoType">
<xs:sequence>
<xs:element name="SourceIP" type="nm1_0:IPV6Address"
maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="DestinationIP"
type="nm1_0:IPV6Address" maxOccurs="1" minOccurs="0">
</xs:element>
<xs:element name="Protocol" type="xs:string" maxOccurs="1" minOccurs="0"></xs:element>
<xs:element ref="nm1_0:VlanId" maxOccurs="1"
minOccurs="0">
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="FlowLayer2Standard" type="nm1_1:FlowLayer2StandardType"></xs:element>
<xs:element name="FlowLayer3Standard" type="nm1_1:FlowLayer3StandardType"></xs:element>
<xs:element name="FlowLayer3v6Extended"
type="nm1_1:FlowLayer3v6ExtendedType">
</xs:element>
<xs:element name="FlowLayer3Extended" type="nm1_1:FlowLayer3ExtendedType"></xs:element>
<xs:element name="AccessLists">
<xs:complexType>
<xs:sequence>
<xs:element ref="nm1_1:AccessList" maxOccurs="unbounded" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
Iijima, et al. Expires June 29, 2008 [Page 9]
Internet-Draft ACL data model for NETCONF December 2007
<xs:element name="FlowDescInfo" type="nm1_1:FlowDescInfoType"></xs:element>
<xs:complexType name="IfAccessListType">
<xs:sequence>
<xs:element name="FilterIn" minOccurs="0" form="qualified">
<xs:complexType>
<xs:sequence>
<xs:element ref="nm1_1:FlowId"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="FilterOut" minOccurs="0" form="qualified">
<xs:complexType>
<xs:sequence>
<xs:element ref="nm1_1:FlowId" maxOccurs="unbounded" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FlowIdType">
<xs:sequence>
<xs:element name="Id" type="xs:string" maxOccurs="1" minOccurs="0" form="qualified"></xs:element>
<xs:element name="Type" type="xs:string" maxOccurs="1"
minOccurs="0">
</xs:element>
<xs:element name="FlowType" type="xs:string" maxOccurs="1" minOccurs="0"></xs:element>
<xs:element name="Detect" type="xs:string" maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PortAccessListType">
<xs:complexContent>
<xs:extension base="nm1_1:IfAccessListType">
<xs:sequence>
<xs:element ref="nm1_0:PortId" maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="operation" type="ncp:editOperationType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="VlanAccessListType">
<xs:complexContent>
<xs:extension base="nm1_1:IfAccessListType">
<xs:sequence>
Iijima, et al. Expires June 29, 2008 [Page 10]
Internet-Draft ACL data model for NETCONF December 2007
<xs:element ref="nm1_0:VlanId" maxOccurs="1" minOccurs="0"></xs:element>
<xs:element name="MacMode" type="xs:string" maxOccurs="1" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="operation" type="ncp:editOperationType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="IfAccessLists">
<xs:complexType>
<xs:sequence>
<xs:element ref="nm1_1:PortAccessList"
maxOccurs="unbounded" minOccurs="0">
</xs:element>
<xs:element ref="nm1_1:VlanAccessList" maxOccurs="unbounded" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="Filter">
<xs:restriction base="xs:string">
<xs:enumeration value="permit"></xs:enumeration>
<xs:enumeration value="deny"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:element name="VlanAccessList" type="nm1_1:VlanAccessListType"></xs:element>
<xs:element name="PortAccessList" type="nm1_1:PortAccessListType"></xs:element>
<xs:element name="PortId" type="nm1_1:PortIdType"></xs:element>
<xs:simpleType name="PortIdType">
<xs:restriction base="xs:string">
<xs:pattern value=".*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="VlanIdType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="4095"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Iijima, et al. Expires June 29, 2008 [Page 11]
Internet-Draft ACL data model for NETCONF December 2007
3.3. Application using ACL 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.
Lists of ACL are wrote down in the spreadsheet file in advance. The
configuration application developed using the ACL data model can open
and read the file. Then, the configuration application reads the
lists of ACL line by line and transforms them into a NETCONF request
message conforming to the XML schema listed before. And the
configuration application sends the NETCONF request message and
configures the network device accordingly.
+-----------------------+
| Configuration |
| Application |
| |
| +---------------+ |
| | Spreadsheet | |
| | File | |
| |(Lists of ACL) | |
| +---------------+ |
+-----------------------+
| ^
| |
NETCONF request/reply
| |
v |
+---------------+
| Network |
| Device |
+---------------+
Figure 3: Application using ACL data model
Iijima, et al. Expires June 29, 2008 [Page 12]
Internet-Draft ACL data model for NETCONF December 2007
4. 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 June 29, 2008 [Page 13]
Internet-Draft ACL data model for NETCONF December 2007
5. IANA Considerations
This document has no actions for IANA.
Iijima, et al. Expires June 29, 2008 [Page 14]
Internet-Draft ACL data model for NETCONF December 2007
6. References
6.1. Normative References
[1] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
6.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>.
Iijima, et al. Expires June 29, 2008 [Page 15]
Internet-Draft ACL data model for NETCONF December 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.net
Iijima, et al. Expires June 29, 2008 [Page 16]
Internet-Draft ACL data model for NETCONF December 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 June 29, 2008 [Page 17]
Internet-Draft ACL data model for NETCONF December 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 June 29, 2008 [Page 18]
