One document matched: draft-ersue-opsawg-management-fw-02.txt
Differences from draft-ersue-opsawg-management-fw-01.txt
Network Working Group M. Ersue
Internet-Draft Nokia Siemens Networks
Intended status: Informational November 27, 2010
Expires: May 31, 2011
An Overview of the IETF Network Management Framework and its Standards
draft-ersue-opsawg-management-fw-02
Abstract
This document gives an overview of the IETF standard management
framework and summarizes existing and ongoing development of IETF
standards-track network management protocols and data models. The
purpose of this document is on the one hand to help system developers
and users to select appropriate standard management protocols and
data models to address relevant management needs. On the other hand
the document can be used as an overview and guideline by other SDOs
or bodies planning to use IETF management technologies and data
models.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 31, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
Ersue Expires May 31, 2011 [Page 1]
Internet-Draft IETF Management Framework November 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. IETF Standard Management Framework . . . . . . . . . . . . . . 6
2.1. Simple Network Management Protocol (SNMP) and its
Architectural Principles . . . . . . . . . . . . . . . . . 6
2.2. SNMP and its Versions . . . . . . . . . . . . . . . . . . 7
2.3. SNMP Security and Access Control Models . . . . . . . . . 9
2.3.1. Security Requirements on the SNMP Management
Framework . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. User-Based Security Model (USM) . . . . . . . . . . . 10
2.3.3. View-Based Access Control Model (VACM) . . . . . . . . 11
2.3.4. SNMP Transport Subsystem and Transport Security
Model . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5. RADIUS Authentication and Authorization with SNMP
Transport Models . . . . . . . . . . . . . . . . . . . 13
2.4. Supplementary Components of the IETF Management
Framework . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. NETCONF and its Modeling Language YANG . . . . . . . . 14
2.4.2. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3. IPFIX/PSAMP . . . . . . . . . . . . . . . . . . . . . 18
3. Management Protocols and Mechanisms with specific Focus . . . 20
3.1. IP Address Management with DHCP . . . . . . . . . . . . . 20
3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . . 21
3.3. SNMP Agent Extensibility (AgentX) Protocol . . . . . . . . 22
3.4. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6. CAPWAP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7. Access Node Control Protocol . . . . . . . . . . . . . . . 26
3.8. Ad-Hoc Network Autoconfiguration . . . . . . . . . . . . . 27
3.9. Policy-based Management . . . . . . . . . . . . . . . . . 27
3.9.1. IETF Policy Framework . . . . . . . . . . . . . . . . 27
3.9.2. COPS-PR . . . . . . . . . . . . . . . . . . . . . . . 27
3.10. Network Performance Management . . . . . . . . . . . . . . 28
3.10.1. IP Performance Metrics (IPPM) . . . . . . . . . . . . 28
3.10.2. Real-time Flow Measurement (RTFM) . . . . . . . . . . 30
3.11. Application Layer Management Protocols . . . . . . . . . . 30
3.11.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11.2. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11.3. EPP . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. Proposed, Draft and Standard Level Data Models . . . . . . . . 31
4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 31
Ersue Expires May 31, 2011 [Page 2]
Internet-Draft IETF Management Framework November 2010
4.2. Configuration Management . . . . . . . . . . . . . . . . . 33
4.3. Accounting Management . . . . . . . . . . . . . . . . . . 34
4.4. Performance Management . . . . . . . . . . . . . . . . . . 34
4.5. Security Management . . . . . . . . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
9. Informative References . . . . . . . . . . . . . . . . . . . . 37
Appendix A. New Work related to IETF Management Framework . . . . 49
A.1. Energy Management (eman) . . . . . . . . . . . . . . . . . 49
Appendix B. Open issues . . . . . . . . . . . . . . . . . . . . . 51
Ersue Expires May 31, 2011 [Page 3]
Internet-Draft IETF Management Framework November 2010
1. Introduction
This document gives an overview of the IETF standard management
framework and summarizes existing and ongoing development of IETF
standards-track network management protocols and data models. The
purpose of this document is on the one hand to help system developers
and users to select appropriate standard management protocols and
data models to address relevant management needs. On the other hand
the document can be used as an overview and guideline by other SDOs
or bodies planning to use IETF management technologies and data
models. The document can be also used to initiate a discussion
between the bodies with the goal to detect possible gaps and to
gather new requirements.
[I-D.baker-ietf-core] identifies the key protocols of the Internet
Protocol Suite for use in the Smart Grid. The target audience is
those people seeking guidance on how to construct an appropriate
Internet Protocol Suite profile for the Smart Grid. In analogy to
[I-D.baker-ietf-core] this document gives an overview on the IETF
management framework and standards and its usage scenarios.
The Overview of the 2002 IAB Network Management Workshop [RFC3535]
documented strengths and weaknesses of some IETF management
protocols. In choosing existing protocol solutions to meet the
management requirements, it is recommended that these strengths and
weaknesses be considered. Some of the recommendations from the 2002
IAB workshop have become outdated, some have been standardized, and
some are being worked on at the IETF.
Guidelines for Considering Operations and Management of New Protocols
and Extensions [RFC5706] recommends working groups to consider
operations and management needs, and then select appropriate
management protocols and data models. This document can be used to
ease surveying the IETF standards-track network management protocols
and management data models.
Section 2 gives an overview of the IETF standard management framework
with a special focus on Simple Network Management Protocol (SNMP) and
supplementary components of the IETF management framework such as
NETCONF, SYSLOG and IPFIX. Section 3 discusses IETF management
protocols and mechanisms with a specific focus and their use cases.
Section 4 discusses Proposed, Draft and Standard Level data models,
such as MIBs designed to address specific set of issues and maps them
to different management tasks.
IETF specifications must have "multiple, independent, and
interoperable implementations" before they can be advanced to Draft
Standard status. An Internet or Full Standard (also referred as
Ersue Expires May 31, 2011 [Page 4]
Internet-Draft IETF Management Framework November 2010
Standard), is characterized by a high degree of technical maturity
and by a generally held belief that the specified protocol or service
provides significant benefit to the Internet community [RFC2026].
This document mainly refers to Proposed, Draft or Full Standard
documents at IETF (see [RFCSEARCH]). As far as it is valuable Best
Current Practice (BCP) documents are referenced. In exceptional
cases and if the document provides substantial guideline for standard
usage or fills an essential gap Informational RFCs are noticed and
ongoing work is mentioned.
Note: This document uses the expired draft [I-D.ietf-opsawg-survey-
management] as a starting point and enhances it with a special focus
on the description of the IETF Standard Management Framework and SNMP
security as well as aims to extend it with explanation of the
standards and their usage scenarios.
Note: The document does not cover OAM technologies on the data-path,
e.g. OAM of tunnels, MPLS-TP OAM, Pseudowire, etc. [I-D.ietf-
opsawg-oam-overview] gives an overview on the OAM toolset for
detecting and reporting connection failures or measurement of
connection performance parameters. [I-D.ietf-mpls-tp-oam-framework]
describes the OAM Framework for MPLS-based Transport Networks.
1.1. Terminology
This document does not describe standard requirements. Therefore key
words from RFC2119 are not used in the document.
o Agent: A software module that performs the network management
functions requested by network management stations. An agent
module may be implemented in any network element that is to be
managed, such as a host, bridge, or router. The 'management
server' in NETCONF terminology.
o CLI: Command Line Interface. A management interface that human
administrators use to interact with networking equipment.
o Data model: A mapping of the contents of an information model into
a form that is specific to a particular type of data store or
repository (see [RFC3444]).
o Event: An occurrence of something in the "real world". Events can
be indicated to managers through an event message or notification.
o FCAPS: Fault, Configuration, Accounting, Performance, Security.
The five categories of management functionality defined by TMN.
Ersue Expires May 31, 2011 [Page 5]
Internet-Draft IETF Management Framework November 2010
o Information model: An abstraction and representation of entities
in a managed environment, their properties, attributes and
operations, and the way they relate to each other. Independent of
any specific repository, protocol, or platform (see [RFC3444]).
o Managed object: A management abstraction of a resource; a piece of
management information in a MIB. In the context of SNMP, a
structured set of data variables that represent some resource to
be managed or other aspect of a managed device.
o Manager: An entity that acts in a manager role, either a user or
an application. The counterpart to an agent. A 'management
client' in NETCONF terminology.
o Management Information Base (MIB): The definition of a related
collection of objects that represent a collection of resources to
be managed.
o MIB module: A MIB definition, typically for a particular network
technology feature, that constitutes a subtree in an object
identifier tree. A MIB that is provided by a management agent is
typically composed of multiple instantiated MIB modules.
o Notification: An event message.
o Trap: An unsolicited message sent by an agent to a management
station to notify an unusual event.
2. IETF Standard Management Framework
2.1. Simple Network Management Protocol (SNMP) and its Architectural
Principles
As described in [RFC3410] the current version of the Internet
Standard Management Framework, the SNMPv3 Framework, builds upon both
the original SNMPv1 and SNMPv2 Management Framework. The basic
structure and components for the Internet Standard Management
Framework did not change between its versions and comprises following
components:
o managed nodes, each with an SNMP entity providing remote access to
management instrumentation (the agent),
o at least one SNMP entity with management applications (the
manager), and
o a management protocol used to convey management information
between the SNMP entities, and management information.
Ersue Expires May 31, 2011 [Page 6]
Internet-Draft IETF Management Framework November 2010
During its evolution, the fundamental architecture of the Internet
Standard Management Framework remained consistent based on a modular
architecture, which consists of:
o a generic protocol definition independent of the data it is
carrying, and
o a protocol-independent data definition language,
o a virtual database containing data sets of management information
definitions (the Management Information Base, or MIB), and
o security and administration.
As such following standards build up the basis of the current IETF
Standard Management Framework:
o SNMPv3 protocol,
o the modeling language SMIv2, and
o MIBs for different management issues.
The SNMPv3 Framework extends the architectural principles of SNMPv1
and SNMPv2 by:
o building on these three basic architectural components, in some
cases incorporating them from the SNMPv2 Framework by reference,
and
o by using the same layering principles in the definition of new
capabilities in the security and administration portion of the
architecture.
2.2. SNMP and its Versions
SNMP is based on three conceptual entities: Manager, Agent, and the
Management Information Base (MIB). In any configuration, at least
one manager node runs SNMP management software. Typically, network
devices such as bridges, routers, and servers are equipped with an
agent. The agent is responsible for providing access to a local MIB
of objects that reflects the resources and activity at its node.
Following the manager-agent paradigm, an agent can generate
notifications and send them as unsolicited messages to the management
application.
To enhance this basic functionality, a new version of SNMP has been
introduced in 1993. SNMPv2 added a Trap PDU, an Inform message, a
Ersue Expires May 31, 2011 [Page 7]
Internet-Draft IETF Management Framework November 2010
bulk transfer capability and other functional extensions like an
administrative model for access control, security extensions, and
Manager-to-Manager communication. SNMPv2 entities can have a dual
role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers
sufficient security features. To address the security deficiencies
of SNMPv1/v2, SNMPv3 was issued as a set of Proposed Standards in
January 1998 (see [STD62]).
[BCP74] "Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework" gives an overview
of the relevant standard documents on the three SNMP versions. The
BCP document furthermore describes how to convert MIB modules from
SMIv1 format to SMIv2 format and how to translate notification
parameters as well as describes the mapping between the message
processing and security models (see [RFC3584]).
SNMP utilizes the Management Information Base, a virtual information
store of modules of managed objects. Generally, standard MIB modules
support common functionality in a device. Based on this fact
operators often define additional MIB modules for their enterprise or
use other protocols such as a Command Line Interface (CLI) to
configure non standard data in managed devices and their interfaces.
SNMP traps and informs can alert an operator or an application when
some aspect of a protocol fails or encounters an error condition, and
the contents of a notification can be used to guide subsequent SNMP
polling to gather additional information about an event.
SNMP is widely used for monitoring fault and performance data and
with its stateless nature SNMP also works well for status polling and
determining the operational state of specific functionality. The
widespread use of counters in standard MIB modules permits the
interoperable comparison of statistics across devices from different
vendors. Counters have been especially useful in monitoring bytes
and packets going in and out over various protocol interfaces. SNMP
is often used to poll a device for sysUpTime, which serves to report
the time since the last reinitialization of the device, to check for
operational liveliness, and to detect discontinuities in some
counters.
Some operators (e.g. for DOCSIS based systems such as cable modems)
use SNMP for configuration in their environment, while others find
SNMP has a limited configuration management support. As a comparison
SNMP supports a data-centric view where some operators use CLI with
its task-oriented view or NETCONF with a document-based view. SNMP
does not separate clearly between configuration data and operational
state. SMIv2 has limited support for structured data types and
relationships among managed objects.
Ersue Expires May 31, 2011 [Page 8]
Internet-Draft IETF Management Framework November 2010
SNMPv1 [RFC1157] is a Full Standard that the IETF has declared
Historic and it is not recommended due to its lack of security
features. SNMPv2c [RFC1901] is only an Experimental RFC that the
IETF has declared Historic and it is not recommended due to its lack
of security features.
SNMPv3 [STD62] is a Full Standard that is recommended due to its
security features, including support for authentication, encryption,
message timeliness and integrity checking, and fine-grained data
access controls. An overview of the SNMPv3 document set is in
[RFC3410].
Standards exist to use SNMP over diverse transport and link layer
protocols, including TCP, UDP, Ethernet, OSI, and others (see section
2.3.4).
2.3. SNMP Security and Access Control Models
2.3.1. Security Requirements on the SNMP Management Framework
Several of the classical threats to network protocols are applicable
to management problem space and therefore applicable to any security
model used in an SNMP Management Framework. This section lists
principal threats, secondary threats, and threats which are of lesser
importance as defined in [RFC3411].
The principal threats against which SNMP Security Models can provide
protection are:
Modification of Information:
Information might be altered by an unauthorized entity, e.g. in-
transit SNMP messages can be generated to effect unauthorized
management operations, including falsifying the value of an
object.
Masquerade:
The masquerade threat is the danger that management operations not
authorized for some principal may be attempted by assuming the
identity of another principal that has the appropriate
authorizations.
Secondary threats against which any Security Model used within this
architecture can provide protection are:
Message Stream Modification:
The SNMP protocol is typically based upon a connectionless
transport service which may operate over any subnetwork service.
The re-ordering, delay or replay of messages can and does occur
Ersue Expires May 31, 2011 [Page 9]
Internet-Draft IETF Management Framework November 2010
through the natural operation of many such subnetwork services.
The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent
which is greater than what can occur through the natural operation
of a subnetwork service, in order to effect unauthorized
management operations.
Disclosure:
The disclosure threat is the danger of eavesdropping on the
exchanges between SNMP engines. Protecting against this threat
may be required as a matter of local policy.
There are at least two threats against which a Security Model within
this architecture need not protect, since they are deemed to be of
lesser importance in this context:
Denial of Service:
A Security Model need not attempt to address the broad range of
attacks by which service on behalf of authorized users is denied.
Indeed, such denial-of-service attacks are in many cases
indistinguishable from the type of network failures with which any
viable management protocol must cope as a matter of course.
Traffic Analysis:
A Security Model need not attempt to address traffic analysis
attacks. Many traffic patterns are predictable - entities may be
managed on a regular basis by a relatively small number of
management stations - and therefore there is no significant
advantage afforded by protecting against traffic analysis.
2.3.2. User-Based Security Model (USM)
The User Security Model (USM) provides authentication and privacy
services for SNMP (RFC3414). Specifically, USM is designed to secure
against the principal and secondary threats discussed in section
2.3.1.
USM does not secure against Denial of Service and attacks based on
Traffic Analysis.
The security services the SNMP Security Model supports are:
o Data Integrity is the provision of the property that data has not
been altered or destroyed in an unauthorized manner, nor have data
sequences been altered to an extent greater than can occur non-
maliciously.
Ersue Expires May 31, 2011 [Page 10]
Internet-Draft IETF Management Framework November 2010
o Data Origin Authentication is the provision of the property that
the claimed identity of the user on whose behalf received data was
originated is supported.
o Data Confidentiality is the provision of the property that
information is not made available or disclosed to unauthorized
individuals, entities, or processes.
o Message timeliness and limited replay protection is the provision
of the property that a message whose generation time is outside of
a specified time window is not accepted.
See [RFC3414] in [STD62] for a detailed description of SNMPv3 USM.
2.3.3. View-Based Access Control Model (VACM)
The View-Based Access Control facility of SNMP enables the
configuration of agents to provide different levels of access to the
agent's MIB. An agent entity can restrict access to its MIB for a
particular manager entity in two ways:
o It can restrict access to a certain portion of its MIB, e.g., an
agent may restrict most manager principals to viewing performance-
related statistics and allow only a single designated manager
principal to view and update configuration parameters.
o The agent can limit the operations that a principal can use on
that portion of the MIB. E.g., a particular manager principal
could be limited to read-only access to a portion of an agent's
MIB.
The access control policy to be used by an agent must be pre-
configured for each manager. The policy is based on a table that
details the access privileges of the various authorized managers.
VACM defines five elements that make up the Access Control Model:
groups, security level, contexts, MIB views, and access policy.
See [RFC3415] in [STD62] for a detailed description of SNMPv3 VACM.
2.3.4. SNMP Transport Subsystem and Transport Security Model
The User-based Security Model (USM) was designed to be independent of
other existing security infrastructures to ensure it could function
when third-party authentication services were not available. As a
result, USM utilizes a separate user and key-management
infrastructure. Operators have reported that having to deploy
another user and key-management infrastructure in order to use SNMPv3
Ersue Expires May 31, 2011 [Page 11]
Internet-Draft IETF Management Framework November 2010
is costly and hinders the deployment of SNMPv3.
SNMP Transport Subsystem [RFC5590] extends the existing SNMP
framework and transport model and enables the use of transport
protocols to provide message security unifying the administrative
security management for SNMP, and other management interfaces.
Transport Models are tied into the SNMP framework through the
Transport Subsystem. The Transport Security Model has been designed
to work on top of lower-layer, secure Transport Models. The
Transport Security Model [RFC5591] and the Secure Shell Transport
Model [RFC5592] utilize the Transport Subsystem.
The Transport Security Model is an alternative to the existing SNMPv1
Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and
the User-based Security Model [RFC3414]. The Secure Shell Transport
Model defines furthermore an alternative to existing standard
transport mappings described in [RFC3417] such as SNMP over OSI, SNMP
over IPX and SNMP over UDP. SNMP over UDP has been so far the most
commonly used SNMP transport binding. The Experimental RFC [RFC3430]
defines a transport mapping with TCP.
The new SNMP Transport Subsystem modifies the Abstract Service
Interfaces to pass transport-specific security parameters to other
subsystems. This includes transport-specific security parameters
that are translated into the transport-independent parameters such as
securityName and securityLevel.
The SNMP Transport Subsystem utilizes one or more lower-layer
security mechanisms to provide message-oriented security services.
These include authentication of the sender, encryption, timeliness
checking, and data integrity checking.
A secure Transport Model establishes an authenticated and possibly
encrypted link between the Transport Models of two SNMP engines.
After a transport-layer tunnel is established, SNMP messages can be
sent through this tunnel from one SNMP engine to the other. The new
Transport Model supports sending multiple SNMP messages through the
same tunnel to amortize the costs of establishing a security
association.
The Transport Model on top of a secure transport protocol performs
security functions within the Transport Subsystem, including the
translation of transport-security parameters to/from Security-Model-
independent parameters. To accommodate this, an implementation-
specific cache of transport-specific information is introduced and
the data flows on this path are extended to pass Security-Model-
independent values. For this purpose, the Transport Subsystem
Ersue Expires May 31, 2011 [Page 12]
Internet-Draft IETF Management Framework November 2010
extends SNMPv3 Abstract Service Interfaces (ASI). New Security
Models can be defined using the modified ASIs and the transport-
information cache.
[RFC5592] introduces a Transport Model (Secure Shell Transport
Model), which makes use of the commonly deployed Secure Shell
security infrastructure establishing a channel between itself and the
SSH Transport Model of another SNMP engine.
Different IETF standards use security layers at the transport or
application layer to address security threads (e.g. TLS [RFC5246],
Simple Authentication and Security Layer (SASL) [RFC4422], and SSH
[RFC4251]). Different management interfaces, e.g. CLI, SYSLOG
[RFC5424] and NETCONF [RFC4741], use a secure transport layer to
provide secure information and message exchange to build management
applications.
Detailed description of the Transport Subsystem for SNMP and
Transport Security Model for SNMP can be found in [RFC5590] and
[RFC5591]. Secure Shell Transport Model for SNMP is specified in
[RFC5592] and Transport Layer Security (TLS) Transport Model for SNMP
is described in [RFC5953].
2.3.5. RADIUS Authentication and Authorization with SNMP Transport
Models
[RFC5608] describes the use of a RADIUS (Remote Authentication
Dial-In User Service) authentication and authorization service by
SNMP secure Transport Models for authentication of users and
authorization of secure transport session creation.
The secure transport protocols selected for use with RADIUS and SNMP
need to support user authentication methods that are compatible with
those that exist in RADIUS. Transport Models rely upon the
underlying secure transport for user authentication services. The
SSH protocol provides a secure transport channel with support for
channel authentication via local accounts and integration with
various external authentication and authorization services such as
RADIUS, Kerberos, etc. SSH Server integration with RADIUS
traditionally uses the username and password mechanism.
Service authorization and access control authorization are the use
cases for RADIUS support of management access via SNMP. User
authentication needs to be done prior to each of these use cases.
Service authorization allows a RADIUS server to authorize an
authenticated principal to use SNMP, optionally over a secure
transport, typically using an SNMP Transport Model (see [RFC5608]).
Ersue Expires May 31, 2011 [Page 13]
Internet-Draft IETF Management Framework November 2010
Access control authorization, i.e. how RADIUS attributes and messages
are applied to the specific application area of SNMP Access Control
Models, and VACM in particular is currently being specified in the
Integrated Security Model for SNMP (ISMS) working group.
2.4. Supplementary Components of the IETF Management Framework
2.4.1. NETCONF and its Modeling Language YANG
The IAB workshop on Network Management [RFC3535] determined advanced
requirements for configuration management:
o Robustness: Minimizing disruptions and maximizing stability,
o Support of task-oriented view,
o Extensible for new operations,
o Standardized error handling,
o Clear distinction between configuration data and operational
state,
o Distribution of configurations to devices under transactional
constraints,
o Single and multi-system transactions and scalability in the number
of transactions and managed devices,
o Operations on selected subsets of management data,
o Dump and reload a device configuration in a textual format in a
standard manner across multiple vendors and device types,
o Support a human interface and a programmatic interface,
o Data modeling language with a human friendly syntax,
o Easy conflict detection and configuration validation, and
o Secure transport, authentication, and robust access control.
The NETCONF protocol [RFC4741] is a Proposed Standard that provides
mechanisms to install, manipulate, and delete the configuration of
network devices and aims to address the advanced configuration
management requirements pointed in the IAB workshop. It uses an
Extensible Markup Language (XML)-based data encoding for the
configuration data as well as the protocol messages. The NETCONF
Ersue Expires May 31, 2011 [Page 14]
Internet-Draft IETF Management Framework November 2010
protocol operations are realized on top of a simple and reliable
Remote Procedure Call (RPC) layer.
A key aspect of NETCONF is that it allows the functionality of the
management protocol to closely mirror the native command line
interface of the device. In addition, applications can access both
the syntactic and semantic content of the device's native user
interface.
NETCONF working group developed the NETCONF Event Notifications
Mechanism as an optional capability, which provides an asynchronous
message notification delivery service for NETCONF [RFC5277]. NETCONF
notification mechanism enables using general purpose notification
streams, which can also transport alarms from other sources, where
the originator of the notification stream can be any managed device
(e.g. SNMP alarms).
NETCONF Partial Locking introduces fine-grained locking of the
configuration datastore to enhance NETCONF for fine-grained
transactions on parts of the datastore [RFC5717].
NETCONF working group also defined the necessary data model to
monitor the NETCONF protocol by using YANG. The monitoring data
model includes information about NETCONF datastores, sessions, locks,
and statistics, which facilitate the management of a NETCONF server.
NETCONF monitoring document also defines methods for NETCONF clients
to discover the data models supported by a NETCONF server and defines
the operation <get-schema> to retrieve them [RFC6022].
NETCONF working group defined SSH transport binding as the mandatory
secure transport of its RPC messages [RFC4742]. Other optional
secure transport bindings are available for TLS [RFC5539], BEEP (over
TLS) [RFC4744], and SOAP (over HTTP over TLS) [RFC4743]. There is an
implementation available using NETCONF over SOAP as a Web Service
[RFC5381].
Currently NETCONF working group is focusing on bug fixing of the
NETCONF base protocol standard [4741bis] and the SSH transport
protocol mapping [4742bis] as well as the specification of the
NETCONF Access Control Model (NACM). NACM is going to provide a
secure operating environment for NETCONF and proposes standard
mechanisms to restrict protocol access to particular users with a
pre-configured subset of operations and content.
NETMOD working group developed YANG as the normative modeling
language for the modeling of configuration data for usage with
NETCONF (see section 2.4.1.1). NETMOD working group also developed
Common YANG Data Types to be used with YANG [RFC6021] and a
Ersue Expires May 31, 2011 [Page 15]
Internet-Draft IETF Management Framework November 2010
guidelines document for authors and reviewers of YANG Data Model
Documents [I-D draft-ietf-netmod-yang-usage] as well as the mapping
rules for translating YANG data models into Document Schema
Definition Languages (DSDL) [I-D.ietf-netmod-dsdl-map]. The
architecture document "An Architecture for Network Management using
NETCONF and YANG" describes how NETCONF and YANG can help to build
network management applications that meet the needs of network
operators [I-D.draft-ietf-netmod-arch].
IPFIX working group prepared the normative IPFIX/PSAMP configuration
model for configuring and monitoring IPFIX and PSAMP compliant
Monitoring Devices using the YANG modeling language and is proposing
to use NETCONF for the configuration of these entities [I-D.ietf-
ipfix-configuration-model].
As of today NETCONF is provided by some major vendor companies but
has not been widely deployed yet. To support wide usage of NETCONF
standard YANG modules are needed. NETMOD working group will focus in
its second working phase on the development of core system and core
interface data models. The working group will not develop models for
specific topic areas or working groups at IETF. Following the
example of IPFIX configuration model such modeling work will be done
in corresponding working groups at IETF.
2.4.1.1. YANG - NETCONF Modeling Language
Following the guideline and requests of the IAB management workshop
[RFC3535] the NETMOD working group developed a modeling language
defining the semantics of operational and configuration data,
notifications, and operations [RFC6020]. The new modeling language
will serve as the normative description of NETCONF data models.
YANG has been prepared with following design goals in mind addressing
specific requirements on a modeling language for configuration
management:
o Allow modeling of standard and vendor defined modules for multi-
vendor interoperability,
o Define semantics and data organization, i.e. models operational
and configuration data, notifications, and operations,
o "human-readable", easy to use and text-based,
o Enable addition of new content to existing data models and can be
extended at IETF as necessary,
Ersue Expires May 31, 2011 [Page 16]
Internet-Draft IETF Management Framework November 2010
o Map directly to XML content (on the wire), and
o Basic types compatible with SMIv2, which preserve investments in
SNMP MIBs.
ADD: Input from YANG team.
2.4.2. SYSLOG
SYSLOG is a mechanism for distribution of logging information
initially used on Unix systems. IETF documented the status quo of
the BSD SYSLOG protocol in the Informational [RFC3164]. The IETF
SYSLOG protocol [RFC5424] obsoletes [RFC3164] and introduces a
layered architecture allowing the use of any number of transport
protocols, including reliable transports and secure transports, for
transmission of SYSLOG messages.
The content of BSD SYSLOG messages has traditionally been
unstructured natural language text. This content is human-friendly,
but difficult for applications to parse and correlate across vendors,
or correlate with other event reporting such as SNMP traps. The
SYSLOG protocol [RFC5424] includes structured data elements to aid
application-parsing.
The SYSLOG protocol enables a machine to send system log messages
across networks to event message collectors. The protocol is simply
designed to transport and distribute these event messages. No
acknowledgement of the receipt is made. The SYSLOG protocol and
process does not require a stringent coordination between the
transmitters and the receivers. Indeed, the transmission of SYSLOG
messages may be started on a device without a receiver being
configured, or even actually physically present. Conversely, many
devices will most likely be able to receive messages without explicit
configuration or definitions. This simple approach aided the
deployment of SYSLOG.
BSD SYSLOG had little uniformity for the message format and the
content of SYSLOG messages. The IETF has standardized a new message
header format, including timestamp, hostname, application, and
message ID, to improve filtering, interoperability and correlation
between compliant implementations.
The SYSLOG protocol further introduces a mechanism for defining
Structured Data Elements (SDEs). The SDEs allow vendors to define
their own structured data elements to supplement standardized
elements. [RFC5675] defines a mapping from SNMP notifications to
SYSLOG messages and [RFC5676] defines the corresponding managed
objects for this purpose. [RFC5674] defines the way alarms are send
Ersue Expires May 31, 2011 [Page 17]
Internet-Draft IETF Management Framework November 2010
in SYSLOG, which includes the mapping of ITU perceived severities
onto SYSLOG message fields and a number of alarm-specific definitions
from ITU-T X.733 and the IETF Alarm MIB.
The IETF has standardized MIB Textual-Conventions for facility and
severity labels and codes to encourage consistency between SYSLOG and
MIB representations of these event properties. The intent is that
these textual conventions will be imported and used in MIB modules
that would otherwise define their own representations. [RFC5427]
[RFC5848] "Signed Syslog Messages" defines a mechanism to add origin
authentication, message integrity, replay resistance, message
sequencing, and detection of missing messages to the transmitted
SYSLOG messages to be used in conjunction with the SYSLOG protocol.
The SYSLOG protocol layered architecture provides for support of any
number of transport mappings. However, for interoperability
purposes, SYSLOG protocol implementers are required to support the
transmission of SYSLOG Messages over UDP as defined in [RFC5426].
IETF furthermore defined the TLS transport mapping for SYSLOG in
[RFC5425], which provides a secure connection for the transport of
SYSLOG messages and describes the security threats to SYSLOG and how
TLS can be used to counter such threats. Datagram Transport Layer
Security (DTLS) Transport Mapping for SYSLOG is defined in [RFC6012],
which can be used in cases where a connection-less transport is
desired.
IETF working groups are encouraged to standardize structured data
elements, extensible human-friendly text, and consistent facility/
severity values for SYSLOG to report events specific to their
protocol.
2.4.3. IPFIX/PSAMP
IPFIX [RFC5101] is a Proposed Standard, which defines a push-based
data export mechanism for formatting and transferring IP flow
information from an exporter to a collector. PSAMP defines a
standard set of capabilities for network elements to sample subsets
of packets by statistical and other methods.
The IPFIX working group has specified the Information Model (to
describe IP flows) and the IPFIX protocol for the export of flow
information from routers or measurement probes to external systems
[RFC5101], [RFC5102]. IPFIX protocol exports flow data e.g. from
routers and probes (IPv4, IPv6) and works on top of the transport
bindings SCTP (mandatory), UDP and TCP. Several applications using
the IPFIX protocol are available.
Ersue Expires May 31, 2011 [Page 18]
Internet-Draft IETF Management Framework November 2010
IPFIX [RFC5101] is a Proposed Standard approach for transmitting IP
traffic flow information over the network from an exporting process
to an information collecting process. IPFIX defines a common
representation of flow data and a standard means of communicating the
data over a number of transport protocols.
The Informational RFC [RFC3917] specifies the observation point,
flows, exporting and the collecting process as well as a metering
process that consists of a packet header capturing, time stamping,
classifying, sampling, and maintaining flow records.
IPFIX Information Model defines Information Elements (IEs) for
distinguishing flows and for reporting flow characteristics
[RFC5102]. Information Model for PSAMP extends the IPFIX information
model by IEs for packet header and payload information [RFC5477] and
defines packet selection methods for filtering and sampling of such
data. IPFIX and PSAMP packet sampling use the same packet processing
(aka. packet mediation). PSAMP packet information is exported with
the IPFIX protocol based on a shared information model.
The IPFIX working group has developed an XML-based configuration data
model in close collaboration with the NETMOD working group and uses
YANG as modeling language [I-D.ietf-ipfix-configuration-model]. The
model specifies the necessary data for configuring and monitoring
selection processes, caches, exporting processes, and collecting
processes of IPFIX and PSAMP compliant monitoring devices.
At the time of this writing a framework for IPFIX flow mediation is
in preparation, which addresses the need for mediation of flow
information in IPFIX applications in large operator networks, e.g.
for aggregating huge amounts of flow data and for anonymization of
flow information. IPFIX Mediation Framework defines the intermediate
device between Exporters and Collectors, which provides an IPFIX
Mediation by receiving a record stream from e.g. a Collecting
Process, hosting one or more Intermediate Processes to transform this
stream, and exporting the transformed record stream into IPFIX
Messages via an Exporting Process [I-D.ietf-ipfix-mediators-
framework].
The work on IP Flow Anonymization Support describes anonymization
techniques for IP flow data and the export of anonymized data
[I-D.ietf-ipfix-anon].
The document 'IPFIX Export per SCTP Stream' [I-D.ietf-ipfix-export-
per-sctp-stream] specifies a reliability extension based on a method
for exporting a Template Record and its associated Data Sets in a
single SCTP stream, for limiting each Template ID to a single SCTP
stream and imposing in-order transmission.
Ersue Expires May 31, 2011 [Page 19]
Internet-Draft IETF Management Framework November 2010
[I-D.ietf-ipfix-structured-data] proposes an extension to the IPFIX
protocol to support the export of hierarchically structured data and
lists (sequences) of Information Elements in data records. The
document describes how to distribute structured data with an abstract
data type and a new Information Element, e.g. for the distribution of
security keys or performance measures. This application can also be
used for the distribution of logging information if standard SYSLOG
based logging is not available.
There are several applications such as usage-based accounting,
traffic profiling, traffic engineering, intrusion detection, and QoS
monitoring, that require flow-based traffic measurements, which can
be realized on top of IPFIX. IPFIX can also be used e.g. for the
monitoring of the protocols like SIP and the related media transfer,
which is indeed based on flows on application layer. The
requirements to such a monitoring application are e.g. measuring
signaling quality (e.g., session request delay, session completion
ratio, or hops for request), media QoS (e.g., jitter, delay or bit
rate), and user experience (e.g., Mean Opinion Score).
Several applications require sampling packets from specific data
flows, or across multiple data flows, and reporting information about
the packets. Measurement-based network management is a prime
example. The PSAMP working group developed the protocol for
reporting observed packets by extending the IPFIX protocol. In order
to reduce the amount of data to be processed for selecting observed
IP packets, packet selection methods have been defined.
PSAMP standardizes sampling, selection, metering, and reporting
strategies for different purposes and includes support for packet
sampling in IPv4, IPv6, and MPLS-based networks. To simplify the
solution, the IPFIX protocol is used for the export of the PSAMP
reports to collector applications.
NOTE: Input from IPFIX WG?
3. Management Protocols and Mechanisms with specific Focus
This section reviews additional protocols IETF offers for management
and discusses for which applications they were designed and/or
already successfully deployed. These are protocols that have mostly
reached or short before Proposed Standard status or higher within the
IETF.
3.1. IP Address Management with DHCP
The Draft Standard Dynamic Host Configuration Protocol (DHCP)
[RFC2131] was defined as an extension to BOOTP (Bootstrap Protocol)
Ersue Expires May 31, 2011 [Page 20]
Internet-Draft IETF Management Framework November 2010
[RFC0951]. DHCP provides a framework for passing configuration
information to hosts on a TCP/IP network and enables as such
autoconfiguration in IP networks. In addition to IP address
management, DHCP can also provide other configuration information,
particularly the IP addresses of local caching DNS resolvers or
servers providing servers. As described in [I-D.baker-ietf-core]
DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment
as well as Service Discovery.
There are two versions of DHCP, one for IPv4 [RFC2131] and one for
IPv6 [RFC3315]. While both versions bear the same name and perform
much the same purpose, the details of the protocol for IPv4 and IPv6
are sufficiently different that they can be considered separate
protocols.
Following are examples, where DHCP options have been used to provide
configuration information or access to specific servers.
o [RFC3646] describes two DHCPv6 options for passing a list of
available DNS recursive name servers and a domain search list to a
client.
o [RFC2610] describes how entities using the Service Location
Protocol can find out the address of Directory Agents in order to
transact messages and how the assignment of scope for
configuration of SLP User and Service Agents can be achieved.
o [RFC3319] specifies two DHCPv6 options that allow SIP clients to
locate a local SIP server that is to be used for all outbound SIP
requests, a so-called outbound proxy server.
o [RFC4280] defines new options to discover the Broadcast and
Multicast Service (BCMCS) controller in an IP network.
3.2. IPv6 Network Operations
The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks, as
well as into new network installations.
The Proposed Standard [RFC4213] specifies IPv4 compatibility
mechanisms for dual stack and configured tunneling that can be
implemented by IPv6 hosts and routers. Dual stack implies providing
complete implementations of both IPv4 and IPv6, and configured
tunneling provides a means to carry IPv6 packets over unmodified IPv4
routing infrastructures.
Ersue Expires May 31, 2011 [Page 21]
Internet-Draft IETF Management Framework November 2010
[RFC3574] lists different scenarios in 3GPP defined packet network
that would need IPv6 and IPv4 transition, where [RFC4215] does a more
detailed analysis of the transition scenarios that may come up in the
deployment phase of IPv6 in 3GPP packet networks.
[RFC4029] describes and analyzes different scenarios for the
introduction of IPv6 into an ISP's existing IPv4 network. [RFC5181]
provides a detailed description of IPv6 deployment, integration
methods and scenarios in wireless broadband access networks (802.16)
in coexistence with deployed IPv4 services. [RFC4057] describes the
scenarios for IPv6 deployment within enterprise networks.
[RFC4038] specifies scenarios and application aspects of IPv6
transition considering how to enable IPv6 support in applications
running on IPv6 hosts, and giving guidance for the development of IP
version-independent applications.
NOTE: Additional input needed.
3.3. SNMP Agent Extensibility (AgentX) Protocol
The Draft Standard [RFC2741] "Agent Extensibility (AgentX) Protocol"
defines a framework for extensible SNMP agents including master
agents and subagents, the AgentX protocol used to communicate between
them, and how the extensible agent processes SNMP protocol messages.
Within the SNMP framework, a managed node contains a processing
entity called agent, which has access to management information.
Within the AgentX framework, an agent is further defined to consist
of:
o a single processing entity called the master agent, which sends
and receives SNMP protocol messages in an agent role (as specified
by the SNMP framework documents) but typically has little or no
direct access to management information, and
o zero or more processing entities called subagents, which are
"shielded" from the SNMP protocol messages processed by the master
agent, but which have access to management information.
The internal operations of AgentX are invisible to an SNMP entity
operating in a manager role. From a manager's point of view, an
extensible agent behaves exactly as would a non-extensible
(monolithic) agent that has access to the same management
instrumentation.
[RFC2741] specifies furthermore a TCP binding for the AgentX
protocol.
Ersue Expires May 31, 2011 [Page 22]
Internet-Draft IETF Management Framework November 2010
The Draft Standard [RFC2742] "Definitions of Managed Objects for
Extensible SNMP Agents" describes objects managing SNMP agents that
use the AgentX Protocol and specifies a MIB module, which is
compliant to the SMIv2, and semantically identical to the peer SMIv1
definitions.
3.4. RADIUS
RADIUS [RFC2865], the remote Authentication Dial In User Service, is
a Draft Standard that describes a client/server protocol for carrying
authentication, authorization, and configuration information between
a Network Access Server (NAS), which desires to authenticate its
links and a shared Authentication Server.
This protocol is widely implemented and is used in environments like
enterprise networks, where a single administrative authority manages
the network, and protects the privacy of user information.
RADIUS is extensible with Vendor-Specific Attributes (VSAs), which
are mostly vendor-specific.
The RADIUS protocol uses a shared secret along with the MD5 hashing
algorithm to secure passwords. Based on the known threads additional
protection like IPsec tunnels are used to further protect the RADIUS
traffic.
RADIUS has been prepared to use over UDP port 1812 for RADIUS
Authentication and 1813 for RADIUS Accounting.
[RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over
IPv6 and the RADIUS attributes used to support the IPv6 network
access.
[RFC4675] 'RADIUS Attributes for Virtual LAN and Priority Support'
defines additional attributes for dynamic Virtual LAN assignment and
prioritization, for use in provisioning of access to IEEE 802 local
area networks usable with RADIUS and DIAMETER.
[RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes'
describes common issues seen in RADIUS implementations and suggests
some fixes. Where applicable, unclear statements and errors in
previous RADIUS specifications are clarified.
[RFC5090] 'RADIUS Extension for Digest Authentication' defines an
extension to the RADIUS protocol to enable support of Digest
Authentication, for use with HTTP-style protocols like the Session
Initiation Protocol (SIP) and HTTP.
Ersue Expires May 31, 2011 [Page 23]
Internet-Draft IETF Management Framework November 2010
[RFC5580] 'Carrying Location Objects in RADIUS and DIAMETER describes
procedures for conveying access-network ownership and location
information based on civic and geospatial location formats in RADIUS
and DIAMETER.
NOTE: Need more discussion of RADIUS RFCs and use cases.
3.5. DIAMETER
DIAMETER [RFC3588] is a Proposed Standard that provides an
Authentication, Authorization and Accounting (AAA) framework for
applications such as network access or IP mobility. DIAMETER is also
intended to work in local Authentication, Authorization, Accounting
situations and in roaming situations. DIAMETER is not directly
backwards compatible, but provides an upgrade path for RADIUS.
DIAMETER is designed to resolve a number of known problems with
RADIUS. DIAMETER supports server failover, reliable transport over
TCP and SCTP, agents for proxy and redirect and relay, server-
initiated messages, auditability, and capability negotiation.
DIAMETER also provides a larger attribute space for attribute-value
pairs (AVPs) and identifiers than RADIUS. DIAMETER features make it
especially appropriate for environments where the providers of
services are in different administrative domains than the maintainer
(protector) of confidential user information.
Other important differences to RADIUS are:
- Use of reliable transport protocols (TCP or SCTP, not UDP),
- Network and transport layer security (IPsec or TLS),
- Stateful and stateless models,
- Dynamic discovery of peers (using DNS SRV and NAPTR),
- Supports application layer acknowledgements, defines failover
methods and state machines [RFC3539],
- Error notification,
- Better roaming support,
- Easier to extend, and
- Basic support for user-sessions and accounting.
The DIAMETER protocol has been enhanced for the use with 3GPP IP
Multimedia Subsystem (IMS). Different IMS interfaces (e.g. Cx) are
supported by DIAMETER applications [3GPPIMS].
The protocol is designed to be extensible to support e.g. proxies,
brokers, mobility and roaming, Network Access Servers (NASREQ), and
Accounting and Resource Management. DIAMETER applications extend the
DIAMETER base protocol by adding new commands and/or attributes.
Each application is defined by an application identifier and can add
new command codes and/or new mandatory Attribute-Value Pairs (AVPs).
Ersue Expires May 31, 2011 [Page 24]
Internet-Draft IETF Management Framework November 2010
Following are examples of DIAMETER applications:
- DIAMETER Mobile IPv4 Application [RFC4004],
- DIAMETER Network Access Server Application (NASREQ, [RFC4005]),
- DIAMETER Extensible Authentication Protocol Application [RFC4072],
- DIAMETER Credit-Control Application [RFC4006],
- DIAMETER Session Initiation Protocol Application [RFC4740], and
- DIAMETER Quality-of-Service Application [RFC5866].
[RFC5516] 'DIAMETER Command Code Registration for the Third
Generation Partnership Project (3GPP) Evolved Packet System (EPS)'
registers a set of IANA DIAMETER Command Codes to use in new vendor-
specific DIAMETER applications defined for the 3GPP) Evolved Packet
System (EPS).
[RFC5447] 'DIAMETER Mobile IPv6: Support for Network Access Server to
DIAMETER Server Interaction' describes the bootstrapping of the
Mobile IPv6 framework and the support of interworking with existing
Authentication, Authorization, and Accounting (AAA) infrastructures
by using the DIAMETER Network Access Server to home AAA server
interface.
[RFC5777] 'Traffic Classification and Quality of Service (QoS)
Attributes for DIAMETER' defines a number of DIAMETER AVPs for
traffic classification with actions for filtering and Quality of
Service (QoS) treatment.
[RFC5729] 'Clarifications on the Routing of DIAMETER Requests Based
on the Username and the Realm' defines the behavior required of
DIAMETER agents to route requests when the User-Name AVP contains a
Network Access Identifier formatted with multiple realms. These
multi-realm Network Access Identifiers are used in order to force the
routing of request messages through a predefined list of mediating
realms.
DIAMETER uses port number 3868 for TCP and SCTP.
NOTE: Need more discussion of DIAMETER RFCs and use cases.
3.6. CAPWAP
Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility
management, and radio management from the single access point to a
centralized controller.
Ersue Expires May 31, 2011 [Page 25]
Internet-Draft IETF Management Framework November 2010
Based on the CAPWAP Architecture Taxonomy work [RFC4118] CAPWAP
working group developed the CAPWAP protocol to facilitate control,
management and provisioning of WLAN Termination Points (WTPs)
specifying the services, functions and resources relating to 802.11
WLAN Termination Points in order to allow for interoperable
implementations of WTPs and ACs. The protocol defines the CAPWAP
control plane including the primitives to control data access. The
protocol document also specifies how configuration management of WTPs
can be done and defines CAPWAP operations responsible for debugging,
gathering statistics, logging, and firmware management as well as
discusses operational and transport considerations.
CAPWAP protocol is prepared to be independent of Layer 2
technologies, and meets the objectives in "Objectives for Control and
Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate
binding extensions enable the use with additional wireless
technologies. [RFC5416] defines CAPWAP Protocol Binding for IEEE
802.11.
CAPWAP Base MIB [RFC5833] specifies managed objects for modeling the
CAPWAP Protocol and provides configuration and WTP status-monitoring
aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] defines managed
objects for modeling of CAPWAP protocol for IEEE 802.11 wireless
binding.
RFC 5833 and RFC 5834 have been published as Informational RFCs to
provide the basis for future work on a SNMP management of the CAPWAP
protocol.
3.7. Access Node Control Protocol
The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol]
realizes a control plane between a service-oriented layer 3 edge
device (the Network Access Server, NAS) and a layer 2 Access Node
(e.g., Digital Subscriber Line Access Module, DSLAM). As such ANCP
operates in a multi-service reference architecture and communicates
QoS-, service- and subscriber-related configurations and operations
between a NAS and an Access Node.
The main goal of this protocol is to configure and manage access
equipments and allow them to report information to the NAS in order
to enable and optimize configuration.
Framework and Requirements for an Access Node Control Mechanism and
the use cases for ANCP are documented in [RFC5851]. Security Threats
and Security Requirements for ANCP are discussed in [RFC5713].
Ersue Expires May 31, 2011 [Page 26]
Internet-Draft IETF Management Framework November 2010
3.8. Ad-Hoc Network Autoconfiguration
Ad-hoc nodes need to configure their network interfaces with locally
unique addresses as well as globally routable IPv6 addresses, in
order to communicate with devices on the Internet. AUTOCONF working
group developed [RFC5889], which describes the addressing model for
ad-hoc networks and how nodes in these networks configure their
addresses.
The ad-hoc nodes under consideration are expected to be able to
support multi-hop communication by running MANET routing protocols as
developed by the IETF MANET working group.
From the IP layer perspective, an ad hoc network presents itself as a
layer 3 multi-hop network formed over a collection of links. The
addressing model aims to avoid problems for ad-hoc-unaware parts of
the system, such as standard applications running on an ad-hoc node
or regular Internet nodes attached to the ad-hoc nodes.
3.9. Policy-based Management
3.9.1. IETF Policy Framework
IETF specified a general framework for managing, sharing, and reusing
policies in a vendor independent, interoperable, and scalable manner
as well as defining an extensible information model for representing
policies. The policy framework is based on a policy-based admission
control specifying the two main architectural elements the Policy
Enforcement Point (PEP) and the Policy Decision Point (PDP).
For the purposes of network management, policies allow an operator to
specify how the network is to be configured and monitored through a
descriptive language. Furthermore, it allows the automation of a
number of management tasks, according to the requirements set out in
the policy module.
IETF Policy Framework [RFC2753] has been accepted by the industry as
a standard-based policy approach and has been adopted by different
SDOs e.g. 3GGP charging standards.
3.9.2. COPS-PR
[RFC3159] defines the Structure of Policy Provisioning Information
(SPPI), an extension to the SMI modeling language used to write
Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the
Common Open Policy Service (COPS) protocol for support of policy
provisioning. The COPS-PR specification is independent of the type
of policy being provisioned (QoS, Security, etc.) but focuses on the
Ersue Expires May 31, 2011 [Page 27]
Internet-Draft IETF Management Framework November 2010
mechanisms and conventions used to communicate provisioned
information between policy-decision-points (PDPs) and policy
enforcement points (PEPs). Policy data is modeled using Policy
Information Base modules (PIB modules).
COPS-PR has not been widely deployed, and operators have stated that
its use of binary encoding (BER) for management data makes it
difficult to develop automated scripts for simple configuration
management tasks in most text-based scripting languages. In the IAB
Workshop on Network Management [RFC3535], the consensus of operators
and protocol developers indicated a lack of interest in PIB modules
for use with COPS-PR.
As a result, the IESG has not approved any policy models (PIB
modules) as IETF standard, and the use of COPS-PR is not recommended.
3.10. Network Performance Management
3.10.1. IP Performance Metrics (IPPM)
The IPPM working group has defined metrics for accurately measuring
and reporting the quality, performance, and reliability of Internet
data delivery services. The metrics include connectivity, one-way
delay and loss, round-trip delay and loss, delay variation, loss
patterns, packet reordering, bulk transport capacity, and link
bandwidth capacity.
These metrics are designed for network operator use and provide
unbiased quantitative measures of performance.
The main properties of individual IPPM performance and reliability
metrics are that the metrics should be well-defined and concrete thus
implementable, and they should exhibit no bias for IP clouds
implemented with identical technology. In addition, the methodology
used to implement a metric should have the property of being
repeatable with consistent measurements.
IETF IP Performance Metrics have been introduced widely in the
industry and adopted by different SDOs such as ITU-T.
Following are examples of essential IPPM documents published as
Proposed Standard:
o IPPM Framework document [RFC2330] defines a general framework for
particular metrics developed by IPPM working group and defines the
fundamental concepts of 'metric' and 'measurement methodology' and
discusses the issue of measurement uncertainties and errors as
well as introduces the notion of empirically defined metrics and
Ersue Expires May 31, 2011 [Page 28]
Internet-Draft IETF Management Framework November 2010
how metrics can be composed.
o One-way Delay Metric for IPPM [RFC2679] defines a metric for one-
way delay of packets across Internet paths. It builds on notions
introduced in the IPPM Framework document.
o Round-trip Delay Metric for IPPM [RFC2681] defines a metric for
round-trip delay of packets across network paths and follows
closely the corresponding metric for One-way Delay.
o IP Packet Delay Variation Metric [RFC3393] refers to a metric for
variation in delay of packets across network paths and is based on
the difference in the One-Way-Delay of selected packets called "IP
Packet Delay Variation (ipdv)".
o One-way Packet Loss Metric for IPPM [RFC2680] defines a metric for
one-way packet loss across Internet paths.
o One-Way Packet Duplication Metric [RFC5560] defines a metric for
the case, where multiple copies of a packet are received and
discusses methods to summarize the results of streams.
o Packet Reordering Metrics [RFC4737] defines metrics to evaluate
whether a network has maintained packet order on a packet-by-
packet basis and discusses the measurement issues, including the
context information required for all metrics.
o IPPM Metrics for Measuring Connectivity [RFC2678] defines a series
of metrics for connectivity between a pair of Internet hosts.
o Framework for Metric Composition [RFC5835] describes a detailed
framework for composing and aggregating metrics.
o A One-way Active Measurement Protocol (OWAMP) [RFC4656] measures
unidirectional characteristics such as one-way delay and one-way
loss between network devices and enables the interoperability of
these measurements.
o A Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adds
round-trip or two-way measurement capabilities to OWAMP.
For the "Information Model and XML Data Model for Traceroute
Measurements [RFC5388] and [BCP108] "IP Performance Metrics (IPPM)
Metrics Registry" see section 4.4 'Performance Management'.
Ersue Expires May 31, 2011 [Page 29]
Internet-Draft IETF Management Framework November 2010
3.10.2. Real-time Flow Measurement (RTFM)
(Real-Time) Traffic Flow Measurement: Architecture [RFC2722]
specifies the general framework for describing network traffic flows,
an architecture for traffic flow measurement and reporting, and
indicates how it can be used within the Internet. As such RTFM is a
mechanism for configuring meters and meter readers, and for
collecting the flow data from remote meters.
RTFM is e.g. used for the measurement of DNS performance.
3.11. Application Layer Management Protocols
3.11.1. ACAP
The Application Configuration Access Protocol (ACAP) [RFC2244] is
designed to support remote storage and access of program option,
configuration and preference information. The data store model is
designed to allow a client relatively simple access to interesting
data, to allow new information to be easily added without server re-
configuration, and to promote the use of both standardized data and
custom or proprietary data. Key features include "inheritance" which
can be used to manage default values for configuration settings and
access control lists which allow interesting personal information to
be shared and group information to be restricted.
ACAP's primary purpose is to allow users access to their
configuration data from multiple network-connected computers. Users
can then sit down in front of any network-connected computer, run any
ACAP-enabled application and have access to their own configuration
data. Because it is hoped that many applications will become ACAP-
enabled, client simplicity was preferred to server or protocol
simplicity whenever reasonable.
3.11.2. XCAP
XCAP [RFC4825] is a Proposed Standard protocol that allows a client
to read, write, and modify application configuration data stored in
XML format on a server.
XCAP is a protocol that can be used to manipulate per-user data.
XCAP is a set of conventions for mapping XML documents and document
components into HTTP URIs, rules for how the modification of one
resource affects another, data validation constraints, and
authorization policies associated with access to those resources.
Because of this structure, normal HTTP primitives can be used to
manipulate the data. XCAP is meant to support the configuration
needs for a multiplicity of applications, rather than just a single
Ersue Expires May 31, 2011 [Page 30]
Internet-Draft IETF Management Framework November 2010
one.
3.11.3. EPP
The Extensible Provision Protocol [RFC5730] is a Full Standard
[STD69] that describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository. EPP permits multiple service providers to
perform object provisioning operations using a shared central object
repository, and addresses the requirements for a generic registry
registrar protocol.
EPP is specified in XML and defines generic object management
operations and an extensible framework that maps protocol operations
to objects. EPP is a stateful XML protocol that can be layered over
multiple transport protocols. Protected using lower-layer security
protocols, clients exchange identification, authentication, and
option information, and then engage in a series of client-initiated
command-response exchanges.
EPP has been adopted by numerous domain name registries mainly for
the communication between domain name registries and domain name
registrars and for allocating objects within registries over the
Internet.
4. Proposed, Draft and Standard Level Data Models
This section lists solutions for which information or data models
have been standardized at the IETF, so that existing solutions can be
reused and the data models can be applied to new solutions.
Management data models have a slightly different interpretation for
interoperability. This is discussed in detail in [BCP27]
"Advancement of MIB specifications on the IETF Standards Track"
[RFC2438] with special considerations about the advancement process
for management data models. However most IETF management data models
never advance beyond Proposed Standard.
This section discusses management data models that have reached
Proposed Standard status at the IETF. In exceptional cases important
Informational RFCs are referred.
4.1. Fault Management
Draft Standards:
[RFC3418], part of SNMPv3 standard [STD62], contains objects in the
system group that are often polled to determine if a device is still
Ersue Expires May 31, 2011 [Page 31]
Internet-Draft IETF Management Framework November 2010
operating, and sysUpTime can be used to detect if a system has
rebooted, and counters have been reinitialized.
[RFC3413], part of SNMPv3 standard [STD62], includes objects designed
for managing notifications, including tables for addressing, retry
parameters, security, lists of targets for notifications, and user
customization filters.
An RMON monitor [RFC2819] can be configured to recognize conditions,
most notably error conditions, and continuously to check for them.
When one of these conditions occurs, the event may be logged, and
management stations may be notified in a number of ways (for further
discussion on RMON see section 4.4 'Performance Management').
Proposed Standards:
The SYSLOG protocol document defines an initial set of Structured
Data Elements (SDEs) that relate to content time quality, content
origin, and meta-information about the message, such as language.
Proprietary SDEs can be used to supplement the IETF-defined SDEs.
DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982]
provide a superset of the capabilities of the RMON alarm and event
groups. These modules provide mechanisms for thresholding and
reporting anomalous events to management applications.
The ALARM MIB in [RFC3877] and the Alarm Reporting Control MIB in
[RFC3878] specify mechanisms for expressing state transition models
for persistent problem states.
ALARM MIB defines:
- a mechanism for expressing state transition models for persistent
problem states,
- a mechanism to correlate a notification with subsequent state
transition notifications about the same entity/object, and
- a generic alarm reporting mechanism (extends ITU-T work X.733 [ITU-
X733).
[RFC3878] in particular defines objects for controlling the reporting
of alarm conditions and extends ITU-T work M.3100 Amendment 3 [ITU-
M3100].
Other MIB modules that may be applied to Fault Management include:
o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for
logging SNMP Notifications.
Ersue Expires May 31, 2011 [Page 32]
Internet-Draft IETF Management Framework November 2010
o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB
to provide information about the state of physical entities.
o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for
extending the Entity MIB to provide generalized access to
information related to physical sensors, which are often found in
networking equipment (such as chassis temperature, fan RPM, power
supply voltage).
4.2. Configuration Management
Draft standards:
It is expected that standard XML-based data models will be developed
for use with NETCONF, and working groups might identify specific
NETCONF data models that would be applicable to the new protocol.
At the time of this writing, only the YANG module for the monitoring
of the NETCONF protocol exists as proposed standard. NETMOD working
group is going to be rechartered to develop core system models in
YANG.
MIB modules for monitoring of network configuration (e.g. for
physical and logical network topologies) already exist and provide
some of the desired capabilities. New MIB modules might be developed
for the target functionality to allow operators to monitor and modify
the operational parameters, such as timer granularity, event
reporting thresholds, target addresses, and so on.
[RFC3418], part of SNMPv3 standard [STD62], contains objects in the
system group that are often polled to determine if a device is still
operating, and sysUpTime can be used to detect if a system has
rebooted and caused potential discontinuity in counters. Other
objects in the system MIB are useful for identifying the type of
device, the location of the device, the person responsible for the
device, etc.
[RFC3413], part of STD 62 SNMPv3, includes objects designed for
configuring notification destinations, and for configuring proxy-
forwarding SNMP agents, which can be used to forward messages through
firewalls and NAT devices.
The Interfaces MIB [RFC2863] is used for managing Network Interfaces.
This includes the 'interfaces' group of MIB-II and discusses the
experience gained from the definition of numerous media-specific MIB
modules for use in conjunction with the 'interfaces' group for
managing various sub-layers beneath the internetwork-layer.
Ersue Expires May 31, 2011 [Page 33]
Internet-Draft IETF Management Framework November 2010
Proposed standards:
The Entity MIB [RFC4133] is used for managing multiple logical and
physical entities managed by a single SNMP agent. This module
provides a useful mechanism for identifying the entities comprising a
system. There are also event notifications defined for configuration
changes that may be useful to management applications.
[RFC3165] supports the use of user-written scripts to delegate
management functionality.
Policy Based Management MIB [RFC4011] defines objects that enable
policy-based monitoring using SNMP, using a scripting language, and a
script execution environment.
Few vendors have implemented MIB modules that support scripting.
Some vendors consider running user-developed scripts within the
managed device as a violation of support agreements.
4.3. Accounting Management
DIAMETER [RFC3588] and RADIUS [RFC2866] can be used to exchange
accounting related information.
IETF so far did only develop Informational RFCs as data model for
accounting. RADIUS Accounting Client MIB for IPv6 [RFC4670] and
RADIUS Accounting Server MIB for IPv6 [RFC4671] allow the gathering
of accounting data.
4.4. Performance Management
MIB modules typically contain counters to determine the frequency and
rate of an occurrence.
RMON [RFC2819] has the full standard status [STD59] and defines
objects for managing remote network monitoring devices. An
organization may employ many remote management probes, one per
network segment, to manage its internet. These devices may be used
for a network management service provider to access a client network,
often geographically remote. Most of the objects in the RMON MIB
module are suitable for the management of any type of network, where
some of them are specific to management of Ethernet networks.
RMON allows a probe to be configured to perform diagnostics and to
collect statistics continuously, even when communication with the
management station may not be possible or efficient. The alarm group
periodically takes statistical samples from variables in the probe
and compares them to previously configured thresholds. If the
Ersue Expires May 31, 2011 [Page 34]
Internet-Draft IETF Management Framework November 2010
monitored variable crosses a threshold, an event is generated.
The RMON host group discovers hosts on the network by keeping a list
of source and destination MAC Addresses seen in good packets
promiscuously received from the network, and contains statistics
associated with each host. The hostTopN group is used to prepare
reports that describe the hosts that top a list ordered by one of
their statistics. The available statistics are samples of one of
their base statistics over an interval specified by the management
station. Thus, these statistics are rate based. The management
station also selects how many such hosts are reported.
The RMON matrix group stores statistics for conversations between
sets of two addresses. The filter group allows packets to be matched
by a filter equation. These matched packets form a data stream that
may be captured or may generate events. The Packet Capture group
allows packets to be captured after they flow through a channel. The
event group controls the generation and notification of events from
this device.
Draft standards:
The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up
to the application layer. The SMON MIB [RFC2613] extends RMON by
providing RMON analysis for switched networks.
Proposed standards:
RMON MIB Extensions for High Capacity Alarms [RFC3434] describes
managed objects for extending the alarm thresholding capabilities
found in the RMON MIB and provides similar threshold monitoring of
objects based on the Counter64 data type.
RMON MIB Extensions for High Capacity Networks [RFC3273] defines
objects for managing RMON devices for use on high-speed networks.
RMON MIB Extensions for Interface Parameters Monitoring [RFC3144]
describes an extension to the RMON MIB with a method of sorting the
interfaces of a monitored device according to values of parameters
specific to this interface.
[RFC4710] describes Real-Time Application Quality of Service
Monitoring. RAQMON is part of the RMON protocol family, and supports
end-2-end QoS monitoring for multiple concurrent applications and
does not relate to a specific application transport. RAQMON is
scalable and works well with encrypted payload and signaling. RAQMON
uses TCP to transport RAQMON PDUs.
Ersue Expires May 31, 2011 [Page 35]
Internet-Draft IETF Management Framework November 2010
[RFC4711] proposes an extension to the Remote Monitoring MIB
[RFC2819] and describes managed objects used for real-time
application Quality of Service (QoS) monitoring. [RFC4712] specifies
two transport mappings for the RAQMON information model using TCP as
a native transport and SNMP to carry the RAQMON information from a
RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
Application Performance Measurement MIB [RFC3729] uses the
architecture created in the RMON MIB and defines objects by providing
measurement and analysis of the application performance as
experienced by end-users. Application performance measurement
measures the quality of service delivered to end-users by
applications.
Transport Performance Metrics MIB [RFC4150] describes managed objects
used for monitoring selectable performance metrics and statistics
derived from the monitoring of network packets and sub-application
level transactions. The metrics can be defined through reference to
existing IETF, ITU, and other standards organizations' documents.
IPPM working group defined an Information Model and XML Data Model
for Traceroute Measurements [RFC5388], which defines a common
information model dividing the information elements into two
semantically separated groups (configuration elements and results
elements) with an additional element to relate configuration elements
and results elements by means of a common unique identifier. Based
on the information model, an XML data model is provided to store the
results of traceroute measurements.
IPPM working group has furthermore defined [BCP108] "IP Performance
Metrics (IPPM) Metrics Registry", which defines a registry for IP
Performance Metrics [RFC4148]. The IANA-assigned registry contains
an initial set of OBJECT IDENTITIES to currently defined metrics in
the IETF as well as defines the rules for adding IP Performance
Metrics that are defined in the future.
SIP Package for Voice Quality Reporting [I-D.ietf-sipping-rtcp-
summary] defines a SIP event package that enables the collection and
reporting of metrics that measure the quality for Voice over Internet
Protocol (VoIP) sessions.
Traffic Flow Measurement: Meter MIB [RFC2720] defines a MIB for use
in controlling an RTFM Traffic Meter, in particular for specifying
the flows to be measured and provides a mechanism for retrieving flow
data from the meter using SNMP.
Ersue Expires May 31, 2011 [Page 36]
Internet-Draft IETF Management Framework November 2010
4.5. Security Management
Proposed standards:
RADIUS Authentication Server MIB for IPv6 [RFC4669] defines a set of
extensions that instrument RADIUS authentication server functions and
RADIUS Authentication Client MIB for IPv6 [RFC4668] defines a set of
extensions for RADIUS authentication client functions. Both RFCs add
support for version-neutral IP address formats. Using these
extensions, IP-based management stations can manage RADIUS
authentication clients and servers.
Following are RADIUS MIBs published as Informational RFC:
o RADIUS Dynamic Authorization Client MIB [RFC4672] describes the
Dynamic Authorization Client (DAC) functions that support the
dynamic authorization extensions defined in [RFC5176].
o RADIUS Dynamic Authorization Server MIB [RFC4673] describes the
Dynamic Authorization Server (DAS) functions that support the
dynamic authorization extensions defined in [RFC5176].
5. IANA Considerations
This document does not introduce any new codepoints or name spaces
for registration with IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document introduces no new security concerns.
7. Contributors
This document uses the expired draft [I-D.ietf-opsawg-survey-
management] edited by Dave Harrington as a starting point.
8. Acknowledgements
The authors would like to thank to ...
9. Informative References
[3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage
2", September 2010,
<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
Ersue Expires May 31, 2011 [Page 37]
Internet-Draft IETF Management Framework November 2010
[BCP108] Emile, S., "IP Performance Metrics (IPPM) Metrics
Registry", August 2005.
[BCP27] D. O'Dell, M., "Advancement of MIB specifications on the
IETF Standards Track", October 1998.
[BCP74] Frye, R., "Coexistence between Version 1, Version 2, and
Version 3 of the Internet-standard Network Management
Framework", August 2003.
[ITU-M3100] International Telecommunication Union, "M.3100: Generic
network information model", January 2006,
<http://www.itu.int/rec/T-REC-M.3100-200504-I>.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and
S. Waldbusser, "Introduction to Community-based SNMPv2",
RFC 1901, January 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner,
"Advancement of MIB specifications on the IETF Standards
Track", BCP 27, RFC 2438, October 1998.
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service
Location Protocol", RFC 2610, June 1999.
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S.
Waldbusser, "Remote Network Monitoring MIB Extensions
for Switched Networks Version 1.0", RFC 2613, June 1999.
Ersue Expires May 31, 2011 [Page 38]
Internet-Draft IETF Management Framework November 2010
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2720, October 1999.
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
"Agent Extensibility (AgentX) Protocol Version 1",
RFC 2741, January 2000.
[RFC2742] Heintz, L., Gudur, S., and M. Ellison, "Definitions of
Managed Objects for Extensible SNMP Agents", RFC 2742,
January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control", RFC 2753,
January 2000.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000.
[RFC2982] Kavasseri, R., "Distributed Management Expression MIB",
RFC 2982, October 2000.
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014,
Ersue Expires May 31, 2011 [Page 39]
Internet-Draft IETF Management Framework November 2010
November 2000.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, March 2001.
[RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for
Interface Parameters Monitoring", RFC 3144, August 2001.
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure
of Policy Provisioning Information (SPPI)", RFC 3159,
August 2001.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed
Objects for the Delegation of Management Scripts",
RFC 3165, August 2001.
[RFC3273] Waldbusser, S., "Remote Network Monitoring Management
Information Base for High Capacity Networks", RFC 3273,
July 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation
Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)",
RFC 3393, November 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62,
Ersue Expires May 31, 2011 [Page 40]
Internet-Draft IETF Management Framework November 2010
RFC 3411, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62,
RFC 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
Over Transmission Control Protocol Transport Mapping",
RFC 3430, December 2002.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity
Sensor Management Information Base", RFC 3433,
December 2002.
[RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB
Extensions for High Capacity Alarms", RFC 3434,
December 2002.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference
between Information Models and Data Models", RFC 3444,
January 2003.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting (AAA) Transport Profile", RFC 3539,
June 2003.
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
RFC 3574, August 2003.
Ersue Expires May 31, 2011 [Page 41]
Internet-Draft IETF Management Framework November 2010
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3729] Waldbusser, S., "Application Performance Measurement
MIB", RFC 3729, March 2004.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, September 2004.
[RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting
Control Management Information Base (MIB)", RFC 3878,
September 2004.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
J. Loughney, "Diameter Credit-Control Application",
RFC 4006, August 2005.
[RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy
Based Management MIB", RFC 4011, March 2005.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6
into ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
Ersue Expires May 31, 2011 [Page 42]
Internet-Draft IETF Management Framework November 2010
RFC 4038, March 2005.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios",
RFC 4057, June 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture
Taxonomy for Control and Provisioning of Wireless Access
Points (CAPWAP)", RFC 4118, June 2005.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics
MIB", RFC 4150, August 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB",
RFC 4268, November 2005.
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
Configuration Protocol (DHCP) Options for Broadcast and
Multicast Control Servers", RFC 4280, November 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, May 2006.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L.
Yang, "Objectives for Control and Provisioning of
Ersue Expires May 31, 2011 [Page 43]
Internet-Draft IETF Management Framework November 2010
Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
M. Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6",
RFC 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
RFC 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6",
RFC 4670, August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6",
RFC 4671, August 2006.
[RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
Dynamic Authorization Client MIB", RFC 4672,
September 2006.
[RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
Dynamic Authorization Server MIB", RFC 4673,
September 2006.
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
Attributes for Virtual LAN and Priority Support",
RFC 4675, September 2006.
[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-
time Application Quality-of-Service Monitoring (RAQMON)
Framework", RFC 4710, October 2006.
[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-
time Application Quality-of-Service Monitoring (RAQMON)
MIB", RFC 4711, October 2006.
[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M.,
and Y. Kim, "Transport Mappings for Real-time
Application Quality-of-Service Monitoring (RAQMON)
Protocol Data Unit (PDU)", RFC 4712, October 2006.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics",
RFC 4737, November 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Ersue Expires May 31, 2011 [Page 44]
Internet-Draft IETF Management Framework November 2010
Canales-Valenzuela, C., and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application", RFC 4740,
November 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)",
RFC 4742, December 2006.
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object
Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol
over the Blocks Extensible Exchange Protocol (BEEP)",
RFC 4744, December 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825,
May 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D.,
and W. Beck, "RADIUS Extension for Digest
Authentication", RFC 5090, February 2008.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information
Export", RFC 5102, January 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
Deployment Scenarios in 802.16 Networks", RFC 5181,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Ersue Expires May 31, 2011 [Page 45]
Internet-Draft IETF Management Framework November 2010
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol
(TWAMP)", RFC 5357, October 2008.
[RFC5381] Iijima, T., Atarashi, Y., Kimura, H., Kitani, M., and H.
Okita, "Experience of Implementing NETCONF over SOAP",
RFC 5381, October 2008.
[RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T.,
and M. Swany, "Information Model and XML Data Model for
Traceroute Measurements", RFC 5388, December 2008.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control
and Provisioning of Wireless Access Points (CAPWAP)
Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over
UDP", RFC 5426, March 2009.
[RFC5427] Keeni, G., "Textual Conventions for Syslog Management",
RFC 5427, March 2009.
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins,
C., and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
RFC 5447, February 2009.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, March 2009.
[RFC5516] Jones, M. and L. Morand, "Diameter Command Code
Registration for the Third Generation Partnership
Project (3GPP) Evolved Packet System (EPS)", RFC 5516,
April 2009.
Ersue Expires May 31, 2011 [Page 46]
Internet-Draft IETF Management Framework November 2010
[RFC5539] Badra, M., "NETCONF over Transport Layer Security
(TLS)", RFC 5539, May 2009.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
RFC 5560, May 2009.
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and
Diameter", RFC 5580, August 2009.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport
Subsystem for the Simple Network Management Protocol
(SNMP)", RFC 5590, June 2009.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security
Model for the Simple Network Management Protocol
(SNMP)", RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[RFC5608] Narayan, K. and D. Nelson, "Remote Authentication
Dial-In User Service (RADIUS) Usage for Simple Network
Management Protocol (SNMP) Transport Models", RFC 5608,
August 2009.
[RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog",
RFC 5674, October 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple
Network Management Protocol (SNMP) Notifications to
SYSLOG Messages", RFC 5675, October 2009.
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP)
Notifications", RFC 5676, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations
and Management of New Protocols and Protocol
Extensions", RFC 5706, November 2009.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder,
"Security Threats and Security Requirements for the
Access Node Control Protocol (ANCP)", RFC 5713,
January 2010.
Ersue Expires May 31, 2011 [Page 47]
Internet-Draft IETF Management Framework November 2010
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote
Procedure Call (RPC) for NETCONF", RFC 5717,
December 2009.
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou,
"Clarifications on the Routing of Diameter Requests
Based on the Username and the Realm", RFC 5729,
December 2009.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol
(EPP)", STD 69, RFC 5730, August 2009.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones,
M., and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777,
February 2010.
[RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang,
"Control and Provisioning of Wireless Access Points
(CAPWAP) Protocol Base MIB", RFC 5833, May 2010.
[RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang,
"Control and Provisioning of Wireless Access Points
(CAPWAP) Protocol Binding MIB for IEEE 802.11",
RFC 5834, May 2010.
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010.
[RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog
Messages", RFC 5848, May 2010.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria,
A., and G. Zorn, "Diameter Quality-of-Service
Application", RFC 5866, May 2010.
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
Hoc Networks", RFC 5889, September 2010.
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol
(SNMP)", RFC 5953, August 2010.
Ersue Expires May 31, 2011 [Page 48]
Internet-Draft IETF Management Framework November 2010
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
"Datagram Transport Layer Security (DTLS) Transport
Mapping for Syslog", RFC 6012, October 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010.
[RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF
Monitoring", RFC 6022, October 2010.
[RFCSEARCH] IETF, "RFC Index Search Engine", January 2006,
<http://www.rfc-editor.org/rfcsearch.html>.
[STD59] Waldbusser, S., "Remote Network Monitoring Management
Information Base", May 2000.
[STD62] Harrington, D., "An Architecture for Describing Simple
Network Management Protocol (SNMP) Management
Frameworks", December 2002.
[STD69] Hollenbeck, S., "Extensible Provisioning Protocol
(EPP)", August 2009.
Appendix A. New Work related to IETF Management Framework
A.1. Energy Management (eman)
Energy management (eman) is a new working group at IETF and will
develop an energy management framework and standard track MIB
documents, which are potentially relevant for the Smart Grid
environment.
Energy management is already an additional requirement for network
management systems due to several factors including the rising energy
costs, the increased awareness of the ecological impact of operating
networks and devices, and the regulation of governments. The basic
objective of energy management is operating communication networks
and other equipments with a minimal amount of energy while still
providing sufficient performance to meet service level objectives.
There are very few IETF documents on energy management discussing the
areas of power monitoring, energy monitoring, and power state
control. IETF started working on MIB modules for monitoring energy
consumption and power states of energy-aware devices. However, it
Ersue Expires May 31, 2011 [Page 49]
Internet-Draft IETF Management Framework November 2010
has been found that a new framework for energy management is
necessary to address known issues sufficiently.
A concrete issue, which needs to be addressed, is the differentiation
between devices reporting energy consumption and remote devices for
which monitoring information is provided. One usage scenario is
power state control of remote devices, for example, at a PoE sourcing
device that switches on and off power at its ports. Another example
scenario for energy management is a gateway to low resourced and
lossy network devices in a wireless building network.
The EMAN working group will work on the management of energy-aware
devices covering following standard track working group items:
Energy-aware Networks and Devices MIB document:
Focus on monitoring energy-aware networks and devices addressing
device identification, context information, and potential
relationship between reporting devices, remote devices, and
monitoring probes.
Power and Energy Monitoring MIB document:
Managed objects for monitoring of power states and energy
consumption/production including retrieving of power states,
properties of power states, current power state, power state
transitions, and power state statistics.
Battery MIB document:
Managed objects for battery monitoring, which will provide means
for reporting detailed properties of the actual charge, age, and
state of a battery and of battery statistics.
The working group will furthermore provide following RFCs as a
guidance for the development of standard track documents:
Requirements for energy management:
Specification of energy management properties that will allow
networks and devices to become energy aware.
Energy management framework:
Extensions to current management framework required for energy
management of IP-based network equipment including power and
energy monitoring, power states, power state control, and
potential power state transitions.
Applicability statement:
Description of applications that can use the energy framework and
associated MIB modules and the discussion of relationships of the
framework to other frameworks like Smart Grid and existing
Ersue Expires May 31, 2011 [Page 50]
Internet-Draft IETF Management Framework November 2010
standards such as those from the IEC, ANSI, DMTF, and others.
NOTE: We need Eman use cases.
Appendix B. Open issues
o Some chapters need additional discussion of standard documents in
this area. Usage scenarios can be added and discussed for
different RFCs.
o Is Experimental RFC3179 "Script MIB Extensibility Protocol" worth
to discuss?
o Management of constrained devices needs a discussion. New work is
available e.g. for optimized SNMP in 6LowPAN environment
(draft-hamid-6lowpan-snmp-optimizations). Discuss the potential
gap for an optimized NETCONF for constrained devices.
Author's Address
Mehmet Ersue
Nokia Siemens Networks
St.-Martin-Strasse 53
Munich 81541
Germany
EMail: mehmet.ersue@nsn.com
Ersue Expires May 31, 2011 [Page 51]
| PAFTECH AB 2003-2026 | 2026-04-23 11:41:31 |