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 | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | 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. Iijima, et al. Expires March 2, 2008 [Page 7] Internet-Draft VLAN data model for NETCONF August 2007 Iijima, et al. Expires March 2, 2008 [Page 8] Internet-Draft VLAN data model for NETCONF August 2007 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. 100 VLAN0100 port 0/7 port 0/11 UNTAGGED_PORT 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 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 , . [4] "Interoperability Technology Association for Information Processing(INTAP), Japan" . [5] "Open Systems Management Industry Collaboration(OSMIC)". 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]