idnits 2.17.00 (12 Aug 2021) /tmp/idnits48566/draft-jxf-i2rs-im-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3133 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3444' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 273, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Ji 3 Internet-Draft G. Yan 4 Intended status: Experimental Huawei Technologies 5 Expires: April 21, 2014 Y. Jin 6 SJTU 7 October 21, 2013 9 An information model atchitecture of network device 10 draft-jxf-i2rs-im-architecture-01 12 Abstract 14 Currently, network equipment already has some Northbound Interfaces, 15 such as SNMP, NETCONF, TL1; and some languages are also provided to 16 describe the data model, such as MIB, SCHEMA and even YANG. While 17 till now, there is not a clear defined information model. In NETCONF 18 domain, some standards are being defined. In order to reduce the 19 cost of NMS integration in customer side, a clear defined information 20 model is necessary, just like the SID in TMF. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 21, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. The overview of information model of network equipment . . . 3 64 2.1. The infrastructure plane . . . . . . . . . . . . . . . . 3 65 2.2. The network service plane . . . . . . . . . . . . . . . . 4 66 3. The layer . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. System Inventory Objects Layer . . . . . . . . . . . . . 4 68 3.2. The System Management Layer . . . . . . . . . . . . . . . 4 69 3.3. The network container layer . . . . . . . . . . . . . . . 4 70 3.4. The network policy layer . . . . . . . . . . . . . . . . 5 71 3.5. The network resource layer . . . . . . . . . . . . . . . 5 72 3.6. The network protocol layer . . . . . . . . . . . . . . . 5 73 3.7. The network service layer . . . . . . . . . . . . . . . . 6 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Currently, network equipment already has some Northbound Interfaces, 83 such as SNMP, NETCONF, TL1; and some languages are also provided to 84 describe the data model, such as MIB, SCHEMA and even YANG. While 85 till now, there is not a clear defined information model. In NETCONF 86 domain, some standards are being defined. In order to reduce the 87 cost of NMS integration in customer side, a clear defined information 88 model is necessary, just like the SID in TMF. 90 In order to understand the difference between information model and 91 data model, please refer to the RFC3444. 93 This document will introduce a set of information models. We hope 94 this model could help the engineer define the model of network 95 service described by SCHEMA or YANG. 97 2. The overview of information model of network equipment 99 This information model is very important. All interfaces design and 100 implementation will use this model, such as MIB, Schema and TL1, even 101 RESTful API. 103 The following figure illustrates the architecture of this information 104 model: 106 P-------------------------------------------------------------------- 107 | Network Service Plane 108 | L--------------------------------------------------------------- 109 | | Network Service Layer 110 | L--------------------------------------------------------------- 111 | | Network Protocol Layer 112 | L--------------------------------------------------------------- 113 | | Network Resource Layer 114 | L--------------------------------------------------------------- 115 | | Network Policy Layer 116 | L--------------------------------------------------------------- 117 | | Network Continer Layer 118 | +--------------------------------------------------------------- 119 P ------------------------------------------------------------------- 120 | Infrastructure Plane 121 | L--------------------------------------------------------------- 122 | | System Management Layer 123 | L--------------------------------------------------------------- 124 | | System Inventory Objects Layer (Software and Hardware) 125 | +--------------------------------------------------------------- 126 | ------------------------------------------------------------------- 128 2.1. The infrastructure plane 130 The infrastructure plane provides a minimum set of functions to 131 support the running system, And this plane can be deployed 132 independently, which will not be affected by upper layer. 134 This plane also provides the API to operate the hardware and 135 software, such as software installation, upgrade, and so on. 137 It has no relation with IP associated service and can be applied to 138 other embedded system device. 140 2.2. The network service plane 142 The network service plane provides the model definition of all 143 network communication services, which can be divided into five 144 layers: Service Layer, Protocol Layer, Resource Layer, Policy Layer 145 and Container Layer. Based on the interfaces provided by 146 infrastructure plane, all network services can be distributed on some 147 deployment units that can be main board, I/O board or one CPU of 148 multiple CPUs system. 150 3. The layer 152 3.1. System Inventory Objects Layer 154 L-------------------------------------------------------------------------- 155 | System Inventory Objects Layer 156 | M----------------+ M-------------+ M-------------+ M----------------+ 157 | | Logical System | | Device Mgmt.| | File System | | Component Mgmt.| 158 | +----------------+ +-------------+ +-------------+ +----------------+ 159 +-------------------------------------------------------------------------- 161 The system inventory Layer provides the model definition to manage 162 all hardware, logical device or virtual system, it include device 163 management, file management, the system component management. 165 3.2. The System Management Layer 167 L-------------------------------------------------------------------------- 168 | System Management Layer 169 | M-------------+ M-------------------------+ M---------------------+ 170 | | System Info | | Softwate Install&Update | | Sys Porcess Monitor | 171 | +-------------+ +-------------------------+ +---------------------+ 172 +-------------------------------------------------------------------------- 174 This layer provides the model of OS, like software installation, 175 upgrade, like the monitor of system process. The function of some 176 basic MIB will be placed here, such as the system MIB of RFC1213. 178 3.3. The network container layer 179 L-------------------------------------------------------------------------- 180 | Network Container Layer 181 | M-------+ M-------+ M------+ 182 | | L3VPN | | L2VPN | | VLAN | 183 | +-------+ +-------+ +------+ 184 +-------------------------------------------------------------------------- 186 The container layer is defined to support some network level object 187 and provides the key of network, or virtual network, and some top 188 level attribute, such as ID, NAME, TYPE, and so on. 190 3.4. The network policy layer 192 L-------------------------------------------------------------------------- 193 | Network Policy Layer 194 | M-----+ M--------------+ M------------+ 195 | | ACL | | Route Policy | | QoS Policy | 196 | +-----+ +--------------+ +------------+ 197 +-------------------------------------------------------------------------- 199 This layer defines the network security, Quality of Service, Route 200 policy. 202 3.5. The network resource layer 204 L-------------------------------------------------------------------------- 205 | Network Resource Layer 206 | M-----------------+ M--------------+ M-----------------+ M------+ 207 | | Interface Mgmt. | | Tunnle Mgmt. | | QoS Queue Mgmt. | | Topo | 208 | +-----------------+ +--------------+ +-----------------+ +------+ 209 +-------------------------------------------------------------------------- 211 The network resource layer manages the resource, such as interface, 212 tunnel, and topology. 214 3.6. The network protocol layer 216 L-------------------------------------------------------------------------- 217 | Network Protocol Layer 218 | M------------------+ M-------------+ M-------------------------+ 219 | | Routing Protocol | | L2 Protocol | | Management APP Protocol | 220 | +------------------+ +-------------+ +-------------------------+ 221 +-------------------------------------------------------------------------- 222 This layer includes the model of almost all functions supported by 223 current network device, like the routing protocol, L2 protocol, MPLS 224 and associated protocol, even all management protocol, like SNMP, 225 Telnet. 227 3.7. The network service layer 229 L-------------------------------------------------------------------------- 230 | Network Service Layer 231 | M----------------------+ M--------------+ M-------------+ 232 | | Built-in Service APP | | SLA TOOL APP | | OM TOOL APP | 233 | +----------------------+ +--------------+ +-------------+ 234 +-------------------------------------------------------------------------- 236 The network service layer includes the model of service or 237 application level, like SLA tools application, this application face 238 the requirement of the end user, not the network protocol. Normally, 239 this layer is not distributed in the network device, but sometimes, 240 there are some built-in applications, like NQA. 242 The module in this layer cannot depend each other and can only depend 243 on the bottom layer. 245 4. Security Considerations 247 NA 249 5. IANA Considerations 251 NA 253 6. Acknowledgements 255 NA 257 7. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 263 Information Models and Data Models", RFC 3444, January 264 2003. 266 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 267 Network Configuration Protocol (NETCONF)", RFC 6020, 268 October 2010. 270 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 271 October 2010. 273 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 274 Bierman, "Network Configuration Protocol (NETCONF)", RFC 275 6241, June 2011. 277 Authors' Addresses 279 Xiaofeng Ji 280 Huawei Technologies 281 Huawei Bld., No.156 Beiqing Rd. 282 Beijing 100095 283 China 285 Email: jixiaofeng@huawei.com 287 Yaohui Jin 288 Shanghai Jiao Tong University 289 China 291 Email: jinyh@sjtu.edu.cn 293 Gang Yan 294 Huawei Technologies 295 Huawei Bld., No.156 Beiqing Rd. 296 Beijing 100095 297 China 299 Email: yangang@huawei.com