internet management: status and challenges · internet management: status and challenges ......

Internet Management: Status and Challenges

2004 IEEE/IFIP Network Operations & Management Symposium

Seoul, Korea, 2004-04-19

Aiko Pras

[email protected] of Twente7500 AE Enschede

The Netherlands

Jurgen Schonwalder

[email protected] University Bremen

28759 BremenGermany

mailto:[email protected]

mailto:[email protected]

Copyright Notice

Copyright c© 2004 Jurgen Schonwalder, Bremen, Germany

Copyright c© 2004 Aiko Pras, Enschede, The Netherlands

All rights reserved.

No part of these sheets may be reproduced, stored in a retrievalsystem or transmitted in any form or by any means, without obtain-ing written permission of the author.

Outline of the Tutorial

1. IETF Working Group Overview (Jurgen Schonwalder, 20 min)

2. SNMP Version 3 (SNMPv3) (Aiko Pras, 45 min)

3. SNMP Improvements (Jurgen Schonwalder, 35 min)

4. XML-based Management (Jurgen Schonwalder, 35 min)

5. Web Services for Management (Aiko Pras, 45 min)

1 IETF Working Group Overview

1.1 MIB Review Guidelines

1.2 IPv6 Support and Management

1.3 Entity MIB Evolution

1.4 Distributed Management

1.5 Middlebox Management

1.6 IEEE 802 Management

1.7 ATM / MPLS / xDSL / Cable Modems

1.8 Printer, IP Storage, RMON

1.9 Extensible Provisioning Protocol

1.1 MIB Review Guidelines

• All MIB modules published by the IETF go through a review process.

• There was quite some variation what MIB doctors checked and agreed upon.

• Many discussions were needed to identify the common rules used by theMIB doctors.

• The MIB Review Guidelines draft documents some of the SMI folklore andthe CLRs (crappy little rules or consistency language rules) that are checkedduring MIB review.

• MIB module authors are encouraged to check their MIBs against these rulesbefore publishing them or submitting them to the IESG.

• A subset of the rules that can be automatically checked has been added tothe smilint MIB module checker of the libsmi package.

• Guidelines document is of high quality and relatively stable. Should go tothe IESG sometime during this year.

1.2 IPv6 Support and Management

• MIB modules under revision:

– TCs for Internet Network Addresses (RFC 3291 update)

– IP-MIB (RFC 2011 update)

– IP-FORWARD-MIB (RFC 2096 update)

– TCP-MIB (RFC 2012 update)

– UDP-MIB (RFC 2013 update)

– TUNNEL-MIB (RFC 2667 update)

• Original IPv6 MIB modules published in 1998 will be made historic.

• Documents being finalized, should go to the IESG soon.

1.3 Entity MIB Evolution

• The ENTITY-MIB models physical entities (e.g., fans, sensors, cpus, ports,modules, chassis) that make up a device.

• Represents the containment hierarchy of physical entities

• Very essential MIB module (comparable to the IF-MIB)

• Improvements made during the last months:

– 3rd revision of the ENTITY-MIB (to become Draft Standard)

– ENTITY-SENSOR-MIB extension for sensors (RFC 3433)

– MIB module providing state objects for physical entities

• 3rd version of the ENTITY MIB waiting for publication, state extension beingfinalized.

1.4 Distributed Management

• Recent work was centered around the definition of a general alarm reportingmechanism, based on some of the ITU work in this space (X.733).

• An additional module provides an alarm reporting control interface, againbased on some ITU work in this space (M.3100 Amendment 3).

• Other work items are concerned with the progression of DISMAN MIB mod-ules to Draft Standard.

• Some discussion about the complexity of the event and expression MIBmodules.

• Documents:

– Alarm MIB

– Alarm Reporting Control MIB

– Ping, Traceroute, Lookup MIB (RFC 2925) Revision

• Documents basically ready for submission to the IESG.

1.5 Middlebox Management

• A middlebox is a network intermediate device (NAT, firewall) that needs tobe configured in order to make applications work (“drilling holes into middle-boxes”).

• Working group went through a detailed development process:

– Middlebox Communication Architecture and Framework (RFC 3303)

– Middlebox Communications (MIDCOM) Protocol Requirements (RFC 3304)

– Middlebox Communications (MIDCOM) Protocol Evaluation

– MIDCOM Protocol Semantics

– Middlebox Communications (MIDCOM) Protocol Managed Objects Anal-ysis

– Definitions of Managed Objects for Middlebox Communication

• Most WG members wanted a simple special purpose protocol and they getan SNMP MIB which nobody really wanted. Is this a model for the future?

1.6 IEEE 802 Management

• Most of the IEEE 802 documents are doing in cooperation with the IEEE.

• Newer Documents:

– Power Ethernet MIB (RFC 3621)

– Ethernet-like Interface Types MIB (RFC 3635)

– IEEE 802.3 Medium Attachment Units MIB (RFC 3636)

– Ethernet WAN Interface Sublayer MIB (RFC 3637)

– Port Access Control MIB

– Ethernet in the First Mile (EFM) Common MIB

– Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

– Ethernet Passive Optical Networks MIB

– VLAN Textual Convention MIB

• Discussions about moving MIB development control over to the IEEE withMIB review service provided by the IETF.

1.7 ATM / MPLS / xDSL / Cable Modems

• Several working groups produce a stream of interface type specific MIB mod-ules.


– Optical Interface Type (RFC 3591)

– SONET/SDH MIB Revision (RFC 3592)

– Supplemental Managed Objects for ATM Interface (RFC 3606)

– DS1 / E1 / DS2 / E2 / DS3 / E3 Interface Type MIBs Revision

– Many (perhaps too many?) MIB modules related to MPLS and trafficengineering

– Very High Speed Digital Subscriber Lines (VDSL) MIB (RFC 3728)

– VDSL Extensions for Single Carrier Modulation (SCM) Line Coding

– VDSL Extensions for Multiple Carrier Modulation (MCM) Line Coding

– Many MIB modules related to Cable Modems.

• The MPLS related MIB modules probably need to get consolidated.

1.8 Printer, Fiber Channel, iSCSI, Remote Monitoring

• Several working groups produce MIB modules related to printers, storagetechnologies and continue the RMON monitoring suite.


– Printer MIB and Finisher MIB (waiting for publication)

– Fiber Channel MIB modules are being revised / extended

– iSCSI MIB modules are currently being defined

– RMON Overview Document (RFC 3577)

– Application Performance Measurement MIB (RFC 3729)

– Transport Performance Metrics MIB

– Synthetic Sources for Performance Monitoring Algorithms MIB

– Real-time Application Quality of Service Monitoring MIBs

1.9 Extensible Provisioning Protocol

• Application layer client-server protocol for the provisioning and managementof objects stored in a shared central repository

• Target application area is automated interaction with registries

• Extensible Provisioning Protocol Features

– XML based protocol (commands / responses)

– Session management commands (login, logout)

– Query commands (check, info, poll, transfer)

– Object transform commands (create, delete, renew, transfer, update)

– Mapping over TCP and BEEP defined (SCTP not detailed)

• Important piece of work done in the Applications Area and largely ignoredby the Operations and Management Area...

SNMPv3

TUTORIAL T4 - PART 2PRESENTED AT NOMS’2004

SEOUL, KOREA19 APRIL 2004

AIKO PRASUNIVERSITY OF TWENTE

THE NETHERLANDS

[email protected]://wwwhome.cs.utwente.nl/~pras

Copyright © 2004 by Aiko PrasThese sheets may be used for educational purposes

SNMPv3

OVERVIEW:

DESIGN DECISIONS

ARCHITECTURE

SNMP MESSAGE STRUCTURE

SECURE COMMUNICATION• USER SECURITY MODEL (USM)

ACCESS CONTROL• VIEW BASED ACCESS CONTROL MODEL (VACM)

RFCs

DESIGN DECISIONS

ADDRESS THE NEED FOR SECURY SET SUPPORT

DEFINE AN ARCHITECTURE THAT ALLOWS FOR LONGEVITY OF SNMP

ALLOW THAT DIFFERENT PORTIONS OF THE ARCHITECTUREMOVE AT DIFFERENT SPEEDS TOWARDS STANDARD STATUS

ALLOW FOR FUTURE EXTENSIONS

KEEP SNMP AS SIMPLE AS POSSIBLE

ALLOW FOR MINIMAL IMPLEMENTATIONS

SUPPORT ALSO THE MORE COMPLEX FEATURES,WHICH ARE REQUIRED IN LARGE NETWORKS

RE-USE EXISTING SPECIFICATIONS, WHENEVER POSSIBLE

SNMPv3 ARCHITECTURE

OTHERNOTIFICATIONORIGINATOR

COMMANDRESPONDER

COMMANDGENERATOR

NOTIFICATIONRECEIVER

PROXYFORWARDER

SNMP APPLICATIONS

SNMP ENGINE

MESSAGE PROCESSINGSUBSYSTEMDISPATCHER

SECURITYSUBSYSTEM

ACCESS CONTROLSUBSYSTEM

SNMP ENTITY

OTHER

SNMPv3 ARCHITECTURE: MANAGER

NOTIFICATIONRECEIVER

COMMANDGENERATOR

PDUDISPATCHER

COMMUNITY BASEDSECURITY MODEL

USER BASEDSECURITY MODEL

OTHERSECURITY MODEL

SECURITY SUBSYSTEM

SNMPv1

SNMPv2C

SNMPv3

OTHER

MESSAGE PROCESSINGSUBSYSTEM

MESSAGEDISPATCHER

TRANSPORTMAPPINGS

SNMPv3 ARCHITECTURE: AGENT

PDUDISPATCHER

COMMUNITY BASEDSECURITY MODEL

USER BASEDSECURITY MODEL

OTHERSECURITY MODEL

SECURITY SUBSYSTEM

SNMPv1

SNMPv2C

SNMPv3

OTHER

MESSAGE PROCESSINGSUBSYSTEM

MESSAGEDISPATCHER

TRANSPORTMAPPINGS

MANAGEMENT INFORMATION BASE

VIEW BASEDACCESS CONTROL

ACCESS CONTROL SUBSYSTEM

NOTIFICATIONORIGINATOR

COMMANDRESPONDER

CONCEPTS: snmpEngineID

OTHER

SNMP ENGINE

SNMP ENTITY

snmpEngineID=4

OTHER

SNMP ENGINE

SNMP ENTITY

snmpEngineID=2

OTHER

SNMP ENGINE

SNMP ENTITY

snmpEngineID=3

OTHER

SNMP ENGINE

SNMP ENTITY

snmpEngineID=1


SYNTAX DEFINED VIA TEXTUAL CONVENTION

OCTET STRING (5..32)

THE VALUE OF snmpEngineID MAY BE DETERMINED BY:• HUMAN OPERATOR

• AUTOMATIC ALGORITHM

AUTOMATIC ALGORITHM USES:• PRIVATE ENTERPRISE NUMBER

• IPv4 ADDRESS / IPv6 ADDRESS / MAC ADDRESS

TEXTUAL CONVENTION DEFINED IN SNMP FRAMEWORK MIB


THE TERM EngineID IS FREQUENTLY USED

SnmpEngineID The textual convention.

snmpEngineID The identifier of an SNMP engine.

securityEngineID Parameter of primitives in the architecture. The authoritative SNMP entity(which is the receiver of a confirmed PDU, the sender of a trap).

contextEngineID Parameter in messages. Identifies the engine associated with the data.

msgAuthoritativeEngineID Parameter in messages. USM security parameter.

usmUserEngineID

An object in the snmpUsmMIB.In a simple agent, this is the agent’s own snmpEngineID. It may also be the snmpEngineID of a remote SNMP engine with which this user can communi-cate.

usmStatsUnknownEngineID An object in the snmpUsmMIB.

snmpCommunityContextEngineID An object in the communityMIB.

entLogicalContextEngineID An object in the entityMIB.

snmpProxyContextEngineID An object in the proxyMIB.

CONCEPTS: Context

OTHER

COMMAND RESPONDER APPLICATION

SNMP ENGINE

SNMP ENTITY

snmpEngineID=1

contextEngineID=1The context can be reached from this engine, thus:

MIB

contextName=card1

MIB

contextName=card2

MODULES OF THE SNMPv3 ARCHITECTURE

DISPATCHER AND MESSAGE PROCESSING MODULE• SNMPv3 MESSAGE STRUCTURE

• snmpMPDMIB• RFC 3412

APPLICATIONS• snmpTargetMIB

• snmpNotificationMIB• snmpProxyMIB

• RFC 3413

SECURITY SUBSYSTEM• USER BASED SECURITY MODEL

• snmpUsmMIB• RFC 3414

ACCESS CONTROL SUBSYSTEM• VIEW BASED ACCESS CONTROL MODEL

• snmpVacmMIB• RFC 3415

SNMPv3 MESSAGE STRUCTURE

msgVersionmsgID

msgMaxSizemsgFlags

msgSecurityModel

msgSecurityParameters

contextEngineIDcontextName

PDU

USED BY MESSAGE PROCESSING SUBSYSTEM

USED BY SNMPv3 PROCESSING MODULE

USED BY SECURITY SUBSYSTEM

USED BY ACCESS CONTROL SUBSYSTEMAND APPLICATIONS

SNMPv3 PROCESSING MODULE PARAMETERS

msgVersionmsgID

msgMaxSizemsgFlags

msgSecurityModel

msgSecurityParameters

contextEngineIDcontextName

PDU

authFlagprivFlagreportableFlag

SNMPv1SNMPv2cUSM

484..2147483647

0..2147483647

SECURE COMMUNICATION VERSUS ACCESS CONTROL

MIB

MANAGER

APPLICATION PROCESSES

TRANSPORT SERVICE

MANAGER AGENT

GET / GET-NEXT / GETBULKSET / TRAP / INFORM

SECURE COMMUNICATION

ACCESS CONTROL

USM: SECURITY THREATS

THREAT ADDRESSED? MECHANISM

REPLAY YES TIME STAMP

MASQUERADE YES MD5 / SHA-1

INTEGRITY YES (MD5 / SHA-1)

DISCLOSURE YES DES

DENIAL OF SERVICE NO

TRAFFIC ANALYSIS NO

USM MESSAGE STRUCTURE

msgVersionmsgID

msgMaxSizemsgFlags

msgSecurityModelmsgAuthoritativeEngineID

msgAuthoritativeEngineBootsmsgAuthoritativeEngineTime

msgUserNamemsgAuthenticationParameters

msgPrivacyParameterscontextEngineID

contextName

PDU

REPLAY

MASQUERADE/INTEGRITY/DISCLOSURE

DISCLOSURE

MASQUERADE/INTEGRITY

IDEA BEHIND REPLAY PROTECTION

LOCAL NOTION OFREMOTE CLOCK

ALLOWEDLIFETIME

LOCALCLOCK

+ >?

ID BOOTS TIME DATA ID BOOTS TIME DATA

Authoritative EngineNonauthoritative Engine

IDEA BEHIND DATA INTEGRITY AND AUTHENTICATION

HASH FUNCTION

DATAKEY

MAC

ADD THE MESSAGE AUTHENTICATION CODE (MAC) TO THE DATAAND SEND THE RESULT

IDEA BEHIND AUTHENTICATION

HASH FUNCTION

KEY

MAC

DATAUSER MAC

DATA

HASH FUNCTION

KEY

MAC

DATAUSER MAC

DATA

=?

IDEA BEHIND THE DATA CONFIDENTIALITY (DES)

DES ALGORITHM

DATADES-KEY

ENCRYPTED DATA

IDEA BEHIND ENCRYPTION

DES ALGORITHM

DATADES-KEY

ENCRYPTED DATA

ENCRYPTED DATAUSER

DES ALGORITHM

DATADES-KEY

ENCRYPTED DATA

ENCRYPTED DATAUSER

VIEW BASED ACCESS CONTROL MODEL

ACCESS CONTROL TABLE

MIB VIEWS

ACCESS CONTROL TABLES

GET / GETNEXTInterface Table John, Paul Authentication

•••••• ••• •••

•••••• ••• •••

SETInterface Table JohnAuthentication

GET / GETNEXTSystems Group George None

•••••• ••• •••

•••••• ••• •••

Encryption

MIB VIEWALLOWED

MANAGERSREQUIRED LEVEL

OF SECURITYALLOWED

OPERATIONS

MIB VIEWS

SNMPv3 RFCs

OTHER

SNMP APPLICATIONS

SNMP ENGINE

MESSAGE PROCESSINGSUBSYSTEMDISPATCHER

SECURITYSUBSYSTEM

ACCESS CONTROLSUBSYSTEM

SNMP ENTITY

RFC 3413

RFC 3411

RFC 3412 RFC 3412 USM: RFC 3414 VACM: RFC 3415

3 SNMP Improvements

3.1 Next Generation Structure of Management Information (SMIng)

3.2 SNMP over TCP

3.3 SNMP Payload Compression

3.4 Extended SNMP Protocol Operations

3.5 AES Cipher Algorithm for USM

3.6 SNMP Uniform Resource Locators

3.7 Session-Based SNMP Security Model

3.1 Next Generation Structure of Management Information

• Problems:

– SMIv2 misses some important base types such as 64 bit numbers.

– SMIv2 lacks reusable composite data types.

– SMIv2 syntax depends on ASN.1 and is generally not well understoodand implemented correctly.

– SMIv2 parsers are difficult to write due to a lack of a well defined gram-mar.

– SMIv2 is not extensible.

– Desirable to use the same data definitions with SNMP and COPS-PR.

• Solution:

– A next generation data modeling language called SMI (SMIng).

– Detailed objectives have been documented in RFC 3216.

– Soon to be published as Experimental RFCs.

SMIng Module Structure

SMIng type and class definitions

SNMP protocol mapping

COPS−PR protocol mapping

protocol independent

no instance naming

protocol dependent

instance naming

SMIng module

• Reusable type and class definitions are seperated from protocol specificmappings.

• Abstraction of instance naming is the most difficult problem to solve.

SMIng Syntax

• Programmer friendly syntax:

– look and feel similar to Java, C, C++, ...– consistent structure of statements (easier to memorize)

• Easy to implement and efficient to parse:

– consistent syntactic structure simplifies grammar– no forward references (except in cases where they are unavoidable)– statement seperators help to recover from parse errors– complete grammar specified in ABNF (RFC 2234)

• Language extensibility:

– declaration of new statements, parsers skip unknown statements

=⇒ Not everyone in the IETF agrees that the ASN.1 syntax is ugly...

SMIng Base Types and Core Derived Types

(includes SM

Iv2 base types)

SM

Ing base types

(includes some S

MIv2 textual conventions)

Integer64

ObjectIdentifier

Bits

OctetS

tring

Float128

Float64

Float32

Unsigned64

Integer32

Enum

eration

TimeS

tamp32

Unsigned32

Counter32

Gauge32

TimeTicks32

Gauge64

Counter64

DisplayS

tring

DateA

ndTime

DisplayS

tring255

IpAddress

Opaque

MacA

ddress

PhysA

ddress

Utf8S

tringU

tf8String255

TimeTicks64

TimeS

tamp64

TruthValue

TimeInterval64

TimeInterval32

Pointer

SM

Ing derived types

SMIng Attributes and Classes

• Classes encapsulate a set of attributes.

• Attributes have an associated type which can be

– a base type, or– a derived type, or– a class (composite type).

• Classes can have associated events.

• Every event in SMIng is associated with a class.

• Events can be mapped to notification messages in protocol mappings.

• Methods are not supported, but might be added in the future.

SNMP Protocol Mapping

• Defines how SMIng base data types are mapped to SNMP data types.

• Uses Opaque wrapping to support new base types.

• Complex composite types are flattened and mapped to table rows or groupsof scalars.

• OID names are assigned in mapping statements.

• SNMP specific derived types (e.g. RowStatus) are defined in a mappingmodule.

SMIng Example

class BasicInOutErrStats {attribute inOctets { type Counter32; ... };attribute inErrors { type Counter32; ... };attribute outOctets { type Counter32; ... };attribute outErrors { type Counter32; ... };...

};

class Interface {attribute index { type InterfaceIndex; ... };attribute stats { type BasicInOutErrStats; ... };...

};

snmp {table ifTable {

oid interfaces.2;index (ifIndex);object ifIndex { implements Interface.index; ... };object ifInOctets { implements Interface.stats.inOctets; ... };object ifInErrors { implements Interface.stats.inErrors; ... };object ifOutOctets { implements Interface.stats.outOctets; ... };object ifOutErrors { implements Interface.stats.outErrors; ... };...

};...

};

3.2 SNMP over TCP (RFC 3430)

• Motivation:

– Support larger message sizes to improve bulk transfers.

– Support session-based security mechanisms.

– No vehicle to turn unconfirmed operations into confirmed operations.

• Specification:

– Optional transport mapping (UDP still has to be available).

– Originator of a request-response transaction chooses the transport pro-tocol for the entire transaction.

– Framing relies on ASN.1/BER message length information.

– Implementations must provide buffers to reassemble fragmented mes-sages.

– Piggybacking of TCP ACKs important!

3.3 SNMP Payload Compression

• Motivation:

– Lossless compression of SNMP payloads with minimal processing over-head.

– Improve encoding efficiency to ship more data in SNMP messages.

• Requirements:

– Compression must happen before encryption.

– Each SNMP message is compressed and decompressed by itself withoutany relation to other SNMP messages (”stateless compression”).

– The size of a compressed SNMP message must never exceed the sizeof the uncompressed SNMP message (”non-expansion policy”).

– The abstract syntax of compressed SNMP messages must be definedusing ASN.1 to ensure that compressed SNMP messages have a validASN.1/BER encoding.

– SNMP payload compression should be able to support multiple compres-sion algorithms. It is desirable to define common compression algorithmsin order to achieve interoperability.

OID Delta Compression (ODC)

• Reduce the OID overhead inherent in SNMP messages by encoding OIDsof variable names as deltas to the previous OID

• The deltas are expressed by a combination of the following primitives:

1. Substitution of a single sub-identifier at a certain position2. Substitution of ranges of sub-identifiers at a given start position3. Truncation and enlargement of the OID

• Algorithm:

1. Loop through the SNMP PDU until you find an OID name value pair(varbind).

2. If it is the first varbind, make a copy of the OID, pass it to the output bufferand continue with the next varbind.

3. Otherwise, compute the delta to the last OID and BER encode it into theCompOID value.

4. If the CompOID representation is larger than the OID, pass the OID to theoutput buffer, else pass the CompOID to the output buffer.

5. Update the last OID and goto step two if there are additional varbinds.

3.4 Extended SNMP Protocol Operations

• Additional protocol operations can substantially improve SNMP’s capabili-ties:

– GetConfig and SetConfig to read and write configuration settings.

– CallRequest and CallResponse to invoke operations.

– GetTable to retrieve complete tables with filtering and OID suppression.

– Create and Delete to address the complexity of the RowStatus mech-anism.

– Object-oriented PDUs with transaction support.

=⇒ There is no agreement which primitives are needed in which order and com-plexity.

3.5 AES Cipher Algorithm for USM

• Problem:

– The SNMP USM security model uses the DES cipher algorithm which isnot considered very secure these days.

– The Advanced Encryption Standard (AES) is widely accepted as a strongerreplacement for DES

• AES Cipher Algorithm for the USM:

– AES in Cipher Feedback Mode (CFB) with a key size of 128 bits.– Defines AES key localization and creation of the 128 bit initialization vec-

tor (IV) from the localized key.

=⇒ Internet Draft in RFC publication queue.

=⇒ Implementations available.

3.6 SNMP Uniform Resource Locators• Problem:

– No common mechanism to indicate how to contact the device for man-agement.

– Especially important when out-of-band IP management is used via a sep-arate management interface

• SNMP Uniform Resource Locators

– Use URL notation to identify SNMPv3 management communication end-points.

– Transport protocol selection (UDP vs. TCP) is implicit.– Examples:

snmp://snmp.example.comsnmp://[email protected]:8161snmp://snmp.example.com/bridge1snmp://snmp.example.com/bridge1;engine=0x800002b804616263

snmp://snmp.example.com//1.3.6.1.2.1.1.3.0snmp://snmp.example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*

=⇒ Internet Draft under active revision.

=⇒ Implementations available (fibre channel MIBs, scli )

3.7 Session-Based SNMP Security Model

• Problem:

– The SNMP USM security model and VACM access control model are self-contained (following the original SNMP design goals) and do not integratewell into deployed authentication/authorization infrastructures.

– Operators prefer to keep the number of authentication/authorization sys-tems that must be managed to a minimum.

• Session-based security model (SSM):

– Uses established security protocols, such as TLS/SSL or SSH.– SSM binds session to a connection, requiring SNMP over TCP.– Must map security protocol parameters into the SNMP parameters securityName

and securityLevel .– Improved efficiency compared to USM under normal network conditions

due to shared state about the security session.– Authentication should integrate with technologies such as Radius or SASL.

=⇒ Details still need to be worked out - no working group yet.

4 XML-based Management

4.1 XML Technologies Overview

4.2 NetConf Proposal based on JunoScript

4.3 NetConf Proposal using Web Services

4.4 SMI Translations and SNMP Gateways

4.1 XML Technologies OverviewXML The eXtensible Markup Language is a standard markup language that al-

lows application s to exchange structured documents.

XSD The XML Schema Definition language offers facilities for describing the struc-ture and constraining the contents of XML documents.

XSL The eXtensible Stylesheet Language is a family of recommendations fordefining XML document transformation and presentation.

XSLT The eXtensible Stylesheet Language Transformations is a language for trans-forming XML documents into other XML documents.

XPATH The XML Path Language is a language for addressing parts of an XML doc-ument.

XQUERY The XML Query Language is a query langauge to extract data from XMLdocuments.

SOAP The Simple Object Access Protocol is for exchanging XML encoded mes-sages.

WSDL Web Services Description Language is a language to describe the behaviorof collections of XML encoded messages.

DOM The Document Object Model is a way to represent XML documents in mem-ory.

SAX SAX is an event-driven API to parse and access XML documents.

Network-Wide Configuration Management Model

Network−WideConfiguration

Database

TranslatorConfiguration Data

Network TopologyInformation

Network Status andPerformance Information

Service ManagementSystems

Policy ManagementSystems

Dev

ice

Con

figur

atio

n

Dev

ice

Con

figur

atio

n

Dev

ice

Con

figur

atio

n

Dev

ice

Con

figur

atio

n

Dev

ice

Con

figur

atio

n

=⇒ Treating configurations as documents leads naturally to the application ofXML.

4.2 NetConf Proposal based on JunoScript

XMLparser

managementdaemon

renderingCLI

XML

Instrumentation

• Juniper Networks developed JunoScript as a programmatic interface to (andwithin) their router products.

• JunoScript uses XML for data representation and the protocol messages.

• The Juniper command line interface is based internally on JunoScript.

• JunoScript is a simple RPC protocol running of Telnet or SSH.

• JunoScript provides the primitives to build robust network-wide configurationmanagement systems (timed confirmed commits).

Example JunoScript RPC Interaction

<rpc><get-interface-information>

<statistics/></get-interface-information>

</rpc>

<rpc-reply><interface-information>

<InOctets>123456</InOctets><InErrors>789</InErrors><OutOctets>654321</OutOctets><OutErrors>0</OutErrors>

</interface-information></rpc-reply>

• All RPC interactions over a single connection form together a single XMLdocument.

• Filtering is based on simple subtree selection.

NetConf Layering Model

Content

Operations

RPC

Transport

Layer Example

<get−config>, <edit−config>

<rpc>, <rpc−reply>

BEEP, SSH, HTTPS, ...

Configuration Data

• Security has to be provided by the transport layer.

• The operations layer provides the primitives to handle configurations.

• The content layer is currently not subject to standardization.

NetConf Operations (mostly finalized)• get-config(source, filter)

Retrieve all or part of a specified configuration from a given source.

• edit-config(target, options, config)Edit target configuration, merge / replace / delete embedded in config data.

• copy-config(source, target)Create or replace an entire configuration with the contents of the source.

• delete-config(target)Delete a configuration datastore.

• get(filter)Retrieve device state information.

• validate(source)Validate the contents of the specified configuration (capability).

• lock(source)Lock a configuration source.

• unlock(config)Unlock a configuration source.

• commit(confirmed, confirmed-timeout)Commit candidate config as the new current configuration (capability).

NetConf over BEEP Request Example (under discussion)

MSG 1 42 . 24 291Content-Type: text/xml; charset=utf-8<rpc message-id="105" xmlns="http://ietf.org/xmlconf/1.0/base">

<get-config><source>

<running/></source><config xmlns="http://example.com/schema/1.2/config">

<users/></config><format>xml</format>

</get-config></rpc>END

• BEEP (RFC 3080) is a generic application protocol kernel for connection-oriented, asynchronous interactions.

• Supports exchange styles MSG/RPY, MSG/ERR, MSG/ANS, multiple chan-nels, application layer framing and fragmentation.

• Integrates into SASL (RFC 2222) and TLS (RFC 2246) for security.

NetConf over BEEP Request Example (cont.)

RPY 1 42 . 24 705<rpc-reply message-id="105" xmlns="http://ietf.org/xmlconf/1.0/base">

<config xmlns="http://example.com/schema/1.2/config"><users>

<user><name>root</name><type>superuser</type><full-name>Charlie Root</full-name>

</user><user>

<name>fred</name><type>admin</type><full-name>Fred Flintstone</full-name>

</user><user>

<name>barney</name><type>admin</type><full-name>Barney Rubble</full-name>

</user></users>

</config></rpc-reply>END

4.3 NetConf Proposal using Web Services

• Instead of inventing a special purpose RPC protocol, use Web Service stan-dards.

• Pros:

– more developers available– more tools available– better integration with IT infrastructure

• Cons:

– base technology not under control of the IETF– unneeded complexity– interoperability problems (immature technology)– HTTP is not a good match for a generic application protocol kernel

• Ongoing debate in the IETF how to weight the arguments.

NetConf WSDL Definition Example

<?xml version="1.0" encoding="UTF-8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:tns="http://ietf.org/netconf/1.0/soap"xmlns:xb="http://ietf.org/netconf/1.0/base"targetNamespace="http://ietf.org/netconf/1.0/soap"name="http://ietf.org/netconf/1.0/soap">

<import namespace="http://ietf.org/netconf/1.0/base" location="base.xsd"/>

<message name="rpcRequest"><part name="in" element="xb:rpc"/>

</message><message name="rpcResponse">

<part name="out" element="xb:rpc-reply"/></message>

<portType name="rpcPortType"><operation name="rpc">

<input message="tns:rpcRequest"/><output message="tns:rpcResponse"/>

</operation></portType>

NetConf WSDL Definition Example (cont.)

<binding name="rpcBinding" type="tns:rpcPortType"><SOAP:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="rpc">

<SOAP:operation/><input>

<SOAP:body use="literal" namespace="http://ietf.org/netconf/1.0/base"/></input><output>

<SOAP:body use="literal" namespace="http://ietf.org/netconf/1.0/base"/></output>

</operation></binding>

</definitions>

• SOAP binding based on a hypothetical location for the NETCONF schema.

• Warning: This example mapping does not provide security!

NetConf WSDL Service Definition

<?xml version="1.0" encoding="UTF-8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xs="http://ietf.org/netconf/1.0/soap"targetNamespace="urn:myNetconfService"name="myNetconfService.wsdl">

<import namespace="http://ietf.org/netconf/1.0/soap" location="soap.wsdl"/>

<service name="netconf"><port name="rpcPort" binding="xs:rpcBinding">

<SOAP:address location="http://localhost:8080/netconf"/></port>

</service></definitions>

• Service definition based on a hypothetical location for the NETCONF/SOAPWSDL definitions.

NetConf over SOAP/HTTP Example

POST /netconf HTTP/1.0Content-Type: text/xml; charset=utf-8Accept: application/soap+xml, text/*Cache-Control: no-cachePragma: no-cacheSOAPAction: "netconfsession:123"Content-Length: 470

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body><rpc id="101" xmlns="http://ietf.org/netconf/1.0/base">

<get-config><source>

<running/></source><config xmlns="http://example.com/schema/1.2/config">

<users/></config><format>xml</format>

</get-config></rpc>

</soapenv:Body></soapenv:Envelope>

NetConf over SOAP/HTTP Example (cont.)

HTTP/1.0 200 OKContent-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body><rpc-reply id="101" xmlns="http://ietf.org/netconf/1.0/base">

<config xmlns="http://example.com/schema/1.2/config"><users>

<user><name>root</name><type>superuser</type>

</user><user>

<name>fred</name><type>admin</type>

</user><user>

<name>barney</name><type>admin</type>

</user></users>

</config></rpc-reply>

</soapenv:Body></soapenv:Envelope>

NetConf Open Issues

• Transport: SSH (must), BEEP (may), SOAP/HTTP[S]? (may), SCTP? ...

• Filtering: ad-hoc subtree?, XPATH?, XQUERY?, XPATH light?, ...

• Protocol: primitives? locking mandatory? XML usage?

• Modeling: XML Schema?, RELAXng?, SMIng?, ...

• Integration: SNMP?, CLI?, ...

4.4 SMI Translations and SNMP Gateways

defines the structure of

used to define

SMIv2

MIB modules

database ofproprietary

SNMP dataXML document

definitionXML Schema

XML Schema(language)Data Definition Language

Data Model

Instance Data

• No standard format for storing / exchanging instance data in the SNMPworld.

• Automatically translate MIB modules into XML schemas to save investments.

• Such translations should follow the ”XML style” as close as possible.

Multiple ”Contexts” per XML Document

A single document maycontain data

• of multiple engines (agents)

– @ipaddr

– @hostname

– @port

• of multiple per-agent contexts

– @context or

– @community

• of multiple points in time

– @time

<?xml version="1.0"?><snmp-data [...]>

<contextipaddr="134.169.246.1"hostname="ciscobs.rz.tu-bs.de"port="161"community="public"time="2003-03-10T10:31:16Z">

[...context data...]</context>

<context [...]>[...context data...]

</context>

[...]</snmp-data>

No ”deep” Element Nesting

• 1st level element <snmp-data>independent root element(not bound to a specific MIB, agent, or point in time)

• 2nd level elements <context>

• 3rd level elements e.g. <system> , <ifEntry ifIndex="1">

– groups of scalar elements– table rows, identified through index attributes

• 4th level elements e.g. <sysContact> , <ifInOctets>

– scalar elements– columnar elements (also of table augmentations)

• deeper level elementsonly for ”table-in-table” relationships, hence quite rare

=⇒ Note: The element nesting is not based on the OID tree.

Using XML Namespaces to Identify Modules

• Each MIB will be compiled to a separate XML Schema that defines an ac-cording namespace:

<xsd:schematargetNamespace="http://example.com/IF-MIB" [...]>

[...]</xsd:schema>

• Imports from MIB modules are translated to imports of namespaces:

<xsd:schema [...]xmlns:SNMPv2-MIB="http://example.com/SNMPv2-MIB" [...]>

[...]<xsd:import

namespace="http://example.com/SNMPv2-MIB" [...]/>[...]

</xsd:schema>

• Elements can be named uniquely with namespace prefixes:

<IF-MIB:interfaces><IF-MIB:ifNumber>7</IF-MIB:ifNumber>

</IF-MIB:interfaces>

Value Representations and Schema Definitions

• numeric values

XML: display hints applied, represented in decimal digitsSchema: range restrictions (<minInclusive> , <maxInclusive> )

display hints (<fractionDigits> )

• octet strings with display hints

XML: represented as strings conforming to display hints,Schema: DISPLAY-HINTs converted to <pattern> reg-exp’s (as good as possible)

• octet strings without display hints

XML: represented as sequences of 2-digit hex valuesSchema: based on the hexBinary type

• enumeration and bit set values

XML: represented as (sequences of) labelsSchema: (<list> s of) <enumeration> values

Example XML Document

<snmp-data "xmlns=http://example.com/TCP-MIB"><context ipaddr="134.169.34.81" hostname="tom.example.com"

port="161" community="public" time="2003-03-17T11:07:53Z"><TCP-MIB:tcp>

<TCP-MIB:tcpRtoAlgorithm>other</TCP-MIB:tcpRtoAlgorithm><TCP-MIB:tcpRtoMin>0</TCP-MIB:tcpRtoMin>[...]

</TCP-MIB:tcp><TCP-MIB:tcpConnEntry

tcpConnLocalAddress="0.0.0.0" tcpConnLocalPort="9"tcpConnRemAddress="0.0.0.0" tcpConnRemPort="0">

<TCP-MIB:tcpConnState>listen</TCP-MIB:tcpConnState></TCP-MIB:tcpConnEntry><TCP-MIB:tcpConnEntry

tcpConnLocalAddress="134.0.0.0" tcpConnLocalPort="42077"tcpConnRemAddress="134.0.0.0" tcpConnRemPort="6010">

<TCP-MIB:tcpConnState>established</TCP-MIB:tcpConnState></TCP-MIB:tcpConnEntry>

</context></snmp-data>

SNMP/XML Gateway Prototype (TU Braunschweig)

HTTPEngine

(withCGIor

Interface)

SNMPEngine

(CommandGenerator

andNotificationOriginator)

HTTP GET

HTTP POST

(HTTP POST)

TranslatorXMLParser DOM

XPathInterpreter

SNMP Set

SNMP Get*

SNMP Trap

Notification SchemaServlet

Log Cache Repository

Example: Retrieve the descriptions of the interfaces at talisker.ibr.cs.tu-bs.dethat are currently in operation and transmitted or received at least one packet:

$ lynx -dump ’http://www.ibr.cs.tu-bs.de/snmp-xml-gw?\get=/snmp-data/context[@hostname="talisker.ibr.cs.tu-bs.de"]\/ifEntry[ifOperStatus="up" and (ifOutOctets > 0 or ifInOctets > 0)]\/ifDescr’

WEB SERVICES FOR MANAGEMENT

A PERSONAL VIEW

TUTORIAL T4 - PART 4PRESENTED AT NOMS’2004

SEOUL, KOREA19 APRIL 2004

AIKO PRASUNIVERSITY OF TWENTE

THE NETHERLANDS

[email protected]://wwwhome.cs.utwente.nl/~pras

Copyright © 2004 by Aiko PrasThese sheets may be used for educational purposes

OVERVIEW

WHY WEB SERVICES?

WHAT ARE WEB SERVICES?

EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS

WHY WEB SERVICES?

EVOLUTION OF SNMP FAILED

NEW TECHNOLOGIES ARE NEEDED

WEB SERVICES MAY BECOME THE MOST IMPORTANTMIDDLEWARE TECHNOLOGY

WILL BECOME AVAILABLE ON ALL FUTURE PLATFORMS

WILL BE APPLIED FOR MANY KINDS OF APPLICATIONS

IMPLEMENTATION OF WS APPLICATIONS IS RELATIVELY SIMPLE

MANY SKILLED DEVELOPERS

MANY TOOLS

FUTURE MANAGEMENT EXPERTSCAN CONCENTRATE ON MANAGEMENT APPLICATIONS

INSTEAD OF MANAGEMENT TECHNOLOGY

WHY WEB SERVICES?SOME FACTS

MANY PROGRAMMING LANGUAGES HAVE WS LIBRARIES

PART OF DEVELOPMENT PLATFORMS: .NET, SUN-ONE, JBUILDER

WS SUPPORT INCLUDED IN WINDOWS / OFFICE

CALLING A WS FROM EXCEL TAKES 4 LINES OF CODE

COMPARE THIS TO SNMP!

THE KEY TO SUCCESS WILL BE EASE OF USE!

WHY WEB SERVICES?THE HYPE

IRTF-NMRGNetwork Management Research Group

OASISWeb Services Distributed Management

OGSI Open Grid Services Infrastructure Working Group

PARLAY GROUPParley-X

MANY RESEARCH GROUPS

OVERVIEW

WHY WEB SERVICES?


EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS


WEB SERVICES COMPONENTS

PROTOCOL STACK

MAIN W3C SPECIFICATIONS

STRUCTURE WSDL DEFINITION

OPERATION STRUCTURE

DATA TYPES

ADVANCED FEATURES

WEB SERVICES COMPONENTS

CLIENT

Webservice

Webservice

Webservice

UDDIREPOSITORY

SOAP/WSDL

WEB SERVICES COMPONENTS FOR MANAGEMENT

MANAGER

BServer

ARouter

CPC

"MIB"REPOSITORY

SOAP/WSDL

"LOCAL ACCESS"

REPOSITORY

STACK DIAGRAM

ProcessesDiscovery, Aggregation, Choreography ...

DescriptionsWeb Services Descriptions (WSDL)

Messages

SOAP ExtensionsReliability, Correlation, Transactions, ...

SOAP

Base T

echnologies: XM

L, Schem

a, ...Bas

e T

echn

olog

ies:

XM

L, S

chem

a, ..

.

CommunicationsHTTP, SMTP, FTP, ...

MAIN W3C DOCUMENTS

Web Services Description Language (WSDL)Working Drafts - Version 2.0 - 2003

• Core Language• Message Patterns

• Bindings• Requirements

• Usage Scenarios

SOAPVersion 1.2 - W3C Recommendation - June 2003

• Part 0: Primer• Part 1: Messaging Framework

• Part 2: Adjuncts

XML SchemaW3C Recommendation - May 2001

• Part 0: Primer• Part 1: Structures• Part 2: Datatypes

STRUCTURE WSDL DEFINITION

ABSTRACT INTERFACE TO THE WEB SERVICE

Independent of a specifictransport protocol

BINDING

To associate the abstract interface with a transport protocol

and Web address

SERVICE

To associate the abstract interface with a Web address

STRUCTURE WSDL DEFINITIONABSTRACT INTERFACE - EXAMPLE

<message name="getIfInOctetsRequest"><part name="community" type="xsd:string"/><part name="index" type="xsd:unsignedInt"/>

</message>

<message name="getIfInOctetsResponse"><part name="ifInOctets" type="xsd:unsignedInt"/>

</message>

<interface name="IfDataServiceInterface"><operation name="getIfInOctets">

<input message="myns:getIfInOctetsRequest"/><output message="myns:getIfInOctetsResponse"/>

</operation></interface>

STRUCTURE WSDL DEFINITIONBINDING TO A PROTOCOL - EXAMPLE

<binding name="ifDataServiceBinding"interface="myns:IfDataServiceInterface">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="getIfInOctets"><soap:operation soapAction=""/><input>

<soap:body use="encoded" namespace="urn:..."encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</input>

<operation></binding>

<output><soap:body use="encoded" namespace="urn:..."

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output>

STRUCTURE WSDL DEFINITIONSERVICE AT A WEB ADDRESS - EXAMPLE

<service name="ifDataService" interface="myns:IfDataServiceInterface">

<endpoint name="ifDataServiceEndpoint"binding="myns:ifDataServiceBinding"

<soap:address location="http://my.webservice.com/ifData/"/> </endpoint>

</service>

MODULAR WSDL STRUCTURE

IF MODULE

ABSTRACT

INTERFACES getIfTable

<message ...<operation ...

IF BINDING

SOAP

<import IF MODULE<binding ...

MY MGT. SERVICE

http://...

<import IF BINDING

<service

IP MODULE

getRouteTable

<message ...<operation ...

IP BINDING

SOAP

<import IP MODULE<binding ...

<import IP BINDING

STANDARDIZED

SITE SPECIFIC

POSSIBLE MESSAGE STRUCTURE

ifInOctets

ifOutOctets

ifTable iPTable

All

getiFOutOctets

getiFInOctets

getiFTable

getAll

COARSE• get(OID, instance, ...)• set (OID, instance, ...)

• ...

FINE• getAll(...)

• getIfTable(...)• getIfInOctets(index, ...)

• getIfOutOctets(index, ...)• ...

POSSIBLE MESSAGE PARAMETERS

NON-TRANSPARENTgetIfInOctets(index, amount)

• Data parsed at WSDL level• One level of standards: WSDL

• Less flexible• Easy integration with standard applications

• Simple users (home environments)

TRANSPARENTgetIfInOctets(string)

• Data parsed by higher level application• Data could be XML encoded

• Two levels of standards: WSDL operation & XML data• Powerful (e.g. XPATH / XQUERY)

• Harder to use (professional operators)

DATA TYPES

anySimpleTypeall complex types

anyType

duration dateTime time date gYearMonth gYear gMonthDay gDay gMonth

boolean base64Binary hexBinary float double anyURI QName NOTATION

integer

string

normalizedString

decimal

nonPositiveInteger long nonNegativeIntegertoken

negativeIntegerlanguage Name NMTOKEN

NCName NMTOKENS

IDREF ENTITYID

IDREFS ENTITIES

unsignedIntshort

unsignedShortbyte

unsignedByte

int positiveIntegerunsignedLong

ADVANCED FEATURES

TRANSACTIONS• Business Transaction Protocol (OASIS)

• WS-Coordination + WS-Transaction (BEA, IBM, MS)• WS-Composite Application Framework (Arjuna, Fujitsu, IONA, Oracle, Sun)

SECURITY• WS-Security (IBM, OASIS)

CHOREOGRAPHY / ORCHESTRATION• XLANG (MS), WSFL (IBM)• BPEL4WS (IBM, MS, BEA)

• WSCI (SUN, ...)• W3C

OVERVIEW

WHY WEB SERVICES?


EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS

EXAMPLE

PROTOTYPE

• ifTableGetIfCell

GetIfColumnGetIfRowGetIfTable

• gSOAP (2.3.8)

• Net-SNMP (V5.0.x) Data retrieval functions

• Debian Linux, kernel v2.4.22, 800 Mhz Pentium

EXAMPLE

<complexType name="GetIfTableResponse"> <sequence> <element name="ifEntry" type="utMon:ifEntry" minOccurs="1" maxOccurs="unbounded"/> </sequence> </complexType>

<message name="GetIfTableRequest"> <part name="commuity" type="xsd:string"/></message>

<message name="GetIfTableResponse"> <part name="-sizeTable" type="xsd:int"/> <part name="ifEntry" type="utMon:ifEntry"/></message>

<portType name="GetIfTableServicePortType"> <operation name="GetIfTable"> <documentation>Service definition of function utMon__GetIfTable</documentation> <input message="tns:GetIfTableRequest"/> <output message="tns:GetIfTableResponse"/> </operation></portType>

EXAMPLE

<complexType name="ifEntry"> <sequence> <element name="ifIndex" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifDescr" type="xsd:string" minOccurs="1" maxOccurs="1" nillable="true"/> <element name="ifType" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifMtu" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifSpeed" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifPhysAddress" type="xsd:string" minOccurs="1" maxOccurs="1" nillable="true"/> <element name="ifAdminStatus" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifOperStatus" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifLastChange" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifInOctets" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifInUcastPkts" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifInDiscards" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifInErrors" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifInUnknownProtos" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifOutOctets" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifOutUcastPkts" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> <element name="ifOutErrors" type="xsd:unsignedInt" minOccurs="1" maxOccurs="1"/> </sequence></complexType>

OVERVIEW

WHY WEB SERVICES?


EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS

PERFORMANCE - BANDWIDTH

4000

1000

2000

3000

5000

6000

7000

objects

octets

0 67 133 20016610033

compressedweb services

compressedSNMP

uncompressedweb services

SNMPget / getNext

SNMPgetBulk

PERFORMANCE - CPU TIME

XML compression

Data Retrieval

XML encoding

BER encoding

XML encoding1 object

1 object

1 Table

BER encoding1 Table

350

70

600

600

1000

2000

time (µsec)

PERFORMANCE - MEMORY USAGE

WS data / fixed

SNMP footprint

WS footprint

SNMP data / fixed

580

1972

0,47

128

162

300

Kbytes

WSper operation

SNMP (cell)per operationSNMP (table)per operation

WS compressionper operation

4,5

71

PERFORMANCE - END TO END DELAY

WS compression

WS1 cell

1 cell

WS1 Table

2,6

3,7

2,3

3,0

4,1

108,0

time (msec)

SNMP1 cell

WS compression1 Table

SNMP1 Table

OVERVIEW

WHY WEB SERVICES?


EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS

TOOLS

gSOAP

WASP

easySOAP++

.NET

JBuilder

SunOne

OVERVIEW

WHY WEB SERVICES?


EXAMPLE

PERFORMANCE

TOOLS

CONCLUSIONS

CONCLUSIONS

EVOLUTION OF SNMP FAILED

WE NEED REVOLUTION

WEB SERVICE IS AN INTERESTING TECHNOLOGY

MANY ISSUES STILL UNCLEAR

TOPIC FOR FUTURE RESEARCH

PERFORMANCE OF WEB SERVICESMAY NOT BE A PROBLEM

Online Resources

• Internet Engineering Task Force (IETF) http://www.ietf.org/

• IETF OPS Area http://www.ops.ietf.org/

• Internet Research Task Force (IRTF) http://www.irtf.org/

• Network Management Research Group (NMRG) http://www.irtf.org/

• The SimpleTimes http://www.simple-times.org/

• The Simple Web http://wwwsnmp.cs.utwente.nl/

• Tutorial Slides http://www.faculty.iu-bremen.de/schoenw/