idnits 2.17.1 draft-bogler-tmn-internet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 85 has weird spacing: '...-adding servi...' == Line 242 has weird spacing: '...cess to manag...' == Line 413 has weird spacing: '... bridge e.g...' == Line 524 has weird spacing: '...onality by en...' == Line 664 has weird spacing: '...agement eleme...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 1998) is 9595 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 700, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 703, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 706, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 728, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 733, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '4') ** Obsolete normative reference: RFC 1866 (ref. '5') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 1695 (ref. '13') (Obsoleted by RFC 2515) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 Networking Working Group Gerhard Bogler 4 Internet Draft Siemens AG 5 Expires January 16, 1998 7 Internet Technology for Integration of Carrier Network 8 Management (TMN) and Enterprise Network Management 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are 15 working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 ``work in progress.'' 25 To learn the current status of any Internet-Draft, please 26 check the ``1id-abstracts.txt'' listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 28 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 29 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 31 This memo provides information for the Internet community. 32 This memo does not specify an Internet standard of any kind. 33 Distribution of this memo is unlimited. 35 Abstract 37 The complexity of telecommunication networks, i.e. enterprise and 38 carrier networks, has grown over the last two decades. Management 39 of carrier networks and enterprise networks has followed different 40 paradigms up to now: 42 - In carrier networks the Telecommunications Management Network (TMN) 43 as created by ITU-T in the early 1980s is still being propagated. 45 - In enterprise networks the SNMP based approach is widely accepted. 47 The borders between public (carrier) and private (enterprise) networks 48 are becoming increasingly transparent, a distinction between both types 49 of networks may soon be irrelevant from a network management point of 50 view. 52 In the light of this development an integrating framework for network 53 management can be expected to gain rapid importance. 55 This Internet Draft shows that Internet technology and existing IETF 56 standards supplemented by a quite limited set of additional specifica- 57 tions can be used as the basis for a cooperative network management 58 approach, integrating management of both network management worlds while 59 leaving their interior essentially untouched. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Existing Management Frameworks . . . . . . . . . . . . . . . . . 3 65 3. Basic Requirements for a Framework for Integrated 66 Network Management . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Framework Architecture . . . . . . . . . . . . . . . . . . . . . 8 68 5. Areas for Work in the IETF . . . . . . . . . . . . . . . . . . .13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . .15 70 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . .15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . .15 72 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . .16 74 1. Introduction 76 1.1 Motivation: the Challenge for Integrated Network Management 78 Today, enterprise and carrier networks are converging. The discrimina- 79 tion between enterprise and carrier networks, between IT and telecommuni- 80 cation is fading. Some consequences for network management are: 82 - De-regulation in many countries allows organizations to be customers 83 (users) of a network as well as providers of a service. Network 84 management is shared among many parties: the "classical" network 85 operator ('Telco'), the value-adding service provider, the ISP, the 86 enterprise network user operating an own network, brokers/resellers 87 of network services etc. 89 - There is a need to integrate management for different types of nodes 90 as the underlying technologies are being more and more integrated. 91 Examples include but are not limited to: IP over ATM, MPOA 92 (Multiprotocol over ATM, standardized by the ATM-Forum), ATM over 93 SDH/Sonet. 95 - Some technologies which are commonly used in enterprise and carrier 96 networks, e.g. ATM, require integrated management. Note that ATM 97 nodes in carrier networks are managed using MIBs according to 98 ATM Forum specifications (M4) or ITU-T Recommendations (I.751) while 99 ATM nodes in enterprise networks are managed using e.g. the AToM MIB 100 of the IETF (RFC 1695). 102 - Virtual Private Networks (VPNs) using "public" network resources 103 require cooperation between enterprise and carrier network management. 104 VPN owners need to manage their dedicated resources in the carrier 105 network. 107 In a nutshell, the challenge that the progressing convergence of 108 networks presents is to manage several network management worlds 109 (SNMP, CMIP and existing proprietary solutions) in a consistent way 110 while preserving the vast investments in existing networks and 111 network management solutions. 113 This Internet Draft shows that while much of the needed technology 114 and the standards are already in place, some additional standardization 115 efforts will be needed to create a common framework for enterprise and 116 carrier network management. 118 1.2 Scope 120 This Internet-Draft does NOT intend to 122 - contribute to the discussion about pro's and con's of SNMP and CMIP, 123 - propose any concept to replace existing SNMP and CMIP based solutions, 124 - define a new management protocol and a new management scheme. 126 Instead, this Internet-Draft 128 - is intended to initiate work on the integration of the traditionally 129 separated network management for enterprise networks and carrier 130 networks. 131 - identifies basic requirements and introduces functional entities 132 which enhance the current management architectures, 133 - proposes areas of work to be tackled by the IETF in order to support 134 the requirements. 136 2 Existing Management Frameworks 138 Network management for carrier and enterprise networks has been 139 traditionally separated: TMN framework vs. SNMP/SMI framework. 141 2.1 The TMN Framework 143 In the 1980s, the vision was established to monitor and tune all types 144 of telecommunication network, usually without any manual intervention. 145 In 1988, the International Telecommunications Union (formerly CCITT) 146 was the first to define formally the concept of Telecommunications 147 Management Networks [7]. 149 The TMN concept relies on 3 pillars: 151 - its functional architecture (which may be mapped in various ways to 152 concrete physical configurations), 154 - its Logical Layered Architecture (LLA) and 156 - its standardized interfaces. 158 2.1.1 The TMN Functional Architecture 160 TMN according to ITU-T Rec. M.3010 identifies 3 main function blocks: 162 - Operations Systems Function (OSF) block: The OSF processes management 163 information for the purpose of monitoring/coordinating and/or 164 controlling telecommunication functions. 166 - Network Element Function (NEF) block: The NEF is a functional block 167 which communicates with the TMN for the purpose of being monitored 168 and/or controlled. The NEF is the characterizing part of the Network 169 Elements, such as switches. 171 - Q-Adapter Function (QAF) block: The QAF is used to connect non-TMN 172 entities, i.e. entities with non-TMN interfaces. It should be noted 173 that from a TMN's point of view SNMP-based Network Elements would have 174 to interact with a TMN via a QAF. 176 The TMN function blocks interact accross TMN reference points. 178 2.1.2 The TMN Logical Layered Architecture (LLA) 180 Management functions in the TMN, i.e. the TMN OSFs, have been organized 181 in 4 layers defining the so called Logical Layered Architecture (LLA) 182 of the TMN. The layers are: 184 - Element management layer (EML): 185 The EML manages each network element on an individual basis and 186 supports an abstraction of the functions provided by the NE layer. 188 - Network management layer (NML): 189 the NML has the responsibility for the management of all the NEs, as 190 presented by the EML, both individually and as a set. It is not 191 concerned with how a particular element provides services internally. 193 - Service management layer (SML): 194 Service management is concerned with, and responsible for, the 195 contractual aspects of services that are being provided to customers 196 or are being made available to potential new customers. 198 - Business management layer (BML): 199 The business management layer has responsibility for the total 200 enterprise and is the layer at which agreements between network 201 operators are made. 203 2.1.3 The TMN Interfaces 205 In order to achieve interoperability between management systems (in TMN 206 terms Operations Systems = OS) and managed systems, respectively, between 207 two management systems, TMN defines standardized interfaces (see [9]). 208 The TMN interfaces are the realization of the TMN reference points. 209 The most prominent ones are: 211 - The Q3 interface 212 is the interface between management systems and network elements of 213 one network operator (corresponding to the q3 reference point in the 214 TMN functional architecture shown in Figure 1). 215 Q3 has been the main focus of TMN standarization up to now. 217 - The X interface 218 is the interface between management systems of different network 219 operators (carrier or enterprise networks). 221 As basis for the TMN interfaces, the OSI systems management technology 222 was chosen, a set of standards developed jointly by the International 223 Standards Organization (ISO) and ITU. According to ITU-T Rec. M.3010, 224 TMN interfaces consist of a communications protocol stack, defined in 225 ITU-T Recommendations Q.811 and Q.812 [9] with the CMIP protocol on top 226 [8] and an information model specified according to ITU-T Recs. X.722 227 (Guide to the Definition of Managed Objects [10]). 229 TMN interfaces have been deployed in a number of carrier networks. 230 In enterprise networks, TMN interfaces have had virtually no influence 231 up to now. 233 2.2 The SNMP/SMI Framework 235 Management of modern enterprise networks is dominantly based on 236 Internet standards. SNMP version 1 (SNMPv1) is the original 237 Internet-standard Network Management Framework. 239 It consists of these three documents: 241 - RFC 1157 [1] defines the Simple Network Management Protocol (SNMP), 242 the protocol used for network access to managed objects. 244 - RFC 1155 [2] defines the Structure of Management Information (SMI), 245 the mechanisms used for describing and naming objects for the purpose 246 of management. 248 - RFC 1212 [3] defines a more concise description mechanism which is 249 wholly consistent with the SMI. 251 Currently, SNMP is being progressed by the IETF towards SNMP v3. 253 3. Basic Requirements for a Framework for Integrated Network Management 255 Two types of basic requirements can be identified: operational 256 requirements stating the goals, i.e. what shall be achieved by this 257 management framework, and technology requirements stating which 258 technology is best suited to achieve these goals. 260 3.1 Key Operational Requirements 262 The network management framework shall support 264 - end-to-end management. 265 This requirement addresses the need to cooperate with more than one 266 network element to perform complex management tasks at the higher 267 management layers, i.e. above element management. An example is the 268 creation of an ATM virtual circuit or a SONET path. 270 - integrated management across multiple network technologies. 271 This requirement addresses the need to jointly manage network 272 elements of different technologies. An example is coordinated 273 management of IP routers and ATM switches. 275 - cooperation between several (human) operators, management applications 276 and managed systems. 277 This requirement acknowledges the fact that management in modern 278 networks is shared among many parties. Examples include: management 279 of ATM end-to-end accross the boundaries of network operators' domains 280 or coordinated provisioning of services involving various departments 281 of a service provider's organization (e.g. customer care and switch 282 managements, billing department etc.). 284 - network user access to network management in a 'public' operator's 285 domain. This capability is generally known as Customer Network 286 Management (CNM). 287 This requirement addresses the trend that, in particular, 288 operators of enterprise networks require direct control of their 289 subscribed services and network resources in a carrier's network. 291 An example is management of a Virtual Private Network (VPN) by a 292 corporate user of the carrier network. 294 - interworking with existing and new SNMP and CMIP based management 295 systems. The framework shall allow also for interworking with 296 proprietary management systems. 297 This requirement addresses the fact that huge investments have been 298 made by enterprise and carrier network operators in their infra- 299 structures. Any management framework which proposed to replace 300 existing solutions, e.g. by introducing a new management protocol 301 between management systems and Network Elements is most probably 302 bound to fail. 304 3.2 Technology Requirements 306 The network management framework shall support 308 - a WWW-style user interface. Off-the shelf WWW-browsers shall be used 309 in the management stations. 310 This requirement addresses the fact that the user interfaces provided 311 by WWW browsers have received wide acceptance and can be seen as 312 state-of-the-art for user interfaces to server-based information 313 services. 315 - a common representation of management procedures, operations and 316 information elements of different styles and formats. 317 This requirement addresses the need to provide the operator with 318 one common view of the items he is handling. That means he should be 319 able to work at a service (= management task) level view which 320 integrates or at least hides details of network resource. 321 Another requirement is to integrate management related information 322 resources, e.g. operation manuals and training/tutorial information. 324 - flexible linking of the entities listed above by hyperlinks as used 325 in the WWW. 326 This requirement is a consequence from the need to support the variety 327 of end-to-end operational procedures, network management task steps 328 etc. A browser-based user interface is used to present the various 329 elements making up integrated network management to the operator. 331 - customization of this linked HTML structure via the network operators 332 management stations and also across a CNM interface. 333 This requirement addresses the fact that in practice network 334 management is highly network operator specific. Basic management 335 operations are combined in very specific ways to fit into the 336 respective organization of a network operator. Obviously this is also 337 true for enterprise network users. Therefore the requirement for 338 customization capabilities holds also for a CNM interface. 340 - interfaces to existing management systems (SNMP and CMIP based, and 341 proprietary). 342 This requirement is a consequence from the need to cooperate with 343 existing management systems especially at the element management 344 layer. 346 - the mapping of linked HTML structures to sets/sequences of SNMP/CMIP 347 (or proprietary) operations. 348 This requirement is a consequence from the fact that from the 349 operator's point of view network management tasks, operations and 350 information elements are represented by a WWW-like structure while 351 interaction with existing management systems has to use existing 352 protocols and data structures. 354 - linking of network originating events (traps in SNMP, event 355 notifications in CMIP) to the relevant pages in the SIB. 356 This requirement addresses the need for the network operator to get 357 knowledge of, and react to, events in the managed network. Examples 358 include major outages of network resources, overload of nodes and 359 transport systems. 361 4. Framework Architecture 363 4.1 Building Blocks 365 This section proposes three architectural enhancements to the existing 366 management frameworks which address the requirements in the previous 367 section: 369 - the use of WWW technology for representing management tasks 370 - the introduction of cooperative sessions for network management 371 - the interworking with SNMP based, CMIP based and proprietary 372 management systems. 374 The principal architectural entities which are introduced are: 376 - CSC Cooperative Session Control 377 - SIB Server Information Base 378 - GAP Gateway Application 380 Figure 1 gives an overview. For the sake of simplicity standard 381 components are not shown such as the WWW-server function and the SNMP 382 respectively CMIP protocol machines for communication with existing 383 management systems. 385 -- -- 386 | | management stations | | 387 -- (using WWW browsers) -- 388 / \ / \ 389 ---- +-----------------+ ---- 390 | | | | 391 +----------+ Inter/Intranet +----------+ 392 | | 393 -- +---+---------+---+ 394 | | | | 395 -- SIB +-----+---------+------+ \ 396 / \ customiz. | ----- ----- | | 397 ---- interface | | CSC |-----| SIB | | | 398 +--------------+ ----- ----- | | 399 +-+---------+--------+-+ > Management 400 | | | | Server 401 +-+--+ +-+--+ +-+--+ | 402 |GAP | |GAP | |GAP | | 403 +-+--+ +-+--+ +-+--+ / 404 | | | 405 +----------+ +----+-----+ +----------+ 406 |Mgmt.syst.| |Mgmt.syst.| |Mgmt.syst.| 407 |e.g. SNM | |e.g. CM | |e.g. propr| 408 +----+-----+ +----+-----+ +-----+----+ 409 | | | 410 +--+-+ +--+-+ +-+--+ Network 411 | NE | | NE | | NE | Elements 412 +----+ +----+ +----+ 413 e.g. router, bridge e.g. carrier switch e.g. transm. equipm. 415 Figure 1: Architectural Entities for WWW-based network management 417 The principal functional entities are characterized as follows: 419 - Cooperative Session Control Function (CSC) 421 The CSC controls the multi-party sessions. It handles adding and 422 removing of session participants which can be humans (e.g. operator 423 staff) and applications (e.g. in existing management systems). 424 The CSC uses information represented by so-called cooperation task 425 descriptions which are represented by linked HTML pages. 427 - Server Information Base (SIB) 429 The server information base is the repository of entities required for 430 WWW-based, cooperative, multi-technology, end-to-end management. It 431 contains the following types of entities: 433 - Managed entities representing the resources to be managed; 434 this includes also resources in the management server 436 - management task descriptions 438 - elementary management operations 440 - information entities (help texts, multimedia guidance etc.) 442 - processing entities, i.e. pieces of code representing management 443 logic relating to one or more of the entities above, 444 e.g. the mapping of a management task to a set of management 445 operations, or the mapping of an elementary operation to an SNMP 446 operation etc. 448 - event-related entities, i.e. stored event notifications 449 (spontaneously emitted in the case of CMIP, retrieved by polling 450 in the case of SNMP) 452 All these entities are represented to the operator by WWW-type pages 453 connected by hyperlinks. 455 - Gateway Applications (GAP) 457 The management server makes use of Gateway Application (GAP) to 458 cooperate with existing (and new) management systems, i.e. for 459 sending commands and receiving event information. 461 The GAPs include the conversion of management commands and event 462 messages to/from WWW representation (HTTP/HTML) and handle access 463 authorization to existing management systems. 465 GAPs can be used to adapt to management systems based on standard 466 MIBs (SNMP or CMIP) or to proprietary management systems. It should 467 be noted that this adaptation does not necessarily need to cover the 468 complete functionality of the respective element management systems. 470 4.2 External Interfaces 472 Internal interfaces, i.e. interfaces within the management server such 473 as the interface between CSC and SIB (see Fig. 1), are outside the scope 474 of this Internet Draft. 476 (1) Interface: Management Station (operator or user domain) - 477 Management Server 479 This shall be a WWW-type interface (HTTP). 481 (2) Interface: Management Server - existing/new element management 482 systems 484 The communication mechanisms for this interface are determined by 485 the corresponding management system, i.e. SNMP or CMIP 486 (or proprietary). 488 (3) Interface: SIB Customization 490 This shall be a WWW-type interface. 491 This interface allows the operator staff to customize the Server 492 Information Base. The corresponding MIB (SIB MIB) is described 493 using the SNMP framework. This SIB MIB is proposed as a subject for 494 further study. 496 4.3 Principles of the Server Information Base (SIB) 498 The SIB consists of a linked structure of WWW-type pages. 500 The operator performs management tasks by surfing this linked WWW 501 structure. He follows hyperlinks which lead to management task 502 descriptions and operation forms (corresponding to elementary 503 management operations) to be filled in. 505 Concrete management interaction with an existing EM/NM (element 506 management/network management) system is implicitly invoked by 507 clicking at the corresponding hyperlink. 509 Data and operation results received from an element management system 510 at one step of a management task can be passed to subsequent steps of 511 the management task by following predefined hyperlinks. 513 The operator can view alarm messages originating from the network by 514 selecting corresponding WWW pages. The operator can access multimedia 515 guidance information ("help", represented as WWW pages) in any phase of 516 a management task. 518 Gateway applications are responsible for interworking with the existing 519 element managers. This includes coordination of these interactions. 521 An example may illustrate these principles: 523 A member of an operator's staff accesses network management 524 functionality by entering the URL designated for end-to-end 525 management. This causes a start page to pop up. 527 Let's assume that the staff member intends to create an ATM PVC 528 (Permanent Virtual Circuit). By following the appropriate hyperlinks 529 he will finally arrive at a task description page titled 'Create an 530 ATM PVC'. 532 At this point the staff member has several options: 534 - to enter immediately the requested information for creating the 535 ATM PVC, e.g. Quality of Service (QoS) parameters, identification 536 of the respective end points in the network elements etc. 538 - to ask for further information about the task, i.e. request a 539 description of the procedure 'how to create an ATM PVC' or request 540 information about syntax and/or semantics of a specific parameter, 541 e.g. QoS. 543 - to request information about availability, current status etc. of 544 the network resources required for that task. 546 - to request another human operator or management to join the 547 management session; an example may be to query the account status 548 of the future owner of the ATM PVC being provisioned. 550 The staff member can choose between these options by selecting the 551 appropriate hyperlink. 553 He is guided through the whole management task step by step, being 554 offered only those hyperlinks which are relevant depending on the 555 status of the task. 557 After providing all the information needed to create the ATM PVC, 558 execution of the single elementary operations which make up the 559 task is triggered in the respective element management systems. 560 These element management systems perform the necessary actions on the 561 network elements in their respective domains. 563 The responses of the element managers are collected, corresponding 564 HTML pages are created and stored in the SIB. A summary response 565 page is generated and stored in the SIB. 567 Finally the staff member who has initiated the management task is 568 informed about completion of this task. 570 5. Areas for Work in the IETF 572 5.1 What is Already in Place, or Currently under Work? 574 The majority of the needed technology and standards is already in place: 576 Transport Protocols: 578 IETF: IP, TCP, UDP, HTTP 579 ISO/ITU-T: OSI layers 1-6, layer 7 association control (ACSE) 581 No additional standardization effort is necessary in this area. 583 Management Protocols/MIBs: 585 IETF: SNMP, SMI, many equipment specific MIBs 586 ISO/ITU-T: CMIP, GDMO, several application specific MIBs 588 SNMP version 3 is currently under work. 590 No additional standardization efforts in the management protocol area 591 are proposed in this Internet draft. 592 MIB efforts are proposed in section 5.2. 594 User Interfaces: 596 IETF: HTML and add-ons 598 No additional standardization efforts in the user interface area are 599 proposed in this Internet draft. 601 5.2 What Needs Still to Be Done? 603 In order to fulfill the requirements for integrated network management 604 some additions to the existing technology/standards are proposed: 606 Framework: 608 Work is proposed to determine and detail the functional entities and 609 their principal interaction needed for cooperative, WWW based network 610 management. This framework should also cover security aspects. 612 Multi-party Sessions: 614 Work is proposed to investigate usability of protocols defined by the 615 mmusic-group (Session Initiation Protocol; Session Description 616 Protocol) for network management. 618 MIBs: 620 Work is proposed for creating a SIB MIB for managing the Server 621 Information Base (SIB). This 'SIB MIB' shall be used by the network 622 operator and (parts of it) also by selected users via a CNM interface. 624 The SIB MIB shall cover managed objects representing: 626 - management tasks 628 - elementary management operations (which are mapped by GAPs to SNMP 629 or CMIP operations) 631 - information entities (e.g. help texts, multimedia guidance 632 information etc.) 634 - processing entities, i.e. software components performing a specific 635 task, such as plausibility checks etc. 637 - grouping entities of the SIB to new complex SIB entities 639 - linking entities of the SIB 641 - network originating events 643 - managed objects representing supporting entities (e.g. event logs) 645 Mapping (GAPs): 647 Work is proposed to investigate the rules for mapping between the 648 linked HTML structure of the SIB and the elementary management 649 operations determined by the cooperating management systems (SNMP, 650 CMIP). An initial proposal addressing this topic was submitted in 651 11/96 as an Internet Draft (in the meantime deleted). 653 What kind of RFCs should be created? 655 The output of this activity could be structured as follows: 657 RFC 'Requirements and Framework': 658 requirements and framework architecture of WWW-based integrated 659 network management (scope: roughly characterized by the contents of 660 sections 2 and 3 of this Internet draft). This should include also 661 security aspects of integrated network management. 663 RFC 'Mapping': 664 mapping management tasks (procedures), management elementary 665 operations, text and multimedia information to URLs (design a 666 scheme which allows to represent and address the various entities 667 which make up network management using WWW techniques). 669 RFC 'SIB MIB': 670 A 'Customizing MIB' for the support of management of the server 671 information base. This MIB shall support creating, deleting and 672 modifying management tasks and other entities of the SIB. 674 A further RFC which may be created (depending on the usability of 675 IP session protocol for cooperative network management): 677 RFC 'CSC': This RFC could cover the application and management of a 678 multi-party session control for network management. This includes a 679 'session control MIB'. 681 6. Security Considerations 683 Security considerations are not discussed in this initial draft. 685 7. Acknowledgments 687 The author is indebted for valuable comments from Reinhard Scholl 688 and Max Sevcik. 690 8. References 692 [1] J. Case, M.Fedor, M. Schoffstall and C. Davin, "The Simple 693 Network Management Protocol (SNMP)", RFC 1157, May 1990 695 [2] M. Rose, K. McCloghrie,"Structure and Identification of Management 696 Information for TCP/IP-based Internets", RFC 1155, May 1990 698 [3] M. Rose, K. McCloghrie, "Concise MIB Definitions", 699 RFC 1212, March 1991 700 [4] T. Berners-Lee, R. Fielding and H. Frystyck, "Hypertext Transfer 701 Protocol, HTTP/1.0", RFC 1945, May 1996, 703 [5] T. Berners-Lee, D. Connolly: "Hypertext Markup Language 2.0", 704 RFC 1866, November 1995. 706 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 707 Locators (URL)", RFC 1738, December 1994. 709 [7] ITU-T: Recommendation M.3010 "Principles for a Telecommunications 710 Management Network", 712 [8] ISO/IEC, ITU-T, Information Technology - OSI, Common Management 713 Information Protocol (CMIP) - 714 Part 1: Specification ISO/IEC 9596-1, ITU-T 715 Recommendation X.711 717 [9] ITU-T, Lower Layer Protocol Profiles for the Q3 Interface, 718 Recommendation Q.811 719 Higher Layer Protocol Profiles for the Q3 Interface, 720 Recommendation Q.812 722 [10] ISO/IEC, ITU-T, Information Technology - OSI, Guidelines for the 723 Definition of Managed Objects, Recommendation X.722 725 [11] ITU-T, Asynchronous Transfer Mode (ATM) Management of the 726 Network Element View, Recommendation I.751 728 [12] ATM Forum, M4 Interface Requirements and Logical MIB: 729 ATM Network Element View, af-nm-0020.000, October 1994 730 ATR Forum, CMIP Specification for the M4 Interface, 731 af-nm-0027.001, September 1995 733 [13] M. Ahmed, K. Tesink, IETF, "Definition of Managed Objects for ATM 734 Management version 8.0 using SMIv2, RFC 1695 736 9. Author's Address 738 Gerhard Bogler 740 Siemens AG, 741 Hofmannstrasse 51, 742 D-81359 Munich, Germany 743 tel.: +49-89-722 27685, 744 fax: +49-89-722 23528, 745 gerhard.bogler@oen.siemens.de