| DIGITAL INTEROFFICE MEMORANDUM
To: DECmcc Interest, Date: 22-October-1992
NSM Staff From: Gail C. Ferreira
cc: UltrixInterest DEPT: EMF/EMA Framework
VMSInterest Strategy Manager
EMA-Interest EXT: 226-5320
NAS_Partners LOC: LKG2-2
Network_Partners ENET: DELNI::FERREIRA
Subject: Framework Strategy and DECmcc V1.3 Phase 0/1 Close
& V.Next Phase 0 Open & DME-Intercept Phase 0 Open
1 Enterprise Management Framework Strategy
The Domain, Roadmap and Budget exercises, in which we've been in-
volved as part of TNSG, have now crystallized the management frame-
work strategy and budget. Today Digital ships 2 products that could
be termed directors: DECmcc which is an implementation of the EMA
Director and MSU (Management Station for ULTRIX). Each of these
products also include a suite of network management applications.
The framework portion of both of these products is the infras-
tructure to enable all types of management applications to in-
tegrate with each other via a common User Interface, shared events
or data, or use of director-specific calls in management appli-
cations, and to allow management of all resource/objects.
In DECmcc terms, the framework includes the current generic DECmcc
modules such as the kernel, domains, registration, alarms, no-
tification, data collector, historian and exporter, as well as
the generic access modules. Also, as a pricing/packaging tactic,
most access modules will be included in the framework or POLY-
CENTER Director free of charge.
We are now proceeding to implement a Management Framework which
will include:
1. Shipping the POLYCENTER Common Agent pervasively (many units
on many platforms),
2. A transition/evolution of the DECmcc Director, with backward
compatibility, to be renamed the POLYCENTER Director as it be-
comes OSF/DME-compliant, and
3. Separately, launching DME intercept efforts to focus on our
convergence with DME, including a DME-compliant Framework and
User Interface. It is anticipated that these DME activities will
be delivered as part of the POLYCENTER Director, and will re-
place the existing framework portions of DECmcc and MSU, al-
lowing the network management applications of each to layer
on these DME intercept efforts.
The POLYCENTER Director and Common Agent are enabling technolo-
gies onto which value-added applications will be layered. One ex-
ample of these are Network Management applications, including the
network-specific functions that were historically part of DECmcc
product. An increasing number of applications are layered on DECmcc,
which provides both a graphical User Interface and coordinated
access/manipulation of application-specific attributes.
It is anticipated that the POLYCENTER Director framework will be-
come a leadership framework or enabling management infrastruc-
ture, from which to launch all POLYCENTER applications, and into
which we further integrate and layer our evolving management ap-
plications, over time. Application areas of particular focus for
NAS Systems Management (NSM) include:
o Storage Management - ex. Media Manager (MLM/MRM)
o Network Management - ex. Voice (TeMIP) and Data (DECmcc/POLYCEN-
TER Network Manager)
o Configuration Management -- ex. POLYCENTER System Census
2 Framework Goal: Pervasiveness
The primary goal of the framework is to be pervasive. To accom-
plish this, the framework must:
o Deliver high performance (a streamlined-product)
o Be Easy to use/develop to
o Offer phased integration support for applications
o Provide timely and predictable releases
o Have open and pervasive market presence (available on lots of
platforms, shipping lots of units and with lots of applica-
tions using it)
To achieve this goal of pervasiveness, the framework MUST pro-
vide clear added value for developers of management applications.
As customers/end-users users buy these applications, the frame-
work will become pervasive. The EMF (Enterprise Management Frame-
work) organization understands that to accomplish NSM's goals,
the framework organization must be open and easy to do business
with. We hope to gain your support and demonstrate that we can
be flexible to incorporate your needs and be preditable in our
deliverables.
3 Director Progress to Date
The following highlights the DECmcc successes to date, in FY89-
92 sales:
o DECmcc has sold more than 1,000 units on VMS and ULTRIX plat-
forms ! This excludes sales on System V, [and future Sun and
DOS sales] and is only through FY92. Revenue exceeds $17.5M
in just 2 full years of sales.
o For comparison to HP's OpenView umbrella of products, all of
Digital's Network Management products total more than 5,500
units on just VMS and ULTRIX through FY92, resulting in $40M
in revenue. [HP had 1200 UNIX licenses through DEC 1992 (with
3 times more than that on DOS).]
o For our full POLYCENTER portfolio, the data is incomplete, but
POLYCENTER products within NSM have sold over 1/3 of a mil-
lion units with revenue far in access of $200M.
4 Director Plans: Phase Open and Close
The following sections outline our plans to move forward and achieve
the strategic goals outlined above.
4.1 DECmcc V1.3: Now Entering Phase 2
With the completion of DECmcc V1.2, it became obvious that the
Framework must become predictable, with timely releases approx-
imately every six months. The objective of V1.3 is to deliver a
limited maintenance release to ship within six months to address
the most pressing needs, while simultaneously starting the larger
V.Next release. The content of DECmcc V1.3 was defined in part-
nership with these customers:
o NAS Network Management, shipping applications based on the DECmcc
Director
o Telco Business Group, shipping TeMIP layered on DECmcc for PTTs,
etc.
o Existing DECmcc Strategic Vendors, including BBN, Olivetti,
Alcatel
The following DECmcc V1.3 enhancements seem to address the most
requested and highest priority needs of these and most DECmcc cus-
tomers/end users:
o Ease of use features
o Ease of development (Steps of Integration)
o Performance enhancements
o Enhanced SNMP support
These requirements were also confirmed by the Network Partners
as the most critical needs. Dates for DECmcc V1.3 are as follows:
______________________________________________________________
Milestone___________________________________Schedule__________
Requirement Collection (Req & Planing) June/July 92
Phase 0 & 1 Exit (Req & Planing) 19-OCT-92
Phase 2 Exit - Start FT (Implement 23-NOV-92
/System Test)
SSB Submission 25-JAN-93
FRS_Shipping________________________________FEB-93___________
Specs are available as follows from TOOK::USER$43:[CARR.PUBLIC]
V13_FUNCTIONAL_SPEC.TXT;1
LAUNCH.PS;2
IMPM_FUNC_SPEC.TXT;1
DECMCC_V13.DEV_PLAN;10
CMIP.DEV_PLAN;1
DAP_DICT.DEV_PLAN;1
DATA_COLLECTOR.DEV_PLAN;1
DATA_SERV.DEV_PLAN;1
IMPM.DEV_PLAN;1
LAUNCH_DEV_PLAN.PS;3
SCRIPT_AM.DEV_PLAN;1
DOC_PLAN_AUG_21.PS;2
TRAINING_PLAN.PS;2
This memo serves to officially close V1.3 Phases 0 and 1, and en-
ter Phase 2.
4.2 POLYCENTER Director V.Next: Phase 0 now open
Where V1.3 is limited in focus and scope, the Framework group is
now focusing on V.Next (no number determined yet), which should
more fully address the many currently outstanding needs of ap-
plication developers that would find it advantageous to layer on
a framework.
This will be the first framework-specific release that will fo-
cus exclusively on the underpinnings, for other products that bun-
dle or [optionally] require the framework as part of their ap-
plication. We are now opening Phase 0 to collect Framework re-
quirements. Users of this framework are management application
developers, and those are the requirements I specifically want
to collect. Network Management Appliations projects will solicit
requirements separately, but any requirements I receive will be
passed on to them. It is anticipated that this framework version
will ship in the Fall of 1993, and depending upon needs, resources,
and other constraints could include:
o XMP API (DME migration)
o Distribution
o Performance enhancements
o Ease of use features
o Enhanced security capabilities, ex. TeMIP roles
o Internationalization
4.3 DME Intercept: Open Phase 0
The OSF/DME integration work has begun to dramatically change the
overlapping selected technologies, and the OSF/DME team is ex-
pected to publish specifications soon. As the full DME project
plan becomes available from OSF next month, we'll be able to start
the planning of our DME-compliant director which will serve as
the underlying infrastructure to both DECMcc and MSU applications,
and many new applications.
Digital has committed to shipping the OSF DME within 6 months of
availability from the OSF, which would mean shipping our prod-
uct by 6/94 based on current OSF targets. However, it is likely
that this DME implementation will be staged over several releases,
and be completed by this timeframe. I'd be very interested in know-
ing your interest and need for DME, and which specific components
(ex. XMP API vs. OMG API) should be implemented earlier rather
than latter.
Remember that neither DME specs or compliance tests have been de-
fined yet, so this schedule will likely put us ahead of the com-
petition in implementing DME since the transition to DME from DECmcc,
for example, is easier that than Openview to full DME.
5 POLYCENTER Common Agent V1.0 currently in Phase 2/Field Test
The POLYCENTER Common Agent for ULTRIX will be product-announced
and demonstrated at the Interop show at the end of October, and
will ship in January 1993. The OpenVMS implementation of Common
Agent will be announced at Fall DECUS in December for shipment
in early 1993. Both the Common Agent for ULTRIX and for OpenVMS
are now in external field test and will close Phase 2 in Novem-
ber. The schedule for the OSF/1 Alpha AXT port of the Common Agent
will also be published in November.
The public directory for Common Agent information is located at:
FILES::EMA$:[PUBLIC.COMMON_AGENT]
Further status and information on the Common Agent will be com-
municated next month in a separate memo. Any immediate questions
are also welcome.
6 Your Input Is Appreciated
To faciliate collection of requirements, a notes file titled EMF_
REQ will be opened on node NOTED. The notes file will be organized
by functional areas to categorize the requirements.
Your experiences and needs for these products are welcome, ei-
ther via NOTES, or via mail to me, which unless you request oth-
erwise, I'll place in the NOTES file to help me organize the re-
quirements.
Additionally, the EMF Business Forum will be inviting internal
groups to present and discuss their requirements from a business
/market-driven perspective.
7 Further Information/PID
Further information of Framework directions, DME status and Dig-
ital's DME strategy, and specifics on the releases outlined above
is available. A postscript file of the "Framework Directions" pre-
sentation is available to you as:
TOOK::USER$219:[BEAUDET.PUBLIC]FRAMEWORK_DIRECTIONS.PS
The main sections of this presentation can be used without a non-
disclosure. It is segmented into modular sections, which can each
be used, reduced or not used depending of the needs/desire of the
audience.
The detailed sections in the back can be added to the appropri-
ate front sections for a detailed non-disclosure presentation.
These rear pages are marked Digital Confidential, and there is
the mandatory PID page preceeding them. Please use this material
appropriately.
This presentation covers only the Frameworks LOB and does not in-
clude the strategies of other NSM Lines of Business such as Dig-
ital's Network Management Strategy. Please contact the NSM Net-
work Management Applications group, managed by Dick Andersen, with
Deb Curtis as the Strategy Manager for more information about Net-
work Management applications.
|
| To: Distribution; including DECMCC, ULTRIX, and VMS interest lists
From: Bill Gassman
Network Management Product Marketing Manager
Subject: Phase 0 Now Open - Network Management Applications next version
Please review this Phase 0 document, and submit your comments to Bill
Gassman (SKIBUM::GASSMAN) or reply in ENUF::NETMGT Note 357 by December 1.
The version of DECmcc currently in development is V1.3. This is a combined
project of the Enterprise Management Framework (EMF) and Network Management
Applications (NMA) engineering groups. All the apporpriate DECmcc V1.3
products (Director, BMS, EMS) on both operating systems (ULTRIX and VMS) are
currently scheduled to go to SSB at the end of January. For information on
the V1.3 project and features, please refer to the specifications and
projects plans available from TOOK::USER$43:[CARR.PUBLIC].
Shortly following the release of DECmcc V1.3, the Network Management
Applications group will be releasing new and enhanced applications that
could not be included in the V1.3 schedule. It is anticipated that this
network management applications version will go to SSB in the spring of
1993, 3 to 4 months after DECmcc V1.3.
This will be the first Network Management Applications-specific release and
will be built on the POLYCENTER Framework (DECmcc Director) V1.3. Some
elements of the project will be included in the BMS or EMS packages, some
elements may be available as optional, add-on modules.
This is a short release cycle and the following are the high priority
market and customer requirements for this project. Many of these
requirements were collected in previous development cycles, but have not
yet been included in any engineering project. Some place requirements on
the Enterprise Management Framework engineering group and will be passed on
to that group.
If you have additional requirements for this project, please submit them to
Bill Gassman (SKIBUM::GASSMAN) or post them as a reply to note 357 in the
ENUF::NETMGT notes file.
---> *** Input will be accepted through Dec. 1, 1992. *** <------
Please note that this list of requirements is not a commitment to implement
all of them in this short release cycle. We need your input and prioritization
during this Phase 0. We will implement as many as possible based on needs,
resources, and other constraints. Projects will be focused on the priority
areas that have been approved for FY93 engineering investment through the
NSM Domain process. These include Network Configuration Management
(auto-configuration, auto-topology, auto-discovery, SNMP, DECnet, LAN),
Network Fault Management (object reachability/availability, default policy
implementation), and Network Performance Management (traffic monitor,
performance analyzer).
*** Company Confidential ***
Major requirements "themes" for next version in top down priority
-----------------------------------------------------------------
1. Incremental Auto-discovery/Entity Reachability
Incremental auto-discovery and auto-topology capabilities have been
available in competing products for a while and have been submitted as
DECmcc requirements for more than two years. This version must deliver
more than a minimal implementation. When released, this capability will
be compared to competing products in specific categories such as accuracy,
ease-of-use, and speed from the time a device is attached to the net
to the time it appears on the map.
Incremental auto-discovery requires that the network management system
recognize that something new has been added to the network, notify the
network manager of the new item, and automatically register and add the
new item to the map. It should recognize when new TCP/IP things, new
DECnet things, and new Ethernet things are added to the network. Bridge
FDDI, and Terminal server are secondary priorities. Project will
investigate the DECmcc MSU approach and Network Systems Laboratory work.
(Map requirements yield a dependency on EMF.)
Included in this general theme is the requirement for the reachability
pollers that "discover" the incremental configuration information. The
V1.3 product already includes a reachability poller for TCP/IP. This
project must extend the reachability pollers to additional protocols and
technologies (specifically DECnet Phase IV, Ethernet IEEE 802.3 and DEChub).
To be competitive, this auto-discovery capability should be able to
identify discovered entities by device and by vendor. For instance,
when an entity is discovered, the management system should be able to
identify it as an Ethernet Bridge, and more specifically a Vitalink
Bridge. Investigate the use of the new MIB MACRO feature to go even
further and identify the model.
To be smart, this capability should use topology information that can be
found in bridges and routers to discover which devices are on which LAN
segment and build an accurate map.
This auto-discovery theme will go a long way to replacing the current
ETHERnim product in the high-end DECmcc EMS package.
2. Traffic Monitoring/Utilization
This theme provides standard and multivendor traffic monitoring. The
goal is to use the information gathered by popular "probes" or "pods"
and correlate, integrate, and present the information to the network
manager. Probes considered for support include: Technically Elite
Concepts (TEC) Network Professor, HP LANprobe, Concord TRAKKER, NAT,
Frontier and, of course, Digital's own LAN Bridge currently used by the
LTM product. The focus will be on presenting and adding value to
standard RMON MIB information.
Associated with this theme is the requirement for higher quality
real-time graphics support including the ability to print, scroll, scale
and lock the graph. Higher quality reporting is also required including
the ability to capture the performance information, include it in files,
spreadsheets and reports. (Graphics support yields a dependency on EMF.)
This project does not include any "what-if" or capacity planning goals, but
does lay the groundwork to deliver those capabilities in future versions.
*** Company Confidential ***
This traffic monitoring theme will go a long way to replacing the
current LTM product in the high-end DECmcc EMS package, providing this
capability on both VMS and ULTRIX.
3. Remedy Health Profiler
For those of you not familiar with the new Health Profiler product from
Remedy, it provides consistent views or "dashboards" to monitor and
control network entities. These dashboards will likely be the de-facto
industry standard look and feel. They will be out on SunNet Manager
early in 1993, on HP Openview in the early spring, and we must have them
supported on our product or risk being tagged "proprietary". Many
vendors of network equipment will be supplying a Remedy dashboard
definition with their product.
4. MCC/MSU transparency and integration
The current MCC and MSU products are on a timeline to have their
underlying frameworks be replaced by the new DME-compliant framework.
When we reach that goal, both products will still exist (investment
protection) and will simply be packaging alternatives based on a common
framework. This is similar to the current BMS and EMS products which
are just packaging alternatives based on the current Director framework.
In the meantime, there are some steps on the way to reaching that goal.
We have already supplied a common applications launch mechanism for MCC
and MSU. For 3rd party vendors who loosely integrate their network
management application with our platforms by "launching", this common
launch mechanism makes it transparent to them which DEC platform they
will be working with.
Additional steps on the way, and requirements for this project are the
support and publication of a common SNMP stack (library), including a
solution for trap sharing for both MCC and MSU. Also, the the ability
to share data between the products. Data sharing must at least support
MSU acting as an "element manager" and sending alert and status information
up to MCC acting as an "enterprise manager". At best, the data sharing
would use the SNMP V2 manager to manager communications.
5. Ease of use
"Out-of-the-box" default setup
- pre-defined alarm rules and reports for common network elements such as
TCP/IP hosts, DECnet nodes, circuits, bridges, routers, terminal servers.
- default installation procedure makes DECnet Phase V support optional.
- default thresholds for performance utilization graphs.
Enhanced alarms manager, beyond that provided in V1.3, to make it easier
for the user to create and apply rules, import and export rules, and
share rules with other users. An object-oriented approach to alarming
would be a bonus. For example, be able to select a specific trap coming
in, and quickly build an alarm based on that trap.
Historian/exporter manager to make it easier to set up, modify and
manage historian/exporter functions.
*** Company Confidential ***
6. SNMP Support
Published SNMP stack (library) as noted above under MCC/MSU.
SNMP trap distribution, and forwarding. This allows the manager to
receive traps, share them with 'launched' applications, and forward
them to other managers.
Enhancements to provide at least limited support for SNMP V2. We showed
our commitment to this at Interop and need to follow through. This
would demonstrate some leadership rather than the "catch-up" items.
SNMP needs an "all partitions" partition that lets users get SNMP data in
a way they are used to, rather than hunting through the partitions to find
what they are looking for.
The MIB browser needs to be enhanced into an editor, so users can easily
change data types of MIB attributes, or quickly add one new MIB element.
7. PC LAN Support
Support of Novell and Apple through the support of SNMP over Novell's
IPX and Apple's DDS including reports and alarms for each.
8. Extensible Performance Analyzer
The current PA product has a limited set of performance statistic
calculations hard coded in. This requirement is for an extensible PA
that allows the user to define and customize their own performance
statistic calculations. Also, if not too hard, add a standard deviation
statistic (calculate norm, and 3 delta values). This would allow alarms
to be written on values outside the 3-delta range.
9. GNMP Compliance
GOSIP and GNMP requirements start in earnest at the beginning of the
calendar year. GNMP compliance also results in IS CMIP support. (The
current CMIP in the DECnet/OSI Access Module is the early Digital
intercept of the standard.) The GNMP option should be packaged separate
from BMS/EMS, and charged appropriately. GNMP specifications are very
extensive, so a minimum acceptable solution would be first pass.
If you submit additional requirements, please include your prioritization of
the importance (most important = 1, least important = 10) of each item on
the above list with your new input included in the list. We know that each
and every one of these items is critical to the success of the network
management program, so "least important" is a relative term. In this
context, it means least important to this current, short-term product
development cycle.
Along with your requirement, please provide a brief description of the
customer environment that led to this requirement. In some cases, there
are multiple potential solutions to answer the customer need. Rather than
just taking your proposed solution in the form of the requirement, we'd
like to get an idea of the source customer environment so alternative
solutions can be considered.
Your Input Is Appreciated
Please submit requirements by Dec. 1, 1992.
*** Company Confidential ***
Distribution:
to: Andy Putnins (Network Partners - NM SIG)
Dennis McCloud (Network Partners - NM SIG)
Chip Schooler (POLYCENTER FMS - Net.Mgmt - US)
Marc Malaise (Net.Mgmt.Mktg. - Europe)
DECmcc Interest
cc: Deb Curtis
Bill Keyworth
Dick Andersen
Gail Ferreira
Andy Bray
ULTRIX Interest
VMS Interest
Network Partners
|