Using Corba For MTNM

TM FORUM PROJECT:
MTNM Phase III Modelling Team
CONTRIBUTION TITLE:
Using CORBA for MTNM
SOURCE:
Siemens AG
Information and Communication Networks (ICN)
Carrier Products Systems Engineering (CP SE)
Hofmannstr. 51
D-81359 Munich
CONTACT:
Felix Flemisch
Phone Number
Email Address
+49 89 722 62175

felix.flemisch@siemens.com
DATE:
FILE NAME:
12 May 2003
Using-CORBA-for-MTNM-12-May-2003.doc
DISTRIBUTION:
MTNM Exploder (MTNM@tmforum.org)
SUMMARY
This document is a contribution to The Promotion and Evolution of TMF MTNM. It provides an introduction to MTNMs CORBA information model including important agreed features of v3.x and a couple of proposed but deferred features. It gives an overview of the connection-oriented and connectionless
transmission layering according to G.805 and G.809, the core TMN functionality supported by TMF
MTNM, and the agreed or scheduled support of specific technologies in v2.1, v3.0, and further versions.
It also relates MTNMs CORBA model to ITU-Ts CORBA framework and demonstrates mediation and
coexistence of both models. Refer to the Abstract and TABLE OF CONTENTS for further details.
NOTICE
The proposals in this submission have been formulated to assist TM Forum working groups. This document is offered to the
TM Forum working group as a basis for discussion and is not binding to the contributor(s), the contributing company or any
of their subsidiaries or affiliates. The contents of the contribution are subject to change after further study. Siemens specifically reserves the right to add to, amend, or withdraw statements contained herein. See also the EDITOR'S NOTES.
Using CORBA for Multi-Technology Network

Management (MTNM)
Felix F. Flemisch
Siemens AG, Information and Communication Networks, Hofmannstr. 51, D-81359 Munich, Germany
E-mail: felix.flemisch@siemens.com
A Contribution to The Promotion and Evolution of TMF MTNM

Abstract TeleManagement Forum (TMF) develops the industry standard for MTNM through its specification of the
NML-EML interface (TMF814). The current version 2.1 includes PDH, SDH/SONET, OTN/DWDM, and core ATM.
Version 3.0 will add inverse multiplexing, Ethernet tributary
interfaces, DSL, various profile mechanisms, and further enhancements. Subsequent versions are scheduled to include
Ethernet services, VLAN, IP services, MPLS, VPNs, AAL, CE,
FR, voice signalling, VoIP, and transmission conditioning.
This document provides an overview of TMFs MTNM
model and its realization in CORBA IDL. It illuminates the
importance of a coarse-grained approach to CORBA object
modelling. It presents how the modelling of managed objects
refers to the ITU-T model of connection-oriented and connectionless transmission layering thereby enabling the seamless
integration of any desired transmission technology. It outlines
the principal behaviour of TMF MTNMs managed objects:
network exploration and monitoring, network and network
element configuration and control, service level agreements
and rapid service provisioning, use of profiles.
The paper then shows how technology-specific management
details specified by other standards development organizations
can be integrated into TMFs MTNM model in a straightforward way and gives important examples of technologies. It
finally relates the model to the CORBA network and network
element management framework specified by ITU-T and
demonstrates mediation and coexistence.
Index Terms MTNM, coarse-grained CORBA, multiple
connection-oriented and connectionless transmission layering,
service level agreements and rapid service provisioning.
I. INTRODUCTION
Service providers, network operators, and suppliers of
telecommunications equipment and business and operations
support software work closely together in TeleManagement
Forum (TMF) to achieve industry-wide agreements on how
management information should be exchanged within the
Telecom Operations Map (TOM) framework. The paper
provides an overview of some aspects of one of these ongoing activities, the development of the Multi-Technology
Network Management (MTNM) NML-EML Interface.1
TMFs MTNM NML-EML interface is abbreviated as TMF
1
The Network Management Layer (NML) and Element Management

Layer (EML) are defined by famous ITU-T Rec. M.3010, which organizes
telecom functions (according to Rec. X.700 and Rec. M.3400) into groupings called logical layers and describes the relationships between these
layers to deal with telecom management complexity.
MTNM in the following. It applies to TOMs Network and

Systems Management Processes, including Network Planning & Development, Network Provisioning, Network Inventory Management, Network Maintenance & Restoration,
and Network Data Management. TMF MTNM is published
in a ready-to-use fashion as a set of HTML-documented
CORBA IDL files with supporting documentation [1], implementation statement template and guidelines [2], a protocol neutral information model with UML diagrams and
class dictionary [3], and requirements and use cases [4].
The paper is not a summary of TMF MTNMs deliverables but focuses on two really unique aspects of MTNMs
CORBA information model that are not found elsewhere
and enable seamless integration of new or currently emerging technologies into TMF MTNM. The supporting documents Overview of the NML-EML interface.htm and layers.pdf (Functional Modelling Concepts) of [1] are the starting point for these considerations. The range of CORBA
features required for CORBA-based telecom management
are Revision 2.3 of OMGs CORBA specification (see [5])
and the OMG Naming Service (see [6]).
TMF MTNM is a client/server interface between an Element Management System (EMS) and a Network Management System (NMS). The EMS is the server that implements
the interface and transmits notifications, and the NMS is the
client that uses the interface and receives notifications. One
frequently views the client system on top of, or northbound
to, the server system, and the server system below of, or
southbound to, the client system. Therefore the interface
part of the server system is called northbound interface
(NBI) while the interface part of the client system is called
southbound interface (SBI).
The specification of an NBI includes the operations that
can be called by clients, the notifications that are sent to
registered clients, and the operation parameters, in particular TMN objects that can be exchanged across the interface.
When the NBI is based on a standard, e.g. a set of CORBA
IDL files such as [1], the specification must include a detailed compliance list that states all interface implementation details that are actually available for clients as well as
applicable restrictions, e.g. [2] and a vendor-specific supplement. The description of an SBI requires the full specification of the corresponding NBI as a prerequisite. It includes the main use case packages that can be used by one
Copyright 12 May 2003 Siemens AG. All Rights Reserved.
Using CORBA for Multi-Technology Network Management (MTNM)

3
or more clients to leverage the functionality offered by the

server. When the SBI is served by a standard, e.g. [1], some
use cases might be documented in the standard, e.g. [4] and
TMF833, while others could be straightforwardly derived
from northbound features.
II. GRANULARITY OF CORBA IDL INTERFACES
Granularity defines the level of abstraction, not the level
of detail, that is exposed between a server and its clients. It
identifies the level at which entities may be accessed, i.e.
how information is exposed at the interface. At a CORBA
interface each object is provided a unique address known as
an Interoperable Object Reference (IOR). In fine-grained
approaches each interface object has an IOR, while in
coarse-grained client/server interfaces only a small number
of interface objects have IORs, i.e. are CORBA objects.
Objects with IORs are used to access a large number of
objects without IORs, i.e. non-CORBA objects. A CORBA
object (with an IOR) is referred to as a faade or a firstlevel object while an object that is managed by a faade is
referred to as a light object or a second-level object.
Generally the design of faades is application-specific but
the weakest form of coarse granularity, the class granularity, is application-independent. A class-grained design has
one CORBA IDL interface for each managed object class,
i.e. it uses a one-instance-per-class approach instead of the
fine-grained one-instance-per-object approach. Some
mechanism has to be supported by the class-grained IDL
interface to allow the management of each managed object
instance, e.g. the managed object name placed as an input
parameter for every faade operation.
A grain-neutral design uses an identification structure
holding both the managed object name and the IOR used to
provide access to the managed object. While requiring the
client to pass the managed object identifier as a parameter
to each operation (i.e., looking like class-grained to the client), it allows the implementation of the servants in the
server to be either class-grained or fine-grained.
The granularity concepts for CORBA IDL interfaces
have their origin in experiences, which were full of suffering, with fine-grained CORBA environments for telecom
management purposes. Object-oriented network management interfaces typically model umpteen millions of entities, and so modelling each entity as a full-fledged CORBA
object may easily lead to inefficient systems.
When a fine-grained interface is requested by a customer,
the vendors system design must take into consideration
how an extremely large number of distributed CORBA objects can be handled efficiently. This issue addresses the
way how the objects are implemented within their respective CORBA servers. Now in CORBA the object adapter is
the built-in mechanism that connects a request using an IOR
with the right code to service that request, which is part of
the programming language entity that implements and
represents the requested CORBA object. These entities are
called servants or incarnations. The Portable Object

Adapter (POA) is a particular type of object adapter specified by the OMG (see [5]) to achieve the maximum amount
of portability amongs ORBs with widely different design
points and, more importantly, to minimize the implementation code route covered to connect to the respective servant
and execute the request. Moreover, the POA allows to persistently store object state between operation invocations.
Therefore the brilliant use of the POA is a conditio sine qua
non when implementing fine-grained interfaces. The POA
enables CORBA implementations to scale up to millions
upon millions of instantiated objects, a magnitude required
for fine-grained network management applications. Clearly,
the use of the POA will offer big performance advantages
for coarse-grained approaches as well where very few servants are called with exceedingly high frequency.
ITU-T SG 4 formalized the coarse-grained approach to
CORBA-based TMN interface modelling in two companion
recommendations (see [7], [8]). These guidelines require,
however, a fine-grained design according to ITU-T Rec.
X.780 as a prerequisite for the coarse-grained design, since
most constructs of the fine-grained interfaces are reused. As
a consequence the resulting interfaces are class-grained and
semantically equivalent to their fine-grained counterparts.
Examples of coarse-grained CORBA IDL modelling can
be found in [1], [9], [10], [11], [12]. While [1], i.e. TMF
MTNM, realizes a true coarse-grained approach where a
faade may manage several related managed object classes,
[9]-[12] refer to ITU-Ts class-grained approach.
III. CONNECTION-ORIENTED AND CONNECTIONLESS
TRANSMISSION LAYERING (G.805 AND G.809)
A transport network conveys telecommunications information between locations. In concrete environments this
information is a signal with a technology-dependent format,
and, optionally, a specific transmission rate (bandwidth),
which is transmitted or received on network connections or
in a connectionless way. ITU-Ts famous Rec. G.805 (see
[13]) considers each specific signal to be bound to a connection-oriented transmission layer and introduces the term
characteristic information (CI) for the signal. It decomposes the transport network into a number of independent
single layer networks with a client/server association between adjacent layer networks. Each layer network can be
separately partitioned in a way, which reflects its internal
structure or the way that it will be managed. Thus the concepts of partitioning and layering are orthogonal: a downwards vertical transmission layering is supplemented by a
recursive horizontal layer network partitioning. A single
layer network describes the generation, transport, and termination of a particular characteristic information.
Layer networks are partitioned into appropriate subnetworks and links between them, and subnetworks and links
may be further partitioned. A network partitioning implies
the connection partitioning of its network connections into

4
so-called tandem connections, i.e. alternating sequences of

subnetwork connections (SNCs) within subnetworks and
link connections (LCs) between subnetworks.
In the client/server relationship of adjacent layer networks, client layer link connections are supported by server
layer trails (one-to-one, many-to-one, one-to-many) through
an adaptation that modifies the characteristic information of
the client layer so that it can be transported over the trail (=
connection with trail terminations at both extremities) in
the server layer network. The trail is built from the underlying tandem connection by means of a trail termination that
generates characteristic information by adding/extracting a
trail overhead to/from the information it has to transport.
This trail overhead allows performance monitoring of the
trail and ensures the integrity of information transfer. A
signal that is transmitted or received on a trail is called
adapted information (AI).
A one-to-one client/server relationship represents the
case of a single client layer link connection supported by a
single server layer trail. The many-to-one relationship
represents the case of several link connections of client
layer networks supported by one server layer trail at the
same time. Multiplexing techniques are used to combine the
client layer signals. The one-to-many relationship represents the case of a client layer link connection supported by
several server layer trails in parallel. Inverse multiplexing
techniques (e.g., I.761 IMA/LASR, G.7042 LCAS) are used
to distribute the client layer signal.
Each G.805 transport entity is delimited by accompanying reference points: link connectionss by connection points
(CPs), trails by access points (APs), tandem connections by
termination connection points (TCPs). Figure 1 (which is
Figure 3/G.805 of [13]) provides an overview of the different reference point and pipe concepts used in connectionoriented TMN functional models.
Trail
AP
Trail
termination
Trail
termination
Network connection
CP
TCP
AP
Link connection
SNC
TCP
Client to
server
adaptation
Client to
server
adaptation
Trail
AP
AP
Trail
termination
Trail
termination
SNC
TCP
Client
layer
network
LC
CP
LC
CP
SNC
LC
CP
Server
layer
network
CP
TCP
T1304480-95
Figure 1 Basic G.805 Modelling Concepts.
Figure 2 (which is Figure 2/G.852.2 of [14]) provides an

overview of the corresponding enterprise-wide network
resource concepts. ITU-Ts Rec. G.852.2 specifies a set of
definitions of management abstractions of G.805 transport
network architectural components; these abstractions are

termed network resources and the resulting transport network resource model is termed Transport Network Enterprise Model (TEM). The most important resources are the
Connection Termination Point (CTP) and the Trail Termination Point (TTP). The CTP is the assembly of the CP
resp. TCP and the client-layer part of the accompanying
adaptation. The TTP is the assembly consisting of the trailtermination part of the TCP and the accompanying trail
termination together with the server-layer part of the adaptation and hence together with the AP. Figure 2 shows that
in the TEM, CTPs are the delimiters of link connections and
TTPs are the delimiters of trails.
Client
layer
AP
Trail
termination
Subnetwork
TCP
Link
CP
Trail
termination
TCP
AP
LC
Connection
termination point
Client to
server
adaptation
Connection
termination point
Trail
Trail
termination
point
Server
layer
SNC
AP
Trail
termination
Trail
termination
point
Network connection
Subnetwork
TCP
SNC
CP
Link
LC
Connection
termination
point
TCP
Trail
termination AP
Connection
termination
point
T0410250-98
Port defined in Recommendation G.805
Figure 2 G.852.2 Transport Network Resource Model.
The inclusion of inverse multiplexing, adaptation and

trail termination function cardinalities, and link partitioning
(taken from G.852.2) are the essential enhancements of the
current issue of G.805 (March 2000, published in August
2001) compared to its predecessor (November 1995).
G.805 classifies transport network layers into service layers, path layers, and physical layers. Physical layers are
either media-independent transmission path (TPath) layers
or media-dependent transmission media (TMedia) layers (=
core transmission layers). TMedia layers are section layers
(e.g., multiplex sections, regenerator sections, digital sections, optical channels) or physical media layers (e.g., wired
cables, optical fibres, radio frequency channels).
G.805 describes the functional and structural architecture
of connection-oriented networks in a generic way, i.e. independently of the underlying networking technologies. Its
power is revealed when applying it to technologies of a
concrete environment. The application consists of the identification of the individual layers, their characteristic information, and their adaptation and trail termination functions.
Traditional examples are PDH layers, SDH layers, SONET
layers, OTN layers, and ATM layers. For further examples
see Section VI. INTEGRATION OF SPECIFIC TECHNOLOGIES.
The prime layer is DS0, the digital signal at level 0 with a
transmission rate of 64 kbit/s, which can be modulated as a

5
voice channel.2 A PDH layer corresponds to one of the basic hierarchical bit rates that are integer multiples of DS0
and based on the primary rate E1 = 2.048 Mbit/s = 32*DS0
or the primary rate T1 = 1.544 Mbit/s 24*DS0. The commonly used multiples are standardized (see ITU-T G.703)
in the E-carrier system (E2 = 4*E1, E3 = 16*E1, E4 =
64*E1, E5 = 256*E1) and T-carrier system (T2 = 4*T1, T3
= 28*T1) but legacy multiples of DS0 are also around.
An SDH layer is defined by the SDH multiplexing structure according to ITU-T G.707; it is a lower-order path
(LOP) layer VC-11, VC-11-Xv, VC-12, VC-12-Xv, VC-2,
VC-2-Xc, VC-2-Xv, VC-3, VC-3-Xv, or a higher-order path
(HOP) layer VC-3, VC-3-Xv, VC-4, VC-4-Xc, VC-4-Xv, or
a transmission media layer (SDH multiplex section or SDH
regenerator section) STM-n (n = 0, 1, 4, 8, 16, 64, 256).
Here -Xc resp. -Xv refers to the contiguous resp. virtual
concatenation of X equal Virtual Containers where X =
1..256 but X = 4, 16, 64 are most frequently used.
Similarly a SONET layer is defined by the SONET multiplexing structure according to ANSI T1.105 and Bellcore
GR-253; it is a path layer VT-1.5, VT-1.5-Xv, VT-2, VT-2Xv, VT-3, VT-6, VT-6-Xc, VT-6-Xv, STS-SPE, STS-Xc,
STS-Xv, STS-3c-SPE, STS-3c-Xc, STS-3c-Xv, or a transmission media layer (SONET line or SONET section)
STS-n or OC-n (n = 1, 3, 12, 24, 48, 192, 768), which correspond to SDH section layers. Here -Xc resp. -Xv refers to
the contiguous resp. virtual concatenation of X equal Virtual Tributaries or Synchronous Payload Envelopes where
X = 1..256 but X = 3, 12, 48, 192 are frequently used.
An Optical Transport Network (OTN) supports the transmission of digital signals with prescribed block frame structures across optical channels. An OTN layer is defined by
the OTN multiplexing hierarchy according to Draft revised
ITU-T Rec. G.709; it is either a digital section layer OPUk,
OPUk-Xv, ODUk, OTUk, OTUkV (k = 1, 2, 3), or an optical section layer OCh, OChr, OMSn, OTSn, OPSn (n >= 0).
Here -Xv refers to the virtual concatenation of X equal Optical channel Payload Units where X = 1..256 (e.g., X = 4,
16). An optical channel OCh resp. OChr is characterized by
a colour (i.e., optical wavelength) or frequency. The OMSn
resp. OPSn performs WDM for up to n OChs resp. OChrs
(n >= 1) to form a WDM group of wavelengths, and OMS0
resp. OPS0 supports a single non-coloured OCh resp. OChr.
Optionally, the OPU2 resp. OPU3 can do TDM for up to 4
ODU1s resp. for up to 16 ODU1s and/or up to 4 ODU2s.
The ATM Protocol Reference Model (PRM) according to
ITU-T Rec. I.321 defines two path layers above the physical layer that implement the features of ATM, the ATM
Adaptation Layer (AAL) and the ATM layer proper, and
splits the physical layer into the transmission convergence
(TC) sublayer and the physical medium dependent (PMD)
sublayer. The (lower) ATM (path) layer generates and ex2
For some applications DS0 paths may need to be channelizable into independent 16 kbit/s or 8 kbit/s channels (i.e., they are not prime).
tracts ATM header information; it consists of the upper

virtual channel (VC) sublayer and the lower virtual path
(VP) sublayer. The ATM transport assembly consists of the
VC layer network, the VC to VP adaptation, the VP layer
network, and the VP to TPath adaptation by means of TC
adaptors (ATM cells to/from say PDH or SDH/SONET or
OTN or DSL payloads), i.e. the network interface (NI) towards the user (UNI) or network (NNI). An ATM NI layer
is a physical layer which can be associated to one or more
adjacent TPath layers that are capable of supporting ATM.
An ATM layer (in the sense of G.805) is defined by the
ATM multiplexing model according to ITU-T I.150; it is a
VC layer or a VP layer or an NI layer. The ATM CI is a
non-continuous stream of ATM cells (with different payload types) that has no specific rate. The ATM transport
assembly multiplexes VC streams into VP streams and VP
streams into the UNI or NNI, and demultiplexes accordingly. It performs VCI and VPI translation at ATM switching or cross-connect nodes to redirect the cell streams. The
VC layer CI is a stream of VC layer AI and F5 OAM information. The VP layer CI is a stream of VP layer AI,
which includes multiplexed VC layer CI, and F4 OAM information. The VP/VC resp. NI/VP adaptation source/sink
includes VCI resp. VPI allocation/demultiplexing.
For details of CI and AI, and the processes of adaptation
and trail termination functions, see G.806 in a generic way,
G.705 for PDH, G.783 for SDH, Bellcore GR-253 for
SONET, G.798 for OTN, and I.731/I.732 for ATM. ITU-T
Recs. G.803, G.872, I.326 (see [15], [16], [17]) translate the
generic G.805 transport model to the SDH, OTN, ATM
transmission technology, respectively.
TABLE 1 summarizes the G.805 layering for the discussed
connection-oriented technologies. The ATM NI layer with
its TC adaptor is an example of a technology interworking
function (IWF) layer. The IWF (e.g., ATM TC) must be
specified separately for each interworked technology (e.g.,
G.804 for ATM over PDH). For further examples see Section VI. INTEGRATION OF SPECIFIC TECHNOLOGIES.
A connection can be a permanent connection (PC) or a
semi-permanent connection (semi-PC) or a switched connection (SC) or a soft permanent connection (SPC). In case
of ATM one talks about permanent virtual connections/
circuits (PVCs), switched virtual connections (SVCs), and
soft permanent virtual connections (SPVCs).
A PC is a connection type that is provisioned (as a crossconnection or an SNC) by the network management system.
PCs are ready-to-use created and permanently activated in
the network and hence reduce the access capability at the
UNI for switched services. Therefore some technologydependent PC types may be configurable to become semipermanent, i.e. they are still dedicated to a subscriber but
created and then separately activated. Semi-PCs are readyto-use configured in the network (i.e., persistently created)
but only activated or deactivated when requested by a dialup or shut-down call from the end users CPE.

6
TABLE 1 TRADITIONAL TRANSMISSION TECHNOLOGIES
Technology
Digital
PDH
(CO-CS)
Layer Type
Prime
E-Carrier
Layers
DS0
E1, E2, E3, E4, E5
T-Carrier
T1, T2, T3
LOVC TPath
Digital
Section
Optical Path
Optical
Section
Path
VC-11, VC-11-Xv,
VC-12, VC-12-Xv,
VC-2, VC-2-Xc,
VC-2-Xv, VC-3,
VC-3-Xv
(X = 1..256)
VC-3, VC-3-Xv,
VC-4, VC-4-Xc,
VC-4-Xv
STM-n (n = 0, 1, 4,
8, 16, 64, 256)
STM-n (n = 0, 1, 4,
8, 16, 64, 256)
VT-1.5, VT-1.5-Xv,
VT-2, VT-2-Xv,
VT-3, VT-6, VT-6Xc, VT-6-Xv
STS-SPE, STS-Xc,
STS-Xv, STS-3cSPE, STS-3c-Xc,
STS-3c-Xv
STS-n, OC-n
(n = 1, 3, 12, 24, 48,
192, 768)
STS-n, OC-n
(n = 1, 3, 12, 24, 48,
192, 768)
OPUk, OPUk-Xv,
ODUk (k = 1, 2, 3)
OTUk, OTUkV
(k = 1, 2, 3)
OCh, OChr
OMSn, OTSn,
OPSn (n >= 0)
VC, VP
TPath
UNI, NNI
G.703, G.705
SDH
(CO-CS)
G.707, G.783,
G.803
HOVC TPath
SONET
(CO-CS)
Multiplex
Section
Regenerator
Section
VT TPath
T1.105, GR-253
STS TPath
SONET Line
SONET
Section
OTN
(CO-CS)
G.709, G.798,
G.872
ATM
(CO-PS)
I.150, I.326,
I.731, I.732
Digital Path
An SC is any connection that is established, as a result of

a request from the end user, between connection end points
using a signalling/control plane, and involves the dynamic
exchange of signalling information between signalling elements within the control plane(s). An SPC is a user-to-user
connection where the user-to-network portion of the end-toend connection is established by the network management
system as a PC (e.g., a link connection). The network portion of the end-to-end connection is established as an SC
using the control plane. In the network portion of the SPC,

requests for establishment of the connection are initiated by
the management plane and set up by the control plane.
While SVCs and SPVCs are well-known in ATM environments (see ITU-T Recs. Q.2766.1 and Q.2767.1), requirements and architectures for automatically switched
transport networks (ASTNs) and especially automatically
switched optical networks (ASONs) and ASON management
are currently under study by ITU-T SG 15 (see G.807 [18],
G.8080 [19], G.771x[.y], G.fame), Optical Internetworking
Forum (OIF), and TMF MTNM (see Section VI.G.).
The concept of the connection is central to the functional
architecture described in ITU-T Rec. G.805. In order to
provide a common framework between connection-oriented
layer networks and connectionless layer networks ITU-T
SG 13 introduced, with new ITU-T Rec. G.809 (see [20]),
new concepts that describe connectionless behaviour. The
connectionless transport network functionality is described
from a network level viewpoint, taking into account layer
network structure, networking topology, client CI, client/
server layer associations and mappings between connectionless and connection-oriented layer networks.
The G.805 concepts of connection, subnetwork, and CP
are replaced by the G.809 concepts of flow, flow domain,
and flow point (FP). Whereas a connection-oriented layer
network may be bidirectional (default) or unidirectional, a
connectionless network is principally unidirectional. Instead
of unidirectional connections, flows are considered, which
are spatial or temporal aggregations of one or more traffic
units with an element of common routing. A flow can contain another flow, flows can be multiplexed together in the
same layer network, and a flow can be defined in terms of a
parameter such as its CI (e.g., Ethernet as a non-continuous
flow of variably long MAC frames) or the address to which
traffic units are directed (e.g., MAC destination address) or
the address the traffic units have come from.
A companion recommendation to G.809 is the Draft new
ITU-T Rec. M.3017 (see [21]) developed by SG 4. While
G.809 studies the connection-oriented (CO) and connectionless (CL) layer interworking, M.3017 considers the circuit-switched (CS) and packet-switched (PS) layer interworking, and these interworkings are clearly closely related.
G.809 distinguishes Connection-Oriented Circuit-Switched
(CO-CS) networks, Connection-Oriented Packet-Switched
(CO-PS) networks, and Connectionless Packet-Switched
(CLPS) networks; and gives details on CLPS networks implemented with IP (using best effort, destination-based forwarding) and those implemented with Ethernet. M.3017
defines a Hybrid Circuit/Packet Network (HCPN) as a network composed of both circuit-switched and (CO or CL)
packet-based layer networks. As with G.805 the power of
G.809 and M.3017 is revealed when applying them to technologies of a concrete environment (e.g., specification of IP
and Ethernet flow points over transport networks).

7
For examples of CO-PS and CLPS transport networks see

Section VI. INTEGRATION OF SPECIFIC TECHNOLOGIES.
IV. TMF MTNM CORBA INFORMATION MODEL
Section II. GRANULARITY OF CORBA IDL INTERFACES
and lengthy Section III. CONNECTION-ORIENTED AND CONNECTIONLESS TRANSMISSION LAYERING (G.805 AND G.809)
provide broad background to two unique aspects of TMF
MTNMs CORBA information model (see [1]) not found
elsewhere that enable seamless integration of new or currently emerging technologies into TMF MTNM: faades as
managing objects and transmission layering of managed
objects with multi-layer encapsulations. The sections paved
the way for the following short presentation.
TABLE 2 lists the faades of TMF814, called object managers, and the MTNM managed objects they manage.
TABLE 2 TMF814 MANAGERS AND MANAGED OBJECTS
TMF814 Manager
(CORBA faade
object with IOR)
ME Manager
MLSN Manager
EQP Manager
EMS Manager
TD Manager
PM Manager
Protection Manager
Maintenance Mgr
GCT Manager
root interfaces
(are not faades)
MTNM v2.1 Managed Object

managed by, or used by,
CORBA faade object
managed element (ME), termination
point (TP) (PTP, CTP, TPPool), alarm,
AID, cross-connection, TD, MLSN
multi-layer sub-network (MLSN)
(includes singleton), sub-network
connection (SNC) (includes crossconnection), topological link (TL),
TPPool, CTP, PTP, route, TD
equipment (EQP), equipment holder
(EQPH) (various types), PTP
element management system (EMS)
object, TL, alarm, AID, MLSN
traffic descriptor (TD), TP
performance management (PM) object
(PM location, granularity, PM parameter, TCA parameter, PM data), TP, ME
protection group (PGP), TP
maintenance operations, TP
GUI cut-through (GCT) widget data,
GCT launch command data
EMS session factory (entry point to
EMS), user name, password, EMS
session, NMS session, event channel
By means of these object managers and managed objects

TMF814 v2.1 allows the NMS to
use a single interface to manage networks comprising
of multiple technologies (see Section III. and Section VI.)
discover the physical network and NE resources managed by an EMS (e.g., network elements, shelves, plug-in
units, links) both at start up and during normal operation
configure termination points (see Section V.B.)
determine resource usage and Sub-Network Connections (SNCs) within the network managed by an EMS
request the EMS to establish SNCs and remove SNCs
create and use traffic descriptors for TP and SNC bulk

configuration and service level agreement conformance
retrieve performance data and measures, and protection
schemes, from the network, reconfigure them, and configure new measures and schemes as required
receive notifications (alarms, TCAs, events) in a standardized format and configurable way, with filter capabilities, and without receiving unsolicited notifications
pull on demand active alarms and TCAs in the notification format and with filter capabilities (see Section V.A.)
do even more
The managing objects (TMF814 CORBA IDL interfaces)
and managed objects (CORBA IDL structs with documented semantic properties) shown in TABLE 2 are described to
some extent in the next two subsections. For further details
refer to the HTML and supporting documentation of [1].
A. Managing CORBA Objects
Figure 3 shows (a fragment of) the CORBA object hierarchy of TMF814. The figure is considered to consist of six
rows according to the captions at the right hand side: root
interfaces, TMF814 v2.1 and v3.x, proprietary extensions, TMF814 v2.1 (continued), proprietary extensions (concluded), TMF814 v2.1 (concluded). What is
coloured in blue is not available with TMF814 v2.1 but
shows the high degree of extensibility of TMF MTNM.
user name
& password
NmsSession_I (at NMS)
EventChannel
root
interfaces
Version_I
ME Mgr
Session_I
EmsSessionFactory_I
MLSN Mgr
<TMF814 Mgr>
EQP Mgr
EmsSession_I
EMS Mgr
TD Mgr
Protection Mgr
Observer
(at NMS)
Maintenance Mgr
TMF814 v2.1 and v3.x
TMD Mgr
Core Functionality
PM Mgr
Common_I
GUI Cut Through Mgr
Observable
N
o
t
i
f
i
c
a
t
i
o
n
s
proprietary extensions
TMF814 v2.1 (continued)
proprietary extensions
(concluded)
Configurable Transmission Mode
inheritance
containment
CosNotification::*
ProcessingFailureException
TMF814 v2.1 (concluded)
Figure 3 Fragment of TMF MTNM CORBA Model.
The six rows are now explained. The row root interfaces includes the EMS session factory, EMS session, and
NMS session. The factory is the entry point to the EMS and
provides EMS sessions in a password-protected way that
get associated to NMS sessions, which are instantiated at
the NMS in advance. From an EMS session all faades of
the EMS can be obtained. The row also includes the virtual
interface Common from which all faades inherit.
The row TMF814 v2.1 and v3.x shows the core managers ME, MLSN, EQP, and the further managers EMS and
TD. The Transmission Descriptor (TMD) Mgr is a generalization of the TD Manager from ATM to any technology.
It will be part of TMF814 v3.x (see Section V.C.).

8
The row proprietary extensions shows a proprietary faade <TMF814 Mgr> that inherits from the core managers.
The row TMF814 v2.1 (continued) shows further standardized managers. Refer to TMF814A (see [2]) for implementation statement proformas regarding these managers.
The row proprietary extensions (concluded) shows an
alternative notification mechanism taken from TMF509.
The row TMF814 v2.1 (concluded) refers to the exception mechanism ProcessingFailureException and imported
interfaces from the OMG Notification Service (see [22]),
whose use with TMF MTNM is mandatory. TMF814 v3.x
will also include the OMG Telecom Log Service (see [23]).
Iterators for each managed object type (see the supporting document iterators.html of [1]) are important CORBA
interfaces of TMF814 but are not shown in Figure 3.
B. Managed MTNM Objects
cross-connected. The ATM VP CTP can be cross-connected

or further terminated to provide ATM VC CTPs.
CTPs (per ATM VP)
n x LR_ATM_VC
CTPs (per ATM NI)
n x LR_ATM_VP
CTPs (per VC4)

1 x LR_ATM_NI
CTPs (per VC4)
63 x LR_VT2_and_TU12_VC12
and
3 x LR_Low_Order_TU3_VC3
CTPs
4 x LR_STS3c_and_AU4_VC4
PTP
While faades are identified by CORBA IORs light objects are identified by (full) distinguished MTNM names,
which are name/value pair lists (see supporting document
objectNaming.html of [1]). Relationships between light objects are modelled by a naming hierarchy. Figure 4 shows
the corresponding MTNM object hierarchy of TMF814.
LR_Line_OC12_STS12_and_MS_STM4
LR_Section_OC12_STS12_and_RS_STM4
LR_DSR_OC12_STM4
LR_OPTICAL_SECTION
Proxy EMS
LR_PHYSICAL_OPTICAL
EMS
Figure 5 ATM and SDH Capable STM-4 Port.

MLSN
SNC
TPPool
ASAP (v3.x)
EQPH
TL
ME
PTP
PGP
or
FTP (v3.x)
AID
TD
TMD (v3.x)
TCAPP (v3.x)
TMC (v3.x)
EQP
CTP
PMP (v3.x)
GTP (v3.x)
Figure 4 TMF MTNM Managed Objects Containment.
Figure 4 also shows a Proxy EMS that rehangs managed

objects of an attached EMS from the EMS interface to the
proxy EMS interface. A proxy EMS may be used for scaleably concentrating multiple EMSes to a common TMF814
interface. This requires unique MTNM naming across all of
the EMSes attached to the proxy EMS, i.e. uniqueness on
the second level (MLSN, ME, TL, TD, TMD, ASAP).
The functional modelling concepts of TMF MTNM v2.1
according to the supporting document layers.pdf of [1] are
strongly based on ITU-T Recs. G.805 and G.852.2 but extend the layering concepts set out there by using multi-layer
encapsulations identified from real network element behaviour to provide high modelling and performance advantages
for information transfer between the NML and EML.
Figure 5 shows the layers of an STM-4 port that is capable of terminating VC4 and can provide VC12, VC3, and
ATM NI CTPs from the VC4. The ATM NI CTP can itself
be terminated to provide ATM VP CTPs but it can not be
Figure 6 shows the IMA model of TMF814 v3.0 (see

[24]). The managed object IMA Group is modelled as a
non-connectable, two-layer floating TP (FTP) with upper
layer LR_ATM_NI and lower layer LR_Fragment. The IMA
Link End managed objects are the server-side CTPs of the
IMA group FTP. They are named relatively to the containing FTP with respect to their common connectable layer
(e.g., LR_E1_2M) by use of an index.
LR_ATM_VP
ATM VP CTP
.../vpi=<p>
* 4095
IMA Group TP (non-connectable FTP)

<PTPStyleName>/atmnetworkinterface=1
LR_ATM_NI
(degraded)
*n
LR_Fragment
IMA Link (End) TP (server CTP)

e.g., .../atmnetworkinterface=1/e1=<e>
e.g., LR_E1_2M
SNC
Supporting CTP
Figure 6 IMA Group TP with Contained CTPs.

9
The model fully complies with the IMA Layer Reference

Model according to ITU-T Rec. I.761. The IMA-specific
(upper) TC sublayer is represented by the fragmentation
layer of the IMA group TP while the physical interfacespecific (lower) TC sublayer is represented by the fragment
layer of its server CTPs. The IMA Virtual Link can be represented by a topological link between two peer IMA group
TPs, the near end IMA group and the far end IMA group.
V. TMN FUNCTIONALITY SUPPORTED BY TMF MTNM
The behaviour of an MTNM managed object is implemented by its responsible CORBA faade. The best overview of managed object behaviour, i.e. supported TMN
functionality, can be obtained by reading TMF MTNMs
use cases that are traced to requirements (see the Business
Agreement TMF513 [4] and the Interface Implementation
Specification (IIS) TMF833 of the Nice 2001 catalyst). An
outline is listed after TABLE 2.
This section presents the most important examples by
reference to the responsible CORBA operations (thereby
doing some SBI specification work). The operations and
managed object structures are technology-independent, i.e.
apply to all technologies implemented by the MTNM EMS,
since the technology-specific parts of the interface (e.g.,
transmission layers and parameters) are encoded as attributes of universal managed objects.
A prerequisite to all work at the MTNM interface is the
successful execution of the use case NMS creates a session
with EMS. To this end the NMS first instantiates an NMS
session, gets the IOR of the EMS session factory from the
Naming Service, and invokes getEmsSession(). Then the
NMS calls EMS session operations: getEventChannel() to
gain access to the event channel and getManager() for each
required (and implemented) faade to gain access to it.
A. Network Exploration and Monitoring
To get to know the managed objects that are managed by
the EMS (i.e., by its faades) the NMS executes the relevant
steps of the universal use cases NMS discovers the EMS
network inventory and NMS queries the EMS concerning
inventory. To this end the NMS identifies the managers
that are responsible for the objects in question and calls the
appropriate getXYZ() operation(s) of these managers.
For monitoring purposes the NMS registers at the Notification Service related to the event channel as a consumer of
notifications, optionally sets filter criteria (e.g., managed
object types, notification types) to avoid the receipt of unsolicited notifications, and then connects to the Notification
Service to be able to receive notifications matching the filter conditions specified. Refer to the supporting document
notificationServiceUsage.html of [1] for details. On demand
the NMS can pull active alarms and threshold crossing
alerts (TCAs) by using the EMS manager operations get
AllEMSAndMEActiveAlarms() and getAllEMSSystemActive
Alarms(), and the ME manager operation getAllActive
Alarms().
These operations offer the option to exclude selected probable causes and/or perceived severities.
B. Network and NE Configuration and Control
The core configuration and control tasks are provisioning

of physical and logical ports (PTPs and CTPs) via the ME
manager, local and end-to-end SNC management (including
cross-connections as atomic SNCs) via the MLSN manager,
and equipment provisioning via the EQP manager.
Regarding TPs refer to the use case package Provisioning use cases, the use case Modify a TD on a VPCTP or
VCCTP, the ME manager operations inherited from the
Common interface,3 and the very central ME manager operation setTPData() that is used to change the TP mapping
mode, to assign and unassign TDs and TMDs, and to modify the multi-layered transmission parameters.
Regarding SNCs refer to the use case package Connection management use cases, the use case NMS creates
and activates ATM subnetwork connection, and the MLSN
manager operations checkValidSNC(), createSNC(), acti
vateSNC(), createAndActivateSNC(), deactivateSNC(),
deleteSNC(), and deactivateAndDeleteSNC(). The activation of SNCs allows for passing TDs and TMDs to establish
a desired service quality (see Section V.C.).
Regarding EQPs and EQPHs refer to the use case package Equipment use cases and the EQP manager operations provisionEquipment(), unprovisionEquipment(),
setAlarmReportingOff(), and setAlarmReportingOn().
The NMS can distinguish installed and/or provisioned
equipment, and there is a state machine for the EQPH states
(see the supporting document equipmentStates.pdf of [1]).
For the time being TMF MTNM does not include network element and equipment operations related to inventory
planning (e.g., spare EQPs, planned and provisioned MEs,
MEs and EQPs in stock, installation and uninstallation of
MEs and EQPHs). This would require a policy for synchronization with the physical (pre-)installation of MEs having
a given EQPH structure. The policy would depend on the
degree of pre-configuration of the considered ME.
C. SLAs and Rapid Service Provisioning
The New Generation Network (NGN) is a concept for defining and deploying networks today, which, due to their
separation into different layers and planes and use of open
interfaces, offer service providers and operators a platform
that can evolve in a step-by-step manner to create, deploy,
and manage innovative and profit-making services. A huge
number of characteristics can be required for the specification of an NGN service. To facilitate detailed planning and
provisioning of large and very large numbers of attractive
(hence complex) NGN services, service providers need to
specify profiles for their service portfolio regarding offered
service levels and granted traffic levels.
3
TMF814 v3.x adds the new Common operation setAdditionalInfo().

10
A service profile, or service level specification (SLS), is a

set of parameters and their values which together define the
service type offered to one or more customers. It is typically
defined at the time a service type is offered for the first
time, usually in the service layer of the deployed OSS architecture, and either in a proprietary format (e.g., XML with
provider-specific tag names and values) or in a standardized
way (e.g., XML that is tML-compliant according to ITU-T
Rec. M.3030). Pre-defined profiles can be communicated to
the network management systems to be used for rapid connection and flow provisioning. Each extremity of a connection can point to a profile for its desired overall egress and
ingress traffic characteristics. A service level agreement
(SLA) is a contract between a service provider and one or
more customers (i.e., a user organization or another provider domain) defining provider responsibilities in terms of
service profile characteristics (especially grades of service),
times of availability, methods of measurement, consequences if service levels are not met by the provider (service degradation or failure) or granted traffic levels are exceeded by the customer, and all costs involved.
A traffic profile is a set of parameters and their values,
defined e.g. in tML, that specify the temporal properties of
a traffic stream (e.g., rate in kbit/s, burst size in bytes) and
include rules for determining profile conformance for a
particular traffic unit (e.g., metering, marking, shaping,
discarding rules). A traffic conditioning specification (TCS)
is a set of parameters and their values which together specify classifier rules and a traffic profile whose rules are to
apply to the traffic streams selected by the classifier. A traffic conditioning agreement (TCA) is a contract negotiated
with customers whose traffic-related technical part is a
TCS. It allows the service provider to offer shared bandwidth services with granted traffic levels in an agreed way.
A traffic conditioner, or traffic conditioning block (TCB), is
a resource in an NE, usually situated at the edge of the network, that enforces compliance with a traffic profile or TCS
for all traffic that gets directed to it (e.g., by incorporating
meters, markers, shapers, droppers, and classifiers).
A service profile may include a traffic profile and an
SLA may include a TCA to specify consequences if granted
traffic levels are not met. A TCS may refer to an SLS and
then encompasses all traffic conditioning rules explicitly
specified by the SLS along with all such rules that are implicit from the applicable service requirements and/or from
an applicable service provisioning policy.
The consideration of service and traffic profiles and their
use in SLAs and TCAs leads to the NGN paradigm of rapid
service provisioning and conditioning: separate concerns by
first creating service and traffic profiles to be used for SLAs
and TCAs and then communicating profiles to the network
management systems (OSSes) for persistent storage and use
for rapid service provisioning and conditioning. From the
viewpoint of an OSS (e.g., a TMF MTNM EMS), a service
or traffic profile has an external representation and an OSS-
specific representation, and the OSS has means to import/

export external/OSS-specific profile representations and to
enforce profiles for service provision and surveillance.
Examples of technologies where profile mechanisms are
advantageous, or indispensable, are ATM traffic management (ATMF AF-TM-0121, ITU-T I.371), DSL line configuration on a massive scale (ITU-T G.997.1, IETF RFC
2662/3440/3276, DSLF TR-057), IP DiffServ traffic conditioning (IETF RFC 2475/3260/3290), and Ethernet user
priority and VLAN tagging (IEEE 802.1D/802.1Q).
TMF MTNM supports the NGN paradigm of rapid service provisioning and conditioning through appropriate managed objects, object managers, and enforcement operations.
The object types are Traffic Descriptor (TD), Transmission
Descriptor (TMD), and Transmission Conditioner (TMC)
(see [25]). TDs and TMDs represent service and traffic profiles while TMCs represent traffic conditioners. TMF814
v2.1 includes TDs for ATM. TMF814 v3.x generalizes TDs
to TMDs, which can be used for any technology and particularly for DSL, and introduces TMCs, which also can be
used for any technology and especially for IP DiffServ, IP
IntServ/RSVP, and tagged Ethernet.
TDs, TMDs, and TMCs can be retrieved at the interface,
and hence exported to an external representation, TDs and
TMDs can be created and TMCs can be modified at the
interface, and so imported from an external representation.
Figure 7 shows that TMDs can be contained by reference
(i.e., by MTNM name) in TPs and TMCs, and that TMCs
can be contained by reference in (i.e., can be pointed to by)
TPs and TMCs of the same ME. The containment of a
TMD in a TP resp. TMC represents the assignment or loading of a service resp. traffic profile and enforces the profile
parameters and their values on the TP resp. TMC.
TP
egress TMD
ingress TMD
TMC-1
eTMD-1
iTMD-1
TMC-1-1
TMC-1-2
...
TMC-2
...
eTMD-2
iTMD-2
Figure 7 Relationships of TPs, TMDs, and TMCs.
The containment of a TMC in a TP enforces traffic conditioning on the TP when the TMC is applicable to the traffic received at the TP. The containment of TMCs in a TMC

11
represents the TMC as a TCB. Similarly TMDs can be contained in TMDs (which is not shown in Figure 7) thereby
allowing for the modular definition of profiles.
For the assignment of a TMD to a TP setTPData() is
used. When a TMD has been assigned to a TP the modification of the TP is not blocked for TP parameters of the TMD
to keep utmost flexibility for different operator roles: some
operators of the service provider can be responsible for
(consistent) TMD management while others are responsible
for manual adjustments and refinements of TP configurations regardless of TMD assignment. As a consequence,
however, TMD assignments can become inconsistent when
one of TMD and TP is modified rashly. To assess the degree of consistency of a TMD assignment on a TP the TMD
state is introduced to the MTNM model. Its transition diagram is shown in Figure 8. Refer to [25] for further details.
The EMS can then, optionally, implement for all or some
TPs an egress TMD state and an ingress TMD state.
NOT_APPLICABLE
setTPData()
with TMD
setTPData()
with TMD
MISMATCH
setTPData()
w/o TMD
PENDING
setTPData()
with null
TMD
TP configuration in progress
APPLIED
setTPData()
w/o TMD
deleteTMD()
or internal fault
TMD_MISSING
Figure 8 State Transition Diagram of TMD State.
A TP represents a resource in a network element that may

be accessed by multiple operators. A TMD is an EMS resource that can be applied to multiple network elements (in
multiple subnetworks). Therefore the determination of current TMD states involves communication steps between the
EMS and network elements when it has to be decided
whether a TMD assignment is consistent. Due to this overhead the TMD states of a TP are not automatically updated
whenever the TP configuration changes but only on request
by the NMS. To this end TMF 814 v3.x specifies the verification operation verifyTMDAssignment().
The configuration of TMCs is quite similar to TP configuration (see Section V.B.). If an ME hosting a TMC belongs to a policy-enabled environment according to IETF
RFC 2753, the TMC can be regarded as a policy enforcement point (PEP). If a service provisioning policy is defined
for the network, or at least for a subnetwork resp. flow domain containing the ME, the policy will contain a set of
rules that express the parameters and range of values that

may be assigned to the TMC. The policy therefore affects
TMC configuration. This impact can be formalized and
automated by first defining traffic profiles that comply with
the policy and then doing TMC configurations only by using these profiles. Refer to TMF053, The New Generation
Operations Systems and Software (NGOSS) TechnologyNeutral Architecture (TNA), with Annexes TMF053C and
TMF053P, the Business Agreement TMF514, EML-NML
Requirements for Management of IP Networks and Services, of TMFs IPNM team, and IETF RFC 3198, Terminology for Policy-Based Management, for more insight into
policy-enabled OSS architectures and policy-based network
management (PBNM) as a key enabling technology.
This important (hence lengthy) subsection showed how
TMF MTNM copes with the complexity of flow-through
service provisioning by separating concerns with the aid of
profile mechanisms. Service and traffic profiles are beneficial to the enforcement of SLA and TCA conformance and
to rapid service provisioning and conditioning on a large
scale, and they can help to plan and organize the network
regarding congestion avoidance and compliance with overall dynamic network performance objectives.
D. PM Points, TCA Parameter Profiles, ASA Profiles
TMF814 v3.x supports further automation features besides service profiles and traffic profiles through new object
types; these are Performance Monitoring Point (PMP),
TCA Parameter Profile (TCAPP), and Alarm Severity Assignment Profile (ASAP).
A PM Point (PMP) represents an access point, identified
by the triple of layer rate, PM location, and granularity, at
which performance monitoring and threshold supervision
are provided for a set of PM parameters. It is contained by
name in a TP or TMC. The PMPs contained in a managed
object constitute its PM capabilities and encompass all the
PM relevant data related to it. The attributes of a PMP are a
list of PM parameters, which the PMP is capable to support,
together with all their PM thresholds, a monitoring state
showing whether performance monitoring is enabled or
disabled, and a supervision state showing whether threshold
supervision is enabled or disabled. The attributes of a PM
threshold are threshold type, trigger/clear flag, value, and
unit. Refer to the HTML document _performance.html of
[1] for details of MTNMs PM model.
A Threshold Crossing Alert Parameter Profile (TCAPP)
stores a set of TCA parameters for a single layer rate. The
attributes of a TCA parameter are PM parameter, PM location, granularity, and PM threshold. It is contained by name
in an ME. It is assigned to a TP or TMC (of its containing
ME) by writing its name into the transmission parameter
TCAParameterProfilePointer at the TCAPPs layer rate.
With TCAPPs the thresholds of PMPs can be configured in
an automated way and on a large scale similar to the configuration of TP and TMC parameters with TMDs.

12
An ASAP parameter is an association of an alarm type,

identified by a Probable cause value, and a perceived severity, identified by an Alarm status value. An Alarm Severity Assignment Profile (ASAP) represents a (complete)
list of ASAP parameters. ASAPs are contained in the EMS.
Optionally, ASAP parameter values can be composed of
three Perceived severity values where the first resp. second
resp. third value refers to the context-dependent case that
the Probable cause identifies a service affecting resp. not
service affecting resp. service independent alarm type (see
Section 6.3.2 and Section 6.5.4 of [9]). An ASAP can be
assigned to any object that is potentially able to raise alarms
except AID (i.e., EMS, ME, PTP, CTP, FTP, TPPool, GTP,
TMC, SNC, TL, EQP, EQPH, PGP). It is assigned to the
object by writing its name into the additional info parameter
ASAPpointer. If the object has layered transmission parameters, an ASAP can also be written to a layer by using
the transmission parameter ASAPpointer. An ASAP assignment enforces, as a rule, perceived severities for all emitted
alarms according to the ASAP. For further details and the
rich behaviour and benefits of ASAPs see [26].
E. Further Features and Interface Design Paradigm
Refer to TABLE 2 and the bullet list after TABLE 2 as well
as TMF513 [4] for further TMN functionality supported by
TMF MTNM. Regarding the presented, referenced, and
emerging TMN features of TMF MTNM it is important to
point out particularly that TMF MTNM uses a unique TMN
interface design paradigm not found anywhere else (including ITU-Ts coarse-grained CORBA framework) to achieve
genuine multi-technology and multi-vendor capability.
This astounding paradigm for the development of new
TMN objectives can be summarized as follows:
TABLE 3 INTERFACE DESIGN PARADIGM OF TMF MTNM
clarify G.805/G.809 layering for each technology to be

supported at the interface (see Section III.); introduce and
document new transmission layer rates if required
specify multi-layer encapsulations of managed objects

(see Section IV.B. and layers.pdf of [1]); introduce new
diagrammatic conventions as well as documented new TP
and MLSN layering varieties if required
assign the new objectives to MTNM managed objects;

introduce new managed object types if the existing types
cannot meet the new objectives or the new objectives and
existing types go together only uneasily; extend existing
object types if it seems advisable and an efficient MTNM
extension mechanism is available (see Section VII.C.)
try to assign every new MTNM managed object class

to some existing managing CORBA object (faade) since
MTNM faades are intentionally meant to manage groups
of several related object classes; introduce new managing
objects only for the management of vendor-specific or
completely new groups of managed object classes
specify MTNM names for the new managed object

classes and, if applicable, extensions to existing ones
model new behaviour of existing managed objects and

behaviour of new managed objects through operations of
existing or new CORBA faades; try to keep operations
technology-independent since technology-specific issues
are meant to be placed inside managed objects as attribute values (and not attribute names), especially as parts of
MTNM names, within multiple transmission layers, and
as additional info parameters
for the existing and new transmission layers involved

in the new objectives, specify new transmission parameters or the use of existing parameters
for objectives not yet modelled otherwise, define additional info parameters of appropriate managed objects
Note that this paradigm does not require to start with a

full fine-grained design (which would be thrown away
later) but only to develop the managed object structures
(CORBA IDL structs), which correspond to CORBA value
types in fine-grained designs, including the encoding of
technology-specific and semantic issues as transmission and
additional info parameters (see also Section VI.). Moreover,
transmission and additional info parameters are name/value
pairs with string values and so are easy to standardize and
to bring into XML format for externalization. As a matter of
fact, just the technology independence of TMF814 CORBA
IDL makes TMF814 multi-technology capable.
For example, in TMF MTNMs performance management model technology-specific issues are encapsulated at
the very bottom in layer rates and their PM parameters, and
the MLSN Manager and its managed object classes MLSN
and SNC apply to any connection-oriented technology.
VI. INTEGRATION OF SPECIFIC TECHNOLOGIES
According to TMF MTNMs interface design paradigm
(see TABLE 3) technology-specific issues are encoded as
MTNM name values, multiple transmission layers and their
parameters, and, as an alternative, additional info parameters. All these attributes are strings or name/value pairs with
string names and values. Therefore it is straightforward, in
principle, how to integrate into TMFs MTNM information
model technology-specific layered architectures and management details specified somehow by other standards development organizations (SDOs)4. As a rule technologies
with many layers (e.g., SDH/SONET, OTN/DWDM) result
in quite sophisticated MTNM name structures with few
transmission parameters while technologies with few layers
(e.g., ATM, DSL) lead to fairly comprehensive transmission and traffic parameter sets.
It is important to point out that the standardized TMF
MTNM clearly cannot consider equipment-specific issues
4
(e.g., IEEE, IETF, ATMF, DSLF, FRF/MPLSF, MEF, OIF, Parlay

Group/3GPP, MSF, ETSI, T1M1, Telcordia/Bellcore, OSS/J, JAIN)

13
and other vendor-specific details. These items should be the

core part of a mandatory vendor supplement to TMF814.
But TMF MTNM gives the overall multi-vendor framework
for those unavoidable vendor-specific extensions thereby
making TMF814 genuinely multi-vendor capable. Due to
the interface design paradigm the specification work by
vendors should consist mainly of name/value pair agreements and so is achievable with minimum effort.
A. PDH, SDH, SONET, OTN, ATM
TMF MTNM v2.1 masters the traditional technologies
summarized in TABLE 1: PDH, SDH, SONET, OTN, ATM.
Beginning in v3.0 with inverse multiplexing, point-to-point
Ethernet, and DSL, further technologies will be added step
by step according to the interface design paradigm.
B. Inverse Multiplexing, Ethernet, DSL
Figure 9 shows the point-to-point Ethernet model with
virtual concatenation over SDH/SONET of TMF814 v3.0
(see [27]). Virtual concatenation and IMA (see Figure 6)
both represent a kind of fragmentation, i.e. an inverse
multiplexing adaptation to some signal, and therefore use
LR_Fragment as characteristic layer rate. It represents the
association of a fragmentation TP with contained fragment
CTPs at the server side. The use of server layer containment
with LR_Fragment as characteristic layer is the TMF
MTNM Inverse Multiplexing Model. It is G.805-compliant.
LR_Ethernet
cost-optimized fashion PDH services by circuit emulation

over Gigabit and 10 Gigabit Ethernet and to offer (virtual)
private line and (virtual) private LAN Ethernet services.
Standardization work on Ethernet network architecture
and services is in progress in MetroEthernet Forum (MEF)
and ITU-T SG 15. MEFs Metro Ethernet Network (MEN)
Architecture Framework (see [29]) and ITU-Ts Ethernet
Layer Network Architecture (G.ethna, see [30]) both apply
ITU-T G.809 (see [20] and Section III.) to LR_Ethernet
thereby defining Ethernet flow points, flow domains, flow
domain flows, and VLAN flows. TMFs MTNM team will
use this basic work to introduce Ethernet bridging and
VLAN in TMF814 v3.x and align MEFs EMS-NMS information model (see [12]) with TMF MTNMs CORBA information model (see Section IV.) and TMF IPNMs information model (TMF611, see Section VI.H.). Refer to Section VI.I. for some preliminary details.
Figure 10 shows TMF MTNMs DSL reference model
with ATM support. TMF814 v3.x defines MTNM models
for DSL lines (with autonomous, integrated, and unmanaged TU-Rs), transmission layer rates for DSL technology,
probable cause identifiers for alarms raised by these layers,
use cases for DSL line provisioning, transmission parameters for ADSL, SHDSL, and VDSL (i.e., the current/readonly and desired/configurable characteristics of these basic
DSL types), DSL states and statuses, DSL maintenance
operations, and DSL performance parameters (see [28]).
LR_Ethernet
LR_Encapsulation
LR_DSR_Gigabit_Ethernet
Fragmentation
adaptation
LR_PHYSICAL_ELECTRICAL
LR_Fragment
LR_Fragment
downstream
DSL TU-C
(Transceiver Unit
at the Central office)
- or -
LR_ATM_NI
DSL TU-O
LR_STS3c_and_AU4_VC4
upstream
LR_STS3c_and_AU4_VC4
LR_DSL
PTP
LR_Section_OC12_STS12_and_RS_STM4
LR_DIGITAL_SIGNAL_RATE
ATM Link
TL
(Transceiver Unit at the

Optical network unit)
LR_Line_OC12_STS12_and_MS_STM4
CTP
DSL TU-R
(Transceiver Unit
at the Remote site)
DSL Line
TL
LR_DIGITAL_SIGNAL_RATE
CC
LR_OPTICAL_SECTION
physical
interconnectivity
LR_PHYSICAL_OPTICAL
local DSL PTP (aEndTP)

(on plug-in unit of DSLAM or MSAP)
remote DSL PTP (zEndTP)

(e.g., on DSL modem at CP)
Figure 9 Gigabit Ethernet Port in an SDH/SONET NE.

Figure 10 DSL Reference Model with ATM Support.
LR_Ethernet represents a (non-)continuous flow of
IEEE 802.3 MAC frames, without or with header tag field

for user priority tags and VLAN tags, above a digital signal
rate (DSR) layer of some Ethernet capacity (LR_DSR_Fast_
Ethernet, LR_DSR_Gigabit_Ethernet, ...), and LR_Encap
sulation represents encapsulation protocols (e.g., GFP).
While enterprise LANs have Fast and Gigabit Ethernet
links and WANs achieve Terabit speeds across 10 Gigabit
DWDM channels, metropolitan area networks often have
PDH links. Optical Ethernet in MANs with small, large,
and carrier-class Ethernet bridges promises to replace in a
G.997.1 specifies mandatory and optional configuration

parameters as well as read-only diagnostic parameters for
the PMD sublayer of ADSL lines (G.992.1, G.992.2,
G.992.3, G.992.4, and G.992.5) in a protocol-independent
way. RFC 2662 and RFC 3440 specify managed objects for
ADSL lines in SNMPs SMI syntax having many G.997.1
parameters as attributes and also further attributes. DSL
Forums TR-041 and TR-050 (see [11]) specify CORBA
IDL structs and valuetypes whose attributes represent some
G.997.1 and RFC 2662 resp. RFC 3440 parameters.

14
Many ADSL parameters apply to other DSL types as well

but with different value ranges. RFC 3276 specifies an
SNMP MIB for managing SHDSL lines with zero or up to
eight regenerators. DSL Forums TR-057 and IETFs draftietf-adslmib-vdsl-09 specify managed objects for VDSL
lines. There is also further ongoing work by DSL Forum,
IETF, and ITU-T on VDSL line management.
TMF MTNM standardizes a fairly large subset of these
ADSL/SHDSL/VDSL parameters as transmission parameters of the universal DSL layer LR_DSL (see [28]).
C. AAL, CE, FR, Channel Groups
The ATM adaptation layer (AAL) is the upper ATM path
layer that translates higher layer services into the size and
format of an ATM cell. Examples of such services are
POTS or ISDN BRI voice services, and Frame Relay or
Ethernet or Transparent HDLC data services (see Section
VI.D.). The AAL functions depend on the service type. The
AAL inserts resp. extracts information into resp. from the
48-byte payload that makes up the ATM cells, i.e. it adapts
the characteristic information of its service layer(s) to ATM
characteristic information. It assures the appropriate service
characteristics according to the AAL type used.
ATM Forum and ITU-T specify four AAL types: AAL1
for connection-oriented constant bit rate services with timing, and with loss and error indication; AAL2 for bandwidth-efficient connection-oriented real-time or non realtime variable bit rate services with high delay sensitivity,
and with loss and error indication; AAL3/4 for connectionoriented/connectionless variable or available bit rate services with delay tolerance and with sophisticated delivery
assurance; AAL5 for connection-oriented and connectionless variable or unspecified bit rate services with delay
tolerance, and with minimal delivery assurance.
The AAL leaves a footprint in the ATM payload whose
size depends on the AAL type. For example, the lower
segmentation and reassembly (SAR) sublayer of AAL1 and
AAL5 is fully responsible for 1 byte of the AAL-PDU.
TMF MTNM is scheduled to support AAL1 and AAL5
and leave AAL2 and AAL3/4 for further study.
As MTNM managed objects according to Section IV.B.
these AAL types (consisting of type-dependent sublayers)5
are modelled by new CTPs above terminated ATM VC
5
AAL1 has an upper convergence sublayer (CS) and a lower SAR
sublayer while AAL5 has an optional upper service-specific convergence
sublayer (SSCS), a middle common part convergence sublayer (CPCS),
and a lower SAR sublayer. In an AAL1 implementation multiplexing can
be realized by multiple CSes above a single SAR sublayer. In an AAL5
implementation multiplexing has to occur in the SSCS.
RFC 2684 defines two methods for carrying connectionless routed and
bridged Protocol Data Units (PDUs) over an ATM network. The LLC
Encapsulation method, based on IEEE 802.2 Logical Link Control (LLC),
allows multiplexing of multiple protocols over a single ATM Virtual Circuit (VC) while in the VC Multiplexing method, each ATM VC carries
PDUs of exactly one protocol type. When multiple protocols need to be
transported, there is a separate VC for each.
CTPs, namely AAL Interface (IF) CTPs (new layer rate)6

and AAL user port CTPs at service-specific layer rates (e.g.,
POTS, ISDN BRI, Fast Ethernet, DSR), in compliance with
applicable specifications by ITU-T and ATM Forum. AAL
IF CTPs include the possibility of AAL interworking, i.e.
an AAL IF CTP may represent an AAL interworking function (IWF) at CP side or CO side. In cases where there is
only one user of the underlying VCC just one enhanced
ATM VC CTP is modelled, called AAL VC CTP, that encapsulates ATM VC, AAL IF, and AAL user port layers.
In cases of multiple users of the underlying VCC, AAL
user ports need to be modelled that are service/subscriber
access points (SAP) and reflect the multiplexing capabilities
of the AAL, and then there is the choice to design either a
separate AAL IF CTP, or an AAL VC CTP without user
port layer. The AAL IF CTP should be used in cases where
true interworking takes place (e.g., exchange of HDLC
messages across a dedicated signalling channel). Also in
cases of multiple users, a key design issue will be the
choice of the way of AAL multiplex channel allocation to
user ports, which may be either static (e.g., plain AAL1) or
dynamic (e.g., AAL2 with ELCP) to allow overbooking of
subscribers. The user ports bundle the needed AAL channels per SAP and hide dynamic multiplexing.
Circuit emulation (CE) of PDH signals into ATM VCCs
is modelled already in TMF814 v2.1 (see Figure 11 and
Section C.4.3.3/Figure 20 of layers.pdf of [1], where the
AAL is missing, however): the PDH signal is transmitted to
and received from a contained non-client CTP (AAL VC
CTP of type AAL1) unterminatedly.
PTP (of kind B) with layers
CTP (of kind F) with layers
LR_E1_2M (Encapsulated CP)
LR_E1_2M (Encapsulated CP)
LR_DSR_2M
LR_ATM_AL
LR_ATM_VC
Figure 11 Unstructured E1 PTP that Adapts to ATM.
While ATM offers two multiplexing levels for PVCs and

ATM cells are identified through their 8-bit VPI and 16-bit
VCI, Frame Relay (FR) offers just one PVC multiplexing
level and FR frames or packets are identified through their
10-bit Data Link Connection Identifier (DLCI). The configuration of an FR card consists of two steps. First the
6
The name ATM adaptation layer leads one to believe that the AAL
does only adaptation work but no trail termination. This is not true despite
the name. There can well be peer-to-peer operations between the end
points of an (extended) AAL connection. The AAL allows for interworking between an AAL IF CTP on CP side and another one on CO side. Such
an AAL connection can be terminated at CP side but stay unterminated and
get extended on CO side through termination of the underlying VCC but
not the AALxC. Instead the AAL channels are terminated after circuit
emulation of the terminated VCC into TDM signals.

15
ports (e.g., T1/E1) are configured in either unchannelized

mode, which can be fractional (e.g., n*DS0) or not, or
channelized mode, which allows for the definition of channel groups (see below). Then for each unchannelized port
and each channel group an FR interface is configured which
defines the entrance to the FR network.
Due to the similarities between FR and ATM an FR IF
CTP and an FR PVC CTP, identified by its DLCI, are
scheduled for TMF MTNM that are modelled in the same
way as the ATM NI CTP and the ATM VC CTP. Figure 12
depicts the layer and TP hierarchy for an unstructured E1
PTP that supports Frame Relay.
CTP (of kind C) with layer

LR_FR_IF
PTP (of kind A) with layers

LR_E1_2M
LR_DSR_2M
Figure 12 Unstructured E1 PTP that Adapts to FR.
When using some emulation service or interworking

function to transport voiceband circuits or data services
over ATM, a major concern is the optimized usage of the
available bandwidth. Switched voice services (POTS,
ISDN-BA) are transmitted within DS0 channels that carry
signalling information or bearer information (see Section
VI.F.), and leased line services are transmitted within
n*DS0 or 1.544 Mbit/s (T1) or 2.048 Mbit/s (E1) channels
or even T3/E3 channels. Data services such as FR may be
captured at DSR ports (e.g., X.21, V.35) with a configurable bandwidth between 56 kbit/s and 2.048 Mbit/s, say, or
may also start at the end of n*DS0 or T1/E1 channels.
CTP (of kind D) with layer
LR_DS0_64K
* 32
PTP (of kind A) with layers
LR_E1_2M
LR_DSR_2M
Figure 13 Structured E1 PTP.
The most widely used tributary ports for CE and FR are

T1 PTPs and E1 PTPs. These ports can be configured to be
either unstructured or structured. Figure 13 shows the structuring of an E1 PTP into 32 DS0 CTPs.
CE terminology uses the terms unstructured data transmission (UDT) mode resp. structured data transmission
(SDT) mode if the underlying PTP is unstructured resp.
structured while FR terminology talks about unchannelized
FR resp. channelized FR. The single channel of an unstructured T1/E1 PTP may also be used to transmit transparently
a single fractional n*DS0 signal together with a time slot
mask that indicates the used and idle time slots thereby reducing the VC CBR of CE and the FR IF bandwidth.
To allow multiplexing of TDM and FR traffic without
idle time slots ATM network elements offer CE boards
(CEBs) for TDM and data boards (DABs) for FR that allow
for the configuration of channel groups. Every channel
group is free-configurable and composed of a number of
DS0 time slots of usually the same T1/E1 port. It functions
as a unit of work for connection management and can be
considered as the end point of a virtual channel that is contained in the physical T1/E1 link. Since all time slots can be
assigned to some channel group no idle time slots need exist. Just as IMA speeds up data transmission by dividing an
ATM cell stream into multiple concurrent streams that are
transmitted at the same time across separate channels and
then reconstructed at the other end back into the original
data stream, channel groups allow to multiplex/de-multiplex
TDM and FR traffic to/from a physical T1/E1 link. The
channel group takes the role that the PTP has in case of
UDT mode resp. unchannelized FR, i.e. the channel group
may transmit/receive its payload to/from a non-client CTP
(e.g., an AAL VC CTP) resp. a client CTP (e.g., an FR IF
CTP). But it could also be connected by an SNC to another
channel group in order to establish a bundled SNC.
For TMF MTNM it is scheduled to model channel groups
as group TPs (GTPs) that will be introduced in TMF814
v3.0 for bundled SNC management.
D. CES, ATM-FR Interworking, Ethernet-over-ATM
To enable TDM-over-ATM the narrowband and broadband TDM services have to be adapted so that they can be
transported across the ATM infrastructure without reduction in quality. The most important adaptation procedure is
the AAL1-based Circuit Emulation Service (CES) defined
by ATM Forum for permanent T1/E1 services, unstructured
or structured, and unstructured T3/E3 services (see AFVTOA-0078). TMF MTNM is scheduled to support CES
through PDH port configuration for UDT mode and channel
group configuration for SDT mode, as well as AAL1 provisioning of an enhanced ATM VC CTP. This amounts to the
definition of appropriate transmission parameters. The support of DBCES that enhances CES (and AAL1) with detection and reutilization of inactive time slots (AF-VTOA0085) and the AAL2-based Broadband Loop Emulation

16
Service (BLES) (AF-VMOA-0145/0175, DSLF TR-039)

for all types of voiceband services are for further study.
TMF MTNM is further scheduled to support PVC network and service interworking between Frame Relay and
ATM technologies according to FRF.5 and FRF.8.1 respectively. FR-ATM network interworking transports the FR
PVC within the ATM PVC and the user data of the service
layer that has been adapted to FR are transported entirely
transparently. In case of FR-ATM service interworking the
user data of the service layer and control information are
adapted to ATM. The FR PVC network interworking with
ATM will be similar to CE: the FR PVC CTP contains an
AAL VC CTP as a non-client CTP and transmits to/receives
from it the FR payload unterminatedly; inside the AAL VC
CTP AAL5 is used to adapt the FR packets to ATM; the
AAL VC CTP is cross-connected to a core ATM VC CTP
at network side (ATM transport assembly). In case of FR
PVC service interworking with ATM, an SNC has to be
established on the respective service layer.
TMF MTNM v3.0 includes the layered modelling of Fast
and Gigabit Ethernet over TDM and DWDM without or
with fragmentation (see Figure 9). The same layered model
can be adopted for Ethernet-over-ATM. The digital Ethernet
signal of an Ethernet PTP (e.g., LR_DSR_Fast_Ethernet) is
transmitted to/received from a contained non-client CTP
unterminatedly. When no fragmentation is required this is
the same model as for unstructured CE (see Figure 11), i.e.
the non-client CTP is an AAL VC CTP, only that AAL5
and RFC 2684 (see Footnote 5) are used instead of AAL1.
When fragmentation is required the non-client CTP has
server-side CTPs whose lowermost layer is ATM VC.
E. Access Network Scenario for VoATM and VoDSL
Access networks undergo changes. The insatiable demand for bandwidth and the shortcomings of synchronous
connections (that reserve bandwidth for the entire duration
and get many unexhausted time slots) have lead to a supplementing or even a substitution of traditional TDM-based
access technology by a common ATM-based infrastructure
that is gradually further enhanced by MPLS and Ethernet
capabilities. DSL technology is being used to provide highspeed connections of the ATM channels and Ethernet links
to the subscribers and inverse multiplexing techniques contribute to the cost-effective exploitation of the existing
transport network infrastructure (see Section VI.B.).
The techniques used to transport voice and data in an integrated way over DSL - whether ADSL or SHDSL or
VDSL - are referred to as Voice over DSL (VoDSL). It refers to any technique that transports voice, data, and video
over the DSL physical layer protocol on a twisted copper
pair using packetized solutions (VoATMoDSL or VoIP
[oATM]oDSL) but not channelized solutions (VeDSL or
CVoDSL). Figure 14 shows a typical broadband access
network scenario with ATM and DSL technology.
Cascade
IAD
ISDN
IMA
DSL
Internet
access
ATM-XC
DSL
Video
ATM
AMGW
PSTN
DSLAM
IAD
Frame Relay
POTS
IMA
DSLAM
IAD
DSLAM
IAD
IP
IP
BRAS
DSL
ISDN
LAN
Interconnection IAD
IP
Service (LIS)
POTS
SDH
DSLAM
ISDN
PBX access
(S2M/V2M)
ATM-XC
IAD
voice
TDM / CES
MSAP
data
voice and data
ATM
Frame Relay
TDM
OTN/DWDM
Figure 14 Network Scenario for VoATM and VoDSL.
The scenario offers narrowband TDM services (POTS,

ISDN-BA, permanent E1/T1, PBX access, etc.), plain or
ADSL-split, and broadband voice, data, and video services.
It shows the following NEs and traffic streams:
multi-service access from customer premises (CP)
equipment (Integrated Access Devices and narrowband
Network Terminations) across unshielded twisted pairs
(UTPs) (local loop or last mile) to the central office (CO)
at the CO access nodes (multi-service access platforms
(MSAPs) or plain DSLAMs) that bundle voice-grade
channels or ATM cell streams (that may contain data traffic from IADs as well) into higher-rate signals towards
the SDH or ATM backbone transport network; IMA
technology can be used to cascade DSLAMs
ATM cross-connects (ATM-XCs) that are optionally
located at the edge of the access network for high
concentration and grooming of the ATM traffic
from the backbone the voice traffic is directed to the
access voice or media gateway (AMGW) that translates
the ATM signals to a local exchange (LE) in the public
PSTN network by using a voice signalling interface in
case of switched circuits, while the data traffic is routed
to the ATM backbone network or, by a Broadband Remote Access Server (BRAS), to an Internet service provider or to a data network of some other type
TMF MTNM supports e2e network connections (and
flows) that comprise multiple technologies and transmission
layers but is not meant to support telecommunication services directly. However, to be useful for a particular TMN
domain the e2e connection (and flow) support must include
all technologies needed for domain-specific services. For
VoATM and VoDSL this means that TMF MTNM needs to
facilitate the provisioning of SNCs (and FDFs) for
transport and signalling of narrowband TDM services
(see Section VI.F. below)
transport of TDM-based services, switched or permanent, over ATM (CES and BLES, see Section VI.D.)
transport of data and video services across an ATM
infrastructure that includes IMA and DSL (see Figure 5,
Figure 6, Figure 10, Section VI.C., Section VI.D.)
The need for standardization of these transport and signalling capabilities derives from the requirement to enable

17
seamless integration of TMF814-based EMSes into multivendor and multi-technology management environments for
VoATM and VoDSL networks.
F. Provisioning of Switched Voice Services
The access domain is concerned with integrated multiservice access from end customer premises equipment
(CPE) to collocations and central offices, and one of the
most important subscriber service types is voice services.
These are the PSTN services that may be either switched
dial-up circuits (POTS or ISDN-BA or ISDN-PRA) on the
twisted-pair telephone copper wire, also known as local
loop or last mile, or permanent leased line (LL) circuits that
may be accessed via the local loop as well. If the last mile
access is by plain or ADSL-split POTS or ISDN the service
is called narrowband (NB), and if it is through an Integrated Access Device (IAD) that uses DSL technology (as a
remote transceiver unit) it is called broadband (BB).
Having got over the last mile the service reaches an optical network unit (ONU) that bundles the voice-grade channels or ATM cell streams into higher-rate signals towards
the SDH or ATM backbone transport network. From the
backbone the traffic is directed to the optical line termination (OLT) that translates the PDH or SDH or ATM signals
to a local exchange (LE) using a voice signalling interface
in case of switched circuits. In Figure 14 the DSLAMs and
MSAPs are the ONUs and the AMGW is the OLT. For the
current scope the transmission of broadband services is always completely ATM-based, namely VoATMoDSL between CPE and ONU, and VoATM between ONU and
OLT. The transmission of narrowband services between the
ONU and the OLT can be either PDH-based and/or SDHbased (Classic Voice)7 or ATM-based (VoATM). Within the
New Generation Access Network the OLT can be extended
by ATM switches and additional gateways (e.g., BRASes)
to an integrated access termination (IAT) that terminates or
redirects the non-voice services, too.
Voiceband services include call and service control functions as well as bearer and bearer control functions. Call
control is achieved by signalling mechanisms based on a
dedicated signalling protocol. The most important voice
signalling interfaces between an Access Network (AN) and
the Local Exchange (LE) are V-interfaces with Common
Channel Signalling (CCS) (see ITU-T Q.512). There are the
E1-based European signalling types V5.1 (see ITU-T
G.964, ETS 300 324-1) with a single E1 link and V5.2 (see
ITU-T G.965, ETS 300 347-1) with up to 16 E1 links, and
the T1-based North American signaling standard GR-303
(see http://www.telcordia.com/resources/genericreq/gr303/)
with up to 28 T1 links. Every E1/T1 link is channelized by
TDM into 32/24 voice channels with DS0 capacity that are
configured to be either bearer channels or common signalling channels. In case of Classic Voice these interfaces are
also used at the subscriber side, while for VoATM the
7
POTS and ISDN signalling and bearer channels and the LL

channels (E1, n*DS0, E3) are directly adapted to ATM cells
via AAL2 (BLES) or AAL1 (CES).
TABLE 4 shows how to map V5 signalling objects to
MTNM managed objects. A similar table can be compiled
for GR-303. It is shown that no new managed object classes
need to be introduced. A V5 interface is an FTP, as introduced with TMF814 v3.0, that contains (logical) c-channels
at the server side and user ports at the client side. The V5
model therefore corresponds to the IMA model where the cchannels are IMA links and the user ports are VP CTPs (see
Figure 6). The TDM traffic of a V5 interface is transmitted
to and received from assigned V5 links, which are structured E1 PTPs (see Figure 13) or CTPs. The DS0 client
CTPs of the V5 links that carry signalling information are
the physical c-channels of the V5 interface. They correspond to the supporting CTPs of IMA and are crossconnected to c-channels of the V5 interface. The remaining
DS0 client CTPs of the V5 links represent bearer channels.
TABLE 4 V5 SIGNALLING OBJECTS OF TMF MTNM
V5 Object
MTNM Object
V5 interface
FTP with upper layer LR_V5_IF

and lower layer LR_FRAGMENT
PTP or CTP with upper layer LR_E1_2M
DS0 CTP contained in a V5 link
and carrying signalling information
CTP with layer LR_POTS or LR_ISDN_BRI,
contained in a V5 interface at its client side
CTP with upper layer LR_FRAGMENT
and lower layer LR_COMM_CHAN,
contained in a V5 interface at its server side
third-level object embedded in a c-channel
and specifying common signalling information
V5 link
physical V5
c-channel
V5 user port
V5 c-channel
V5 c-path
The provisioning of V5 interfaces includes the provision

of V5 c[omm]-channels. Such a c-channel represents a time
slot on a V5 link where, for one or several V5 user ports,
signalling information is transferred. The exact usage of a
c-channel is specified by the concept of a V5 c-path that
represents a certain type of signalling information, from one
or more subscribers (represented by V5 user ports), to be
conveyed over a V5 interface. A c-channel is provisioned to
carry one or more c-paths, all of different types. This leads
to another partitioning of c-channels into logical sub-timeslots besides the subscriber-related partitioning, which
needs not be represented in TMF MTNM, however.
The following V5 c-path types can be distinguished:
PSTN signalling information for POTS

ISDN D-channel signalling (Ds-type) data (i.e., the
SAP identifier (SAPI) of the link access procedure on
the D-channel (LAPD) (see ITU-T Q.921) is = 0 or 63)
ISDN packet (p-type) data (LAPD SAPI = 16)
ISDN frame (f-type) data (LAPD SAPI = 32 to 62)
Classic Voice with its ONUs and OLTs is not shown in Figure 14.

18
a vital protocol (i.e., a signalling protocol that is mandatory for the correct interworking between V5 interfaces
at AN-side and LE-side), namely any one of
common control protocol
port control protocol
bearer channel connection (BCC) protocol
link control protocol
protection of a vital protocol
protection of a non-vital protocol
From the viewpoint of (cross- or e2e-) connection management not bearer channel connections above V5 links but
user port connections (UPCs) are provisioned (at layer rate
LR_POTS or LR_ISDN_BRI) thereby hiding the transfer
details of signalling information. In case of Classic Voice
you have V5 user ports at both ends while in case of
VoATM there is an AAL user port at the AN-edge and a V5
user port at the LE-edge of the network element (AMGW)
or MLSN. Like an AAL connection (see Section VI.C.) an
UPC can be dynamic (i.e., uses dynamic channel allocation
to user ports) to allow overbooking of subscribers.
Though the current scope of broadband services is ATMbased it is important to point out that the same model applies for other transmission technologies between the ONU
and the OLT. It applies in particular to the case of IP transmission when the ONU becomes a genuine Access Gateway
(AGW) that is capable of VoIP processing. This is true as
far as VoIP is still based partly on V5/GR-303 technology.
However, the second generation of VoIP processing will no
longer need the TDM-based V5/GR-303 technology but
become purely IP- and Ethernet-based. But since the characteristic voice information at the edges of the NGN, coming from POTS and ISDN-BA PTPs, remains unchanged, it
seems not unlikely that V5/GR-303 might be translated
from TDM to IP, e.g. by means of MPLS constructs.
The modelling of first and second generation VoIP in
TMF MTNM terms is currently under study by TMFs
IPNM team (see Section VI.H.).
G. Dynamic Connection Provisioning (ASTN)
An automatically switched transport network (ASTN) encompasses a signalling network that supports a control
plane for the set-up, release, supervision, and maintenance
of network connections (NCs). Examples are Classic Voice
or VoATM networks with fully configured V5/GR-303
interfaces (see Section VI.F.) or ATM networks with SVC
and/or SPVC capabilities (see I.150, Q.2766.1/Q.2767.1).
Experiences with the provisioning of switched connections
for these networks might be useful for dynamic connection
provisioning in the ASTN/ASON problem space.
The control plan supports network connection set-up/
teardown as a result of a user request (SC) or a management
request (SPC), re-establishment of a failed connection by
restoration (i.e., rerouteing using spare capacity), protection
(i.e., enhancing availability through the use of additional
capacity), and resilience (i.e., continuing operation under
failure conditions). A call is a signalling association between one or more user applications and the network to
control the establishment of sets of connections. Call control must provide co-ordination of connections (in a multiconnection call) and co-ordination of parties (calling party
and called party or parties). ITU-T G.8080 [19] introduces
the term subnetwork point (SNP) to represent in the control
plane an actual or potential underlying CP (or CTP) or an
actual or potential TCP (or TTP) of the transport plane (see
Figure 2). Several SNPs (in different subnetwork partitions
of the control plane) may represent the same TCP or CP.
An SNP has an SNP state that takes one of four values:
Available, Potential, Provisioned, Busy.
A static relationship between two SNPs in different
subnetworks is referred to as an SNP link connection (SNP
LC), and a dynamic relationship between two or more SNPs
at the boundary of the same subnetwork is simply referred
to as a subnetwork connection (SNC). ITU-T G.807 [18]
introduces the terms address and name with respect to globally unique sources and destinations. An address is a string
that is source-independent and changes if the destination
moves. It is used for the purpose of routeing in the control
plane. A name, or identifier, is a location-independent string
with respect to both a source and a destination. If it is the
name of a destination, it remains unchanged if the destination moves and is valid regardless of associated sources.
The extent to which names are unique is for further study.
ITU-T Rec. G.807 further introduces the term interface to
represent a logical relationship between ASTN control
plane entities in support of different equipment implementations and network architectures. Interfaces are defined by
the information flow between the entities, and the flow
elements can be aggregated to form three types of reference
points consisting of one or more logical interfaces: UserNetwork Interface (UNI), Internal Network-to-Network Interface (I-NNI), External Network-to-Network Interface (ENNI). The UNI is a bidirectional signalling interface between service requester and service provider entities. The INNI is a bidirectional signalling interface between entities
belonging to one or more domains having a trusted relationship (e.g., within the same subnetwork). The E-NNI is a
bidirectional signalling interface between entities belonging
to different domains (e.g., between different subnetworks).
The attributes of these interface types are specified in detail
in ITU-T Rec. G.7713. Many are control plane names.
The NNI exchanges explicit routeing and recovery information while the UNI requires some security information
from a peer entity. The UNI is generally used between untrusted administrations (i.e., two interconnected networks
from a single carrier managed by two independent business
units). The I-NNI may be used in a single EMS domain
while the E-NNI may be used between EMS domains. The
interfaces differ in the level of topology information that
peer nodes are willing to exchange over the interface (i.e.,
in the level of trust between peer networks). As the UNI is

19
used between untrusted interface networks, there is no topology information exchange. The I-NNI allows the exchange of complete topology information while the E-NNI
allows the exchange of limited topology information.
ITU-T Rec. G.7713, Distributed Call and Connection
Management (DCM), specifies three operational procedures
that have to be completed for the establishment of a call:
call setup request

establishment of SNP LCs by allocation of SNPs
(i.e., by bringing peer SNPs from SNP state Available
to SNP state Provisioned)8
set-up of control plane SNCs between actual SNPs
Figure 15 shows the relationships between the control

plane call, the NC in the transport plane, and a representation of the NC in the management plane in MTNM terms.
Domain A
Client
UNI
Connection
Control Plane
Domain B
E-NNI
UNI
Subnetwork
Connection
E-NNI
Connection
Client
Subnetwork
Connection
UNI
E-NNI
Connection
Subnetwork
Connection
TL 3
LC 3
MLSN C
SNC c
UNI
Connection
Network Connection
(SC, SPC)
Transport Plane
MTNM Model
Domain C
E-NNI
TL 1
LC 1
MLSN A
SNC a
TL 2
LC 2
MLSN B
SNC b
TL 4
LC 4
Figure 15 Control Plane Call, NC, MTNM Connection.
Note, however, that the MTNM information model currently does not include link connections and so MTNM
cannot manage topological link capacity. A corresponding
proposal to add an LC managed object that is contained in a
TL just as an SNC is contained in an MLSN (see [31]) has
not yet been discussed by the MTNM team.
TM814 v2.1 already includes some means that are well
suited for SC and SPC management, e.g. network routed
SNCs and a naming convention for off-network TPs and
TLs based on remote addresses. In case of ATM there are
SVC-related transmission parameters and SPVCs can be
provisioned as network routed SNCs with aEnd being the
calling party and zEnd being the called party/parties.
In the course of its liaison with OIFs OAM&P working
group and as core part of the TMF814 v3.x evolution,
TMFs MTNM team has begun studies regarding enhancements of SNC management in support of dynamic connection management. As a first result the SNC managed object
will be enhanced by the additional info parameter Corre
lationID that contains information about relationships
that the SNC may have to other objects (e.g., an NC and a
call). When relating the SNC to MTNM objects or control
plane objects the relationships will be encoded by MTNM
names, which may be off-network, or control plane names.
Scenarios of the type shown in Figure 15 were studied to
some extent with off-network TLs and three EMSes (EMS
8
A, EMS B, EMS C) managing the three MLSNs. It is generally assumed that CTPs can be enhanced by control plan
information, in particular by the control plane names of the
associated SNPs. An NMS that maintains a TMF814 session to each EMS sends the call setup request to the EMS
that manages the port of the calling party and gets notified
from all EMSes about the progression of the call setup. The
NMS may then determine the route of the end-to-end NC
by correlating the received SNC object creation notifications, and even create the corresponding NC at NMS side.
For the call setup request the createAndActiveSNC()
operation of TMF814 v2.1 for a network routed SNC could
be used but there are some issues with the approach. One
issue when fully modelling the control plane is alignment
with the G.7713 operational procedures that requires the
concepts of link connections and component links. Also
further scenarios regarding SPCs and control plane-aware
EMSes have to be considered and new MTNM managed
object classes to represent NCs and calls are required.
Therefore the formal working out of dynamic connection
management is not included in the scope of TMF814 v3.0
but for further study in a further step (ffsfs) v3.x.
H. VoMSDN, IP Services, MPLS, PP VPN, GMPLS
The network scenario shown in Figure 14 differs from
other known descriptions where an ATM switch is used instead of an ATM-XC and a voice gateway (VGW) instead of
an AMGW. ATM switches include the capabilities of
ATM-XCs, i.e. management of ATM cross-connections on
VP layer and VC layer across an ATM bus with very high
throughput (several Gbit/s), but go beyond by offering more
sophisticated switching capabilities (e.g., support of Frame
Relay and Circuit Emulation services, see Section VI.D.,
including channel groups for channelized FR and SDT CE).
These are not needed in the typical VoDSL scenario, however, due to the capabilities of the AMGWs and BRASes.
Figure 14 shows only the first, purely ATM-based step of
the evolution of the TDM-based access network towards the
next generation IP network known as Multi-Service Data
Network (MSDN). When the AMGW is only used as a
VGW in the first step, it is assumed that its roadmap is
scheduled to let it become integrated into future VoMSDN
networks. These networks are moving away from traditional TDM switched networks with CCS or CAS to new
softswitch technologies with the intelligence distributed
over (subscriber and transit) media gateways (MGs) that are
controlled by a media gateway controller (MGC). They
transport voice, data, and video (VDV) via IP packets over
MPLS (VoIP or VoMPLS). The bearer channels are set up
between MGs while signalling channels are set up between
MGs and the MGC by using the MG Control Protocol
(MGCP) of IETFs MG Control (MEGACO) working
group (ITU-T Rec. H.248.1, draft-ietf-megaco-h248v2-04),
thereby turning the VoMSDN network into an ASTN.
When ATM is still present in a VoMSDN network (ATM
SNPs in SNP state Busy or Potential are not available for allocation.

20
NGN), of course the virtual circuits can be not only PVCs,

as in Figure 14, but also SVCs and SPVCs.
In such a VoMSDN network the AMGW is a transit MG
that converts VoATM or VoIP or VoMPLS data to TDM.
The multi-service data arriving at the transit MG is generated at subscriber MGs or access gateways (AGWs) that
correspond to the DSLAMs and MSAPs in Figure 14. Thus
the AMGW evolution is accompanied by the DSLAM evolution towards an MSAP that is a purely IP-based AGW.
The ONUs in Figure 14 generate, or concentrate at least,
the ATM cell streams with bearer and signalling information from input they receive by Customer Premises Equipment (CPE). A CPE can be a multi-service-capable Integrated Access Device (IAD) or a simple Network Termination (NT) (e.g., a DSL modem, a narrowband PSTN device)
or a Customer Premises Gateway (CPG) with an Ethernet
interface. IADs and NTs are directly connected to the ONU
and use DSL for broadband services while CPGs are connected to the ONU through a DSL modem.
The AGWs of VoMSDN networks generate or concentrate the (ATM cell or) IP packet streams from the same
types of CPEs and from additional types. In particular
H.323 entities according to ITU-T Rec. H.323, PacketBased Multimedia Communications Systems, are of great
importance, and even more are SIP-enabled devices according to IETF RFC 3261, SIP: Session Initiation Protocol.
From the viewpoint of network management a CPE is of
one of three kinds (see [28]): either autonomous or integrated or unmanaged. Autonomous CPEs are managed as
stand-alone network elements while integrated CPEs are
managed remotely by some ONU and integrated in their
ONU as managed objects. Managed CPEs allow the service
provider to offer managed services according to the capabilities of the CPE. The service provider may retain ownership of the managed CPE or, alternatively, it may be purchased or leased by the (enterprise) customer.
The all IP MSDN offers service providers and operators a
platform that keeps evolving to create, deploy, and manage
more and more kinds of high-value, high-margin, revenuegenerating IP services. Examples are business-class Internet
access, LAN interconnection service (LIS), secure IP VPN,
VoIP, converged services like IP Centrex, managed bandwidth by class-based queuing (CBQ) or low-latency queuing (LLQ) to provide carrier-grade QoS, network-based
application recognition (NBAR), intranet content hosting,
hosted Web services, CPE-based services, Public Wireless
LAN (PWLAN) based on IEEE 802.11 Wi-Fi, and many
many more. TMF MTNM is never meant to support IP services directly but to be able to establish e2e connectivity for
the IP domain thereby supporting the delivery of IP services. This task is complex due to the various choices of
underlying layer 2 and layer 1 technologies. Moreover, in
the case of CPE-based IP services the service provider
needs to manage CPEs and so the responsible EMS has to
master CPE technologies that packetize/depacketize the
specific service characteristics to/from IP flows and adapt

IP to the respectively underlying transport layers.
Currently TMFs MTNM team focuses mainly on layer 1
and layer 2 technologies and does not have the resources to
study layer 2.5 (MPLS) and layer 3 (IP). Fortunately there
is a companion modelling team on IP Network Management
(IPNM) that takes the MTNM deliverables [4], [3], [1] as a
starting point to develop the BA TMF514, EML-NML Requirements for Management of IP Networks and Services,
the IA TMF611, IPNM NML-EML Interface, Information
Agreement, and the SS TMF8IP, IPNM NML-EML Interface, CORBA IDL Solution Set. TMFs IPNM NML-EML
interface is abbreviated as TMF IPNM in the following.
Given the broad spectrum of IP networks and services,
the TMF IPNM team initially focuses on BGP/MPLS-based
IP VPN (see IETF RFC 2547, ITU-T Rec. Y.1311.1, draftietf-ppvpn-rfc2547bis-03) and MGCP-based VoIP (respectively Open Packet Telephony (OPT)). Besides it is the
teams ambition to study the feasibility of enhancing
TMF814-like EMSes by Policy-Based Network Management (PBNM) principles. Ideally the final specification of
TMF IPNM v1.x regarding IP VPN, VoIP, and PBNM will
be a set of seamless enhancements of TMF MTNM v3.x
similar to MTNMs own Ethernet and VLAN modelling
(see Section VI.B. and Section VI.I.).
An IP service of particular interest to the corporate customers of carrier-grade service providers is the IP-enabled
virtual private network (IP VPN) service. With IP VPN, a
service provider connects two or more IP addresses located
at geographically dispersed customer sites (from private
intranets, branch offices, extranet partners, etc.), which by
virtue of the IP VPN service appear to be within a private
IP network. The customer experiences a private network
service that connects the sites even though traffic actually
flows through a shared (or public) infrastructure operated
by the service provider. The infrastructure is securely partitioned for use by individual users; and the VPN employs
the security, management, and throughput policies of a private network. The benefits of virtual connectivity include
greater reliability and flexibility for the customer, and better
resource utilization for the service provider. In its simplest
form IP-enabling means to seamlessly connect registered
sites on IP layer over the underlying provider network with
agreed grades of service and without the need for the customer to create IP connectivity between the sites. IP VPNs
have therefore occasionally been hailed as the killer application for carrier networks in the 21st century. This is an
exaggeration but IP VPNs are certainly very important due
to the ubiquity of intranets, extranets, and the Internet.
The IP VPN model of RFC 2547bis considers some set of
sites that are attached (e.g., via GSTN services) to a common IP network called the backbone (e.g., a private IP network or the public Internet). From the perspective of a particular IP backbone, a site is a set of (ports of) IP systems
(i.e., hosts or IP routers) having mutual IP connectivity that

21
does not require the use of the backbone (e.g., since they
are in geographic proximity or connected via leased line
services). Some policy is applied to create a number of subsets of the set of sites. Such a subset is called a VPN. By
definition, two sites have IP connectivity over the common
backbone if and only if there is some VPN which contains
both of them. If all the sites in a VPN are owned by the
same enterprise, the VPN is a corporate intranet, and if the
various sites in a VPN are owned by different enterprises,
the VPN is an extranet. A site can be in more than one VPN
(e.g., in an intranet and several extranets). The backbone is
operated by one or more service providers (SPs) and the
owners of the sites are the customers of the service providers. At each site there are one or more customer edge (CE)
devices, each of which is attached via some sort of layer 2
link (e.g., PPP, HDLC, Frame Relay, ATM, Ethernet) to
one or more provider edge (PE) routers. Any router in the
backbone that does not attach to a CE device it termed provider core (PC) router. Since the backbone is assumed to be
all IP the layer 2 service that attaches a CE to a PE is terminated at the edge of the backbone, where the customers IP
datagrams are removed from any layer 2 encapsulation.
Each VPN can be further partitioned into subsets such
that each subset resides in an autonomous system (AS). An
AS is a set of sites where the same method of VPN service
implementation is used throughout the set to provide connectivity and services (e.g., only one SP operates the subset
over the backbone). An AS uses one or more interior gateway protocols (IGPs) and one or more sets of metrics to
route packets within the AS (intra-AS routing) and uses an
exterior gateway protocol (EGP) to route packets to other
ASes (inter-AS routing). A maximal subset of a VPN that
forms an AS is called a SubVPN.
The backbone must be IP VPN-enabled, i.e. its forwarding mechanisms must be integrally aware of the IP VPN
partitioning without having to use overlay models to establish connectivity. RFC 2547bis proposes Multi-Protocol
Label Switching (MPLS) (see IETF RFC 3031/RFC 3032)
as IP VPN-enabling technology.
The roots of MPLS go back to numerous efforts in the
mid-1990s to combine IP and ATM technologies for the
benefit of bringing L2 switching advantages to L3 routing
(multilayer switching), in particular to improve throughput
and delay performance of IP. Certain ISPs evolved their
networks from router-based cores to the overlay model running IP over ATM because they needed greater bandwidth,
deterministic forwarding performance, and traffic engineering (TE) to support the explosive growth occurring in their
networks. The IP-over-ATM model is complex to deploy
and manage, however, due to the completely different protocol architectures of IP and ATM, and has inherent scaleability problems. The proprietary predecessors of MPLS
sought to combine the best properties of IP routing and
ATM switching, while still maintaining an IP focus. They
combined directly IP routing technology with ATM label
swapping technology by mapping routes to labels and

distributing them to neighbours to establish LSPs across the
core of the network. In the meantime IP routers became as
fast as ATM switches so that ATM or MPLS are no longer
needed for performance improvement of IP networks. But
IP networks can benefit from the connection-oriented nature
and multi-protocol support of MPLS in other respects, e.g.
QoS support, TE, VPN support, multiple data link and
transport layers. For example, IP-over-MPLS-over-ATM is
much easier to deploy and manage than IP-over-ATM.
Figure 16 IP VPN according to RFC 2547bis.9
After establishment of the layer 2 link of a CE device to a

PE router, the CE router advertises its sites local VPN
routes to the PE router and learns the remote VPN routes
from the PE router. The PE router maintains a VPN Routing
and Forwarding (VRF) table for each port that terminates a
layer 2 link to an attached site. RFC 2547bis proposes Border Gateway Protocol (BGP) (see IETF RFC 1771) to be
used to exchange the routes of a particular VPN among the
PE routers that are attached to that VPN, or rather the multiprotocol extensions for BGP (MBGP) (see IETF RFC
2858). Each route within a VPN is assigned an MPLS label;
when BGP distributes a VPN route, it also distributes an
MPLS label for that route. Before a customer data packet
travels across the SPs backbone, it is encapsulated with the
MPLS label that corresponds, in the customers VPN, to the
route that is the best match to the packets destination address. This MPLS packet is further encapsulated (e.g., with
another MPLS label if the backbone supports MPLS, or
with an IP or Generic Routing Encapsulation (GRE) (see
IETF RFC 2784) tunnel header) so that it gets tunnelled
across the backbone to the proper PE router. Thus the backbone PC routers do not need to know the VPN routes.
Figure 16 summarizes the outlined IP VPN concepts.
Copyright 2000 Peter J. Welcher. Peter J. Welcher, (4 October 2000)
[online], BGP and MPLS-Based VPNs, available: http://www.netcrafts
men.net/welcher/papers/mplsvpn.pdf, 15 April 2003 [date accessed].

22
The backbone of an RFC 2547bis VPN therefore consists

of a control plane and a transport plane. The control plane
cares for VPN route distribution using MBGP and MPLS
label switched path (LSP) establishment using either Label
Distribution Protocol (LDP) (see RFC 3036, RFC 3212),
for best-effort LSPs, or Resource reSerVation Protocol
(RSVP) (see RFC 2205, RFC 2750), for LSPs with specific
QoS guarantees and/or TE objectives, while the transport
plane forwards the customer IP traffic along LSPs. The
LSPs are established between the PE router that learns the
VPN route and the PE router that advertises the route.
MPLS operation (e.g., in IP VPNs) is based on a label
stack, also known as shim header, that is inserted after the
layer 2 headers and before any layer 3 headers; each label
stack entry consists of 4 bytes, where the first 20 bits are the
label value (see IETF RFC 3032). When used in this way
MPLS is described as layer 2.5 technology. Figure 17
shows the shim header for some layer 2 technologies.
Figure 17 MPLS Label Stack Examples.10
To integrate IP VPN technology into the MTNM/IPNM

information model the following steps need to be taken:
model IP routers as MEs and specify the applicable

routing protocols and equipment of IP routers
make a check on suitability of existing faades and

managed objects for use with MPLS according to the interface design paradigm of TMF MTNM (see TABLE 3)
introduce the control plane and MBGP
phrase a complete use case package for IP VPN configuration, monitoring, and control
IETF working groups have introduced the concepts of

Provider-Provisioned (PP) VPN and Pseudo Wire Emulation Edge to Edge (PWE3). PP VPNs generalize and supplement the RFC 2547-style VPNs and are based on customer edges (CEs), provider edges (PEs), attachment circuits (ACs), Packet Switched Network (PSN) tunnels, and
pseudo wires (PWs). A PP VPN is either a Layer 2 (L2)
VPN (see draft-ietf-ppvpn-l2-framework-03) or a Layer 3
(L3) VPN (see draft-ietf-ppvpn-framework-08).
Three types of L2 VPNs are described: Virtual Private
Wire Service (VPWS), Virtual Private LAN Service (VPLS),
and IP-only LAN-like Service (IPLS). A fourth type is the
Virtual Hierarchical LAN Service (VHLS) (see draftsodder-ppvpn-vhls-02), which currently is not yet included
in the L2 VPN framework (see also Section VI.I.).
Two types of L3 VPNs are described: PE-based VPN
(e.g., an RFC 2547-style VPN) and CE-based VPN where
the shared SP network does not have any knowledge of the
customer VPN but this information is limited to CEs that
are, however, provided and managed (in particular provisioned) by the SP (see draft-ietf-ppvpn-ce-based-03).
Figure 18 shows the resulting taxonomy of PP VPNs
(adapted from draft-andersson-ppvpn-terminology-03):
PP VPN
________________|______________
|
|
L2 VPN
L3 VPN
____|____
_______|_______
|
|
|
|
VPWS
MP2MP
PE-based
CE-based
_______ __|____
____|____
|
|
|
|
|
|
|
VPLS
IPLS
VHLS
RFC 2547 Virtual
IPsec
Style
Router
Figure 18 Taxonomy of PP VPN Technologies.
11
specify IP sites as PTP pools , and define IP VPNs
specify CE devices/routers, PE routers, and PC routers
introduce MPLS as a transport mechanism on a new

connection-oriented layer; in particular specify label
switching routers (LSRs), label edge routers (LERs),
forwarding equivalence classes (FECs), LSPs, MPLS
TMDs for QoS and TE,12 and the use of LDP and RSVP
10
Copyright 2001 Cisco Systems. William Stallings, MPLS, The
Internet Protocol Journal, vol. 4, no. 3, pp. 2-14, September 2001 (see
http://www.cisco.com/warp/public/759/ipj_4-3.pdf).
11
This point of view is also taken by TMF611.
12
TMF IPNM currently defines the additional concept of a traffic trunk
(TT) that aggregates traffic flows along LSPs subject to QoS constraints.
The CEs and PEs can be routers, bridges, or switches, the

CEs can also be hosts. An AC is a physical or logical link
between a CE and a PE (e.g., a physical Ethernet link, an
ATM VCC or VPC, an FR VC). A Packet Switched Network (PSN) is an IP network (of one or more SPs) through
which edge-to-edge tunnels can be set up. A PSN tunnel
represents connectivity used to transport packets across the
PSN from one edge NE to another. In L2 VPNs and PEbased L3 VPNs tunnels run between PEs while in CE-based
L3 VPNs they run between CEs over the SP network(s).
How tunnels are established depends on the tunnelling
mechanism(s) supported by the PSN; e.g., the tunnel can be
based on an MPLS label, the IP-header (IP-in-IP), the L2TP

23
session ID, the GRE key field, or the SPI field of IPSec in
tunnel mode, i.e. the network is using MPLS, IPv4 or IPv6,
L2TP, GRE, or IPSec as the unit of switching.
PWE3 is a mechanism that emulates the essential attributes of a service over a PSN. A CE is a device where one
end of an emulated service originates and terminates. The
CE is not aware of using an emulated service rather than a
real service. A PE is a device that provides PWE3 to a
CE. A PW is a connectivity (i.e., a connection or a flow)
between two PEs carried over a PSN within a tunnel and
carrying the essential elements of an emulated service. The
PE provides the adaptation between the CE and the PW.
Multiple PWs may be carried in a single tunnel. The PW
provides the CE with what appears to be a connection (virtual circuit) to its peer at the far end. A Pseudo Wire End
Service (PWES) is the interface between a PE and a CE; this
can be a physical interface (e.g., T1/E1, Ethernet, DSL) or a
virtual interface (e.g., ATM VC, FR VC, Ethernet VLAN).
Figure 19 summarizes the PWE3 terminology (slightly
adapted from draft-ietf-pwe3-requirements-05):
|<------- Pseudo Wire -------->|
|
|
|
|<-- PSN Tunnel -->|
|
V
V
V
V
PWES
+-----+
+-----+
PWES
+-----+
|
| PE1 |==================| PE2 |
|
+-----+
|
|----------|.... ........PW1............. |----------|
|
| CE1 |
|
|
|
|
|
|
| CE2 |
|
|----------|.... ........PW2............. |----------|
|
+-----+ ^ |
|
|==================|
|
| ^ +-----+
^ |
+-----+
+-----+
| ^
| |
Provider Edge 1
Provider Edge 2
| |
| |
| |
| Attachment Circuit
Attachment Circuit |
|
|
|<---------------- Emulated Service ---------------->|
Customer
Edge 1
Customer
Edge 2
Figure 19 PWE3 Reference Model.
In an L2 VPN the SP is responsible for L2 connectivity;

the customer is responsible for L3 connectivity, which includes routing. L2 connectivity is achieved by setting up
pseudo wires and mapping attachment circuits to PWs.
Early examples of L2 VPNs are FR-based or ATM-based.
A pretty new technology are virtual private wire services
through point-to-point encapsulation methods of L2 frames
over a PSN, especially an MPLS network. These methods
are known as Martini Draft (see draft-martini-l2circuitencap-mpls-05). The industry is now standardizing on Martini interoperability, especially for Ethernet services (see
draft-ietf-pwe3-ethernet-encap-02) but also for TDM (PDH,
SDH, SONET), ATM (in cell mode or in AAL5 mode), FR,
HDLC, PPP. In the Martini model for Ethernet-over-MPLS
native Ethernet and VLAN services (bridged LAN services)
are emulated as pseudo wires within MPLS tunnels (i.e.,
LSPs). When Ethernet frames contain IEEE 802.1Q tags, all
frames in a PW must have the same tag value.
The VPWS model for Ethernet-over-MPLS is extended

to a fully-fledged VPLS model by the Lassere-VKompella
Draft (see draft-lasserre-vkompella-ppvpn-vpls-04).
The enhancement of IP VPN technology to L3 PP VPN
and L2 PP VPN within TMF MTNM/IPNM is for further
study in a further step (ffsfs) v4.x (see also Section VI.I.).
MetroEthernet Forum (MEF) specifies details of Ethernet
services for E-Line Service types (i.e., Ethernet Private Line
(EPL), Ethernet Virtual Private Line (EVPL), Dedicated
Internet Access, Intranet/Extranet L2 VPN or Ethernet Private LAN (EPLan)) and E-LAN Service types (i.e., LAN
Extension or Ethernet Virtual Private LAN (EVPLan)). For
these services MPLS is the preferred transport layer though
provider bridges based on IEEE 802.1Q VLAN double
stacking (not double tagging), according to IEEE P802.1ad,
are also seriously considered (see Section VI.I.).
Therefore MEF is doing some MPLS work in general
(based on Martini and pwe3 drafts) and rather a lot of work
on MPLS management in particular (see [12]). The coordination of MPLS work in TMFs MTNM and IPNM
teams and MEF Technical Committees Management SubGroup, similar to the planned co-operation on Ethernet
bridging and VLAN modelling (see Section VI.B.), is therefore to be recommended. It should also clarify the needed
amount of support for PP VPN and PWE3 by TMF MTNM.
The MPLS architecture has been defined to support the
forwarding of data based on a label. In this architecture,
LSRs were assumed to have a forwarding plane that is capable of recognizing either packet or frame/cell boundaries
and being able to process either packet headers or
frame/cell headers. The original MPLS control plane has
recently been extended to the Generalized MPLS (GMPLS)
architecture (see IETF RFC 3471, draft-ietf-ccamp-gmplsarchitecture-06) to encompass time-division switching (e.g.,
PDH, SDH, SONET), wavelength switching (i.e., optical
lambdas), and spatial switching (i.e., incoming port or fiber
to outgoing port or fiber). GMPLS includes LSRs whose
forwarding plane recognizes neither packet nor frame/cell
boundaries and therefore cannot forward data based on the
information carried in either packet or frame/cell headers.
Such LSRs include devices where the forwarding decision
is based on time slots, wavelengths, or physical ports.
Interfaces of LSRs are subdivided into the following
classes: packet switch capable (PSC), layer 2 switch capable (L2SC), TDM, lambda switch capable (LSC), fibre
switch capable (FSC). A circuit can be established only
between, or through, interfaces of the same type.
The concept of nested LSP (LSP-in-LSP), already available in the traditional MPLS by the label stack mechanism13, facilitates building a forwarding hierarchy, i.e. a
hierarchy of LSPs. This hierarchy of LSPs can occur on the
same interface, or between different interfaces. The nesting
can also occur between interface types. At the top of the
13
(see draft-ietf-mpls-lsp-hierarchy-08 for further mechanisms)

24
hierarchy are FSC interfaces, followed by LSC interfaces,

followed by TDM interfaces, followed by L2SC interfaces,
and followed by PSC interfaces. This way, an LSP that
starts and ends on a PSC interface can be nested (together
with other LSPs) into an LSP that starts and ends on an
L2SC interface. This LSP, in turn, can be nested (together
with other LSPs) into an LSP that starts and ends on a TDM
interface. In turn, this LSP can be nested (together with
other LSPs) into an LSP that starts and ends on an LSC
interface, which in turn can be nested (together with other
LSPs) into an LSP that starts and ends on an FSC interface.
GMPLS is closely related to dynamic connection management (see Section VI.G.). The formal working out of
GMPLS for TMF MTNM should therefore be done jointly
with dynamic connection management. This is postponed
for further study in a further step (ffsfs) v3.x or v4.x.
I. Separation, MAC-in-MAC, Provider Bridges
Q-in-Q technology separates customer networks (of the

same provider), the emerging MAC-in-MAC technology
separates customer and provider networks (and therefore
customer networks as well). These orthogonal separation
planes are shown in Figure 20.
VPNs can be considered as logical connectivity objects to

which sites may be attached and which may be interconnected together, in the same manner as hosts are attached to
physical networks and physical networks are interconnected
together (e.g., via bridges or routers) (see IETF RFC 2764).
A VPN emulates a private MAN/WAN by using one or
more circuit- or packet-switched public or private networks
as its backbone and covers the use of the backbone to create
and manage groups of users, the VPN customers, who are
separated from other user groups (according to a specified
level of separation) and where the users of a group may
communicate among each other as if they were on a private
network (with specified level of security and privacy).
Techniques for customer separation and their respective
inherent grade of separation and transmission quality are
therefore of vital importance for VPN provision. A connection-oriented, circuit- or packet-switched backbone, e.g. an
SDH or ATM network, uses circuits or virtual circuits (i.e.,
connections) for separation, while a connectionless packetswitched backbone, e.g. an IP L3 or Ethernet L2 network,
uses tunnels (i.e., flows). The separation-capable backbone
may be realized using one or more network topologies to
interconnects PEs, including point-to-point (P2P), point-tomultipoint (P2MP, also known as hub-and-spoke), multipoint-to-multipoint (MP2MP, also known as full or partial
mesh), and hierarchical topologies.
The used separation technology should include a multiplexing/demultiplexing facility to allow for multiple customers and optimized resource usage in the same edge-toedge connection or flow. If the separation mechanism does
not provide multiplexing, this can be accomplished by a
stacking/nesting procedure that repeats the payload encapsulation with different parameters. Section VI.H. outlines
such mechanisms, in particular Ethernet-over-MPLS.
The present section presents two purely Ethernet-based
customer separation mechanisms that are known as Q-in-Q
(or .1Q-in-.1Q) and MAC-in-MAC. While the VLAN-based
Q-in-Q is a generalization of MAC and VLAN bridging

according to IEEE 802.1D/802.1Q that adds tagged MAC
headers (specified by 802.1Q and 802.3-2002) with provider VLAN (P-VLAN) tags to the customer payload that
may or may not contain customer VLAN (C-VLAN) tags.15
An equipment that supports Q-in-Q is therefore called a
provider bridge. P-VLAN tagging differs from C-VLAN
tagging in several respects that are specified by P802.1ad.
The overall goal is to enable the (re-)configuration of a
VLAN-aware bridge as a provider bridge. While P-VLANs
identify provider-provisioned customer tunnels, C-VLANs
identify end customer tunnels provisioned by customers.
A MAC-in-MAC-aware LAN switch is called a Virtual
Hierarchical LAN (VHL) switch or Layer 2 Provider Edge
(L2PE) device or Hierarchical Bridge (HB). It encapsulates
the customer MAC frames with an additional MAC header
of a new Ethernet type that maps customer MAC addresses
to HB addresses and contains a 24-bit L2 VPN identifier
(L2VID). The L2VID is administered by the SP and is
globally unique for the SPs backbone network.16 Customer
VLAN identifiers are assigned to unique L2VIDs. The VHL
Service (VHLS) reference model places L2PEs between CEs
Customer network
Provider network
Customer network
MAC-in-MAC
Customer #A
Customer #A
Q-in-Q
Customer #B
Customer #B
Customer #C
Customer #C
Figure 20 Q-in-Q and MAC-in-MAC Separation.14
14
Copyright 2003 MetroEthernet Forum.
Paul Bottorf, Michael Chen, Dirceu Cavendish, Marcus Holness, Pankaj
Jha, Kshitij Kumar, Dinesh Mohan, Himanshu Shah, Arnold Sodder, Joris
Wils, (9 April 2003) [online], Separating Provider from Customer with
MAC-in-MAC (Rev. 1.1), available: http://www.metroethernetforum.net/
apps/org/workgroup/technical/download.php/816/05035_001_05035_001_
Separating Provider from Customer with MAC-in_Wils_Wils.ppt,
12 May 2003 [date accessed].
15
VLAN technology introduces three types of MAC frames: untagged
frames (see Figure 3-1/802.3), priority-tagged frames with null VLAN
Identifier (VID) and any 3-bit user priority (see Figure 3-3/802.3), and
VLAN-tagged frames with a non-null 12-bit VID that must not be FFF and
may be 001 only when used as a temporary bridge Port VLAN ID (PVID).
Thus the SPs backbone network may support up to 212-2 = 4094 VLANs.
For the semantics of the possible user priority values 0..7, regarding traffic
types in particular, refer to Section 7.7 and Annex J of IEEE 802.1D.
16
Since the L2VIDs 000000 and FFFFFF are reserved the SPs backbone
network may support up to 224-2 = 16777214 VPN instances.

25
and PEs (see draft-sodder-ppvpn-vhls-02), and prefers

MPLS-based and VPLS-capable backbone networks (i.e.,
the Lasserre-VKompella VPLS with Martini LSPs).
While Q-in-Q reuses the widespread VLAN technology,
MAC-in-MAC requires the new VHLS or HB technology.
Therefore Q-in-Q can be considered a todays customer
separation mechanism, whose standardization in IEEE and
IETF is supported by many equipment vendors and service
providers, while MAC-in-MAC is a brilliant and furtherreaching customer and provider separation mechanism,
whose standardization is supported only with reluctance.
Since a Q-in-Q based SP backbone can support only up
to 4094 VLAN instances, support for inter-provider links
between SP backbones (of the same or different SPs) is
required when virtual bridged multi-user LANs have to be
scaled to build carrier-class provider networks. A solution
that requires no further standardization work (but quite
some co-operation work) is the concept of IEEE provider
bridge islands that are interconnected with IETF VPLS
meshes and use the IEEE 802.1s Multiple Spanning Tree
Protocol (MSTP). Figure 21 depicts this solution.
VII. TMF CORBA VERSUS ITU-T CORBA

TMF MTNM as summarized in Section IV.A. Managing
CORBA Objects and Section IV.B. Managed MTNM Objects is now related to the CORBA NE and network management framework specified by ITU-T. The ITU-T model
is outlined, mediation between TMF MTNM CORBA and
ITU-T CORBA is discussed, and coexistence strategies are
demonstrated. The coexistence of both models as they are
today is possible if mediators are used or even standardized.
It is indicated how improved coexistence could be achieved
if both models would be evolved towards each other. The
main obstacle to these improvements are compatibility issues that are also briefly discussed.
It is explicitly recommended not to (try to) adopt TMF
MTNMs information model to ITU-Ts information model,
as proposed e.g. in [44], since it would eliminate important
goodies of the TMF MTNM model. Instead a co-operation
of TMFs MTNM team and ITU-Ts SG 4 is recommended
to bring TMF MTNMs goodies into ITU-Ts framework.
A. ITU-Ts CORBA Framework
T1M1.5 and ITU-T SG 4 defined a standard approach for
specifying network and NE management interfaces that use
CORBA, called ITU-T CORBA-based TMN framework.
This approach is strictly object-oriented and designed to be
customizable with network technology specific (or even
equipment supplier specific) extensions. The framework
defines a number of constructs as shown in Figure 22:
Figure 21 Interconnected Provider Bridge Islands.17
While hailing IP VPNs according to IETF RFC 2547bis/

ITU-T Y.1311.1 (see Figure 16) as the killer application for
carrier networks in the 21st century must be regarded as an
exaggeration, the same assessment for the emerging PP
VPN technologies (see Figure 18) seems less exaggerated.
Their integration into TMF MTNM is postponed for further
study in a further step (ffsfs) v4.x, however.
17
Copyright 2003 Cisco Systems.
Norman Finn, (8 April 2003) [online], IEEE 802.1ad Provider Bridges
Tutorial (Rev. 1), available: http://www.metroethernetforum.net/apps/
org/workgroup/technical/download.php/801/05051_000_802-1adprovider-bridges-tutorial_Klessig.pdf, 12 May 2003 [date accessed].
Norman Finn, (12 October 2002) [online], Bridge-Based Ethernet Service
Provision (Rev. 2), available: http://www.ieee802.org/1/files/public/
docs2002/bridge-based-ether-prov-2.pdf, 12 May 2003 [date accessed].
protocol requirements, CORBA Common Object Service (COS) usage requirements, and TMN-specific support services for basic capabilities of managed systems
(including support of coarse-grained interfaces), regardless of the type of network technology being managed
(CBTS Q.816 [32], CCBTS Q.816.1 [7], fault management Q.821.1 [34], performance management Q.822.1
[35], software management X.744.1 [36], etc.)
the root class itut_x780::ManagedObject from
which all managed objects inherit core capabilities they
must implement to get enabled for operation within the
framework (GDCMO X.780 [33])
the root class itut_x780::ManagedObject_F from
which all managing objects (faades) inherit basic capabilities they must support to be able to operate within the
framework (GDCCMO X.780.1 [8])
rules and conventions for defining application-specific
managed and managing object classes (MOCs) (X.780
[33] GDCMO and X.780.1 [8] GDCCMO); GDCMO
translates GDMO/ASN.1 (X.721, X.722) and GDCCMO
extends GDCMO so that the fine-grained approach becomes a prerequisite of the coarse-grained approach
catalog of generic MOCs at NE and network level
(M.3120 [9]) that lacks traits specific to any particular
network technology but defines concepts common to
most network technologies by translating them mainly

26
from famous ITU-T Rec. M.3100;18 some MOCs (e.g.,

NE, equipment shelf, circuit pack) can be used without
further specialization, other MOCs (e.g. link, connection,
TP) are abstract and must be specialized with traits specific to a particular network technology before being included in a commercial interface specification
X.780.1
X.780
Conventions:
Superclasses:
Standard
Data Types
GDMO to IDL
Managed
Object
Managed
Object Factory
Link
Faade
Network
Factory
Network
Heartbeat
Service
Inherits
Link
Managed
Element
Faade
Connection
Factory
etc. etc.
Managed
Element
Factory
Managed
Element
Containment
Service
Naming
Service
Names
Names
Terminator
Service
Channel
Finder
Link
Factory
Connection
Connection
Faade
Applicationspecific
Objects:
Other
Conventions
Multiple Object
Operation Service
Factory
Finder
Notification
Service
Telecom
Log Service
etc. etc.
CORBA 2.3 ORB
Q.816.1
TMF MTNM must take into account that it should be as

much multi-vendor capable as possible from the NMS point
of view. In particular, if in a customers OSS environment
run CORBA servers that implement TMF814 and, at the
same time, CORBA servers that implement some interface
that complies with the ITU-T framework, then the effort for
the CORBA clients to switch between the interfaces should
be minimized. This amounts to the possibilities to
Services:
Managed
Object
Faade
Network
Faade
Notification
Specifications
B. Mediation between ITU-T and TMF CORBA
M.3120
AF-NM-0185
DSLF TR-050
Q.834.4
etc.
Q.816
Q.821.1
Q.822.1
X.744.1
etc.
Figure 22 ITU-T CORBA Framework.19
The framework and its guideline rules have already been

applied to define MOCs for specific technologies, e.g. ATM
(see ATMF AF-NM-0185 [10]), ADSL (see DSLF TR-050
[11]), BPON (see ITU-T Q.834.4 [37]).
MetroEthernet Forum (MEF) is considering to apply the
framework for Ethernet and MPLS modelling (see [12]).
Care has to be taken that the MEF-standardized NML-EML
interface and its information model will align with the
TMF-standardized NML-EML interface (MTNM/IPNM)
and its information model regarding Ethernet and IP network and network element management. To this end close
co-operation, and possibly a formal liaison, is scheduled
between the teams MTNM and IPNM of TMF and the
Management Sub-Group of MEFs Technical Committee.
18
ITU-T SG 4 started work on the revision of M.3100, since the current
status with five amendments and three corrigenda makes application difficult. This work may have some impact on M.3120 as well.
19
Copyright 2001 ITU-T SG 4 and SBC Technology Resources. The
figure includes some adaptations by the present author.
either enhance the TMF814 interfaces by thin ITU-T

Q.816/X.780 mediation layers that will need to map
MTNM MOCs to M.3120 and technology-specific MOCs
or enhance the ITU-T Q.816/X.780 interfaces by thin

TMF814 mediation layers that will need to map M.3120
and technology-specific MOCs to MTNM MOCs
For example, ITU-T Q.816/X.780 supports ATM via an
ATMF extension (see [10]) and ADSL via a DSLF extension (see [11]), and TMF814 supports core ATM (v2.1, see
[1]) and DSL (v3.0, see [28]) as well. Therefore in a large,
multi-vendor VoATMoDSL network (see Section VI.E.)
there could well be Q.816/X.780 and TMF814 installations
of ATM- and ADSL-capable EMSes.
In general, due to ITU-Ts a little intricate nature, mainly
caused by the vast amount of value type definitions and
related CORBA operations, and the very smart nature of
TMF814 (see Section IV.), which is actually designed for
very easy use by the NMS, it will be much much easier to
implement a thin TMF814 mediation layer on top of ITU-T
than doing the reverse. Specifying an ITU-T Q.816/X.780
mediation layer would indeed amount to developing a second CORBA solution set besides TMF814 for TMF
MTNM. You would use the fine-grained UML model and
class dictionary of TMF608 and first apply X.780 GDCMO
to get a fine-grained model and then X.780.1 GDCCMO to
translate it to a class-grained model. There are neither consent nor resources in the MTNM team to do this work.
For the same inherent reasons, and even more importantly for customers, it is much easier and cheaper to develop and operate a CORBA client (southbound interface)
for a TMF814 CORBA server (northbound interface) than
to do the same for an ITU-T CORBA server.
It is therefore recommended, for the benefit of EMS customers and NMS vendors, that all supporters of the ITU-T
framework shall deliver a thin TMF814 mediation layer in
addition to their ITU-T interface. The specification of such
a layer is straightforward, given the TMF814 delivery and
the ITU-T framework specifications (with miscellaneous
technology-specific addenda), but out of scope of the present paper. It is further recommended to even standardize
this mediation layer. Companies participating in TMF
MTNM work and supporting the ITU-T framework should
consider the possibility, to enhance TMF814A (see [2]) by20
20
(or to introduce a second IS document, TMF814B, with)

27
suitable templates for a mediation layer from the ITU-T

framework to TMF814, and come up with a corresponding
joint contribution, TMF814 Mediation Layer for ITU-T
Q.816/X.780/M.3120 say. This will include technologyneutral templates and technology-specific templates for the
technologies supported by the respective TMF814 version.
The starting point of the TMF814 mediation layer specification work would be a detailed comparison of the TMF
information model, as outlined in TABLE 2, Figure 3, and
Figure 4, and the ITU-T information model, as outlined in
Figure 22 above, supplemented by Figures 1, 2, 3, and 4 of
M.3120, and further supplemented by outlines of all applicable technology-specific extensions provided only they are
available (e.g., Sections 3.1 and 3.2 of ATMF NM-0185 for
ATM [10] and Figures 3-1, 3-2, and 3-3 of DSLF TR-050
for ADSL [11]). This is hard work due to the overwhelming
amount of details collected in the ITU-T framework.
The implementation of standardized TMF814 mediators
would facilitate the co-existence of both models as they are
today. But mediators may have shortcomings during runtime and so the mediation function should be kept as thin as
possible. Therefore the requirement exists to bring both
models more into line by letting them evolve towards each
other through joint further development. This amounts to
establishing a corresponding liaison between ITU-Ts SG 4
and TMFs MTNM team.21 As a consequence TMF MTNM
could be enhanced step-by-step by the goodies of ITU-Ts
CORBA framework (e.g., use of value types, root classes,
constant definitions, common services infrastructure), and
vice versa (e.g., multiple transmission layering according to
G.805/G.809/G.852.2, session management, faades that
manage multiple related managed object classes, equipment
model, ease of integration of specific technologies). Both
parties have to resolve step-by-step the corresponding version compatibility issues for their respective interface.
It is explicitly recommended not to (try to) adopt TMF
MTNMs information model to ITU-Ts current information model, as proposed e.g. in [44], since this would eliminate important goodies of the TMF MTNM model.
C. Version Compatibility and Extension Mechanisms
The proposal to co-ordinate the further development of
both models, immediately raises backward compatibility
issues regarding existing northbound and southbound
TMF814 v2.x implementations. The requirement with highest priority for TMF814 v3.0 has been backward compatibility of NBI, to protect investments in v2.x EMSes, preferably in conjunction with forward compatibility of SBI, to
protect investments in v2.x NMSes.
This requirement was analysed in great detail (see [38])
and the TMF MTNM team agreed that every attempt shall
21
The ITU-T framework has its roots in pioneering ATIS T1M1.5 work
(T1M1.5/2000-029 and T1M1.5/2000-030). It is therefore desirable to ask
T1M1.5 and the original framework contributors to take an active role in
the alignment effort for Q.816/X.780/M.3120 and TMF814.
be made to render TMF814 both interface backward compatible and interface forward compatible starting with version 2.0. For example, TMF814 v2.1 fulfils the requirement. However, it was also recognized that this agreement
imposes a lot of restrictions on the types of changes that
can be made. As a consequence, if at some point it is understood that the agreement is too stringent and does not allow
proper implementation of a significant feature, then interface backward compatibility will be forced but forward
compatibility through versioning will be allowed.22 This is
an optional feature in the EMSes, however, since it requires
that they implement different versions. Therefore another
choice is to provide interface backward compatibility without forward compatibility. However, TMF814 itself would
in all cases allow both backward and forward compatibility.
The compatibility principles were applied (or not) so far
for proposals of extension mechanisms for TMF MTNM:
general purpose extension mechanism 23 relying on
CORBA any type declarations (see [39]); it is backward
and forward compatible and recommended for use; the
decision on use is pending since not yet needed
general purpose extension mechanism 23 relying on
CORBA valuetype value declarations but keeping
TMF814 v2.1 CORBA struct type declarations (see
[39]); it is backward and forward compatible but hybrid
and little elegant and not recommended for good reasons;
the decision on non-use in favour of any is pending 24
general purpose extension mechanism relying purely
on CORBA valuetype value declarations and including vendor-specific usage for EMS and NMS (see [40]);
it is neither backward nor forward compatible and was
therefore rejected by the MTNM team
extension mechanism for CORBA enum type declarations (see [41]); it is backward compatible and mostly
forward compatible; it will be used for TMF814 v3.0
Some people have an issue with the any proposal as described in [39] since any is known to sometimes give rise
to performance shortcomings and is not much tested in
CORBA environments. But for a concrete application the
any approach just means to specify attachable extensions of
MTNM managed object classes (see Figure 4) by using
MTNM names as the attachment mechanism. An attachable
22
Refer to the supporting document versioning.pdf of [1] for TMF
MTNMs versioning concept(s).
23
A general purpose extension mechanism applies to any MTNM managed object class (see Figure 4), allows to specify supplementary information for a managed object that extends its core-defined properties, is related
to a given functionality of TMF MTNM, could but need not be managed
by a separate faade, and can be attached to the object by some defined
means (e.g., by repeating the object identifier within the extension specification, or by an inheritance mechanism). Multiple extensions, all of different types, can be attached to the same managed object.
24
The introduction of the hybrid valuetype & struct extension mechanism in TMF814 v3.x would clearly only make sense if in parallel an
agreement on a progressive migration strategy towards a pure valuetype
extension mechanism in TMF814 v4.x could be reached.

28
MTNM extension is defined as a struct declaration that

includes globaldefs::NamingAttributes_T name;
as a mandatory record member. Such a declaration usually
will not include any record members of type any. However,
there will be get, iterator, and set operations with parameters of type any for which it is completely up to the EMS to
take care for an efficient implementation by carrying an
appropriate non-any object within the any type (see [39]).
CORBA value types (see [5], [42]) define the general
purpose extension mechanism 23 of the ITU-T framework
and are one of its core design principles. Their introduction
for TMF MTNM was proposed by [43], and subsequently
this proposal was enlarged considerably to propose a recasting of TMF814s managed objects according to the ITU-T
framework thereby replacing the MTNM faades (see
TABLE 2) by new faades for each single MOC (see [44]).
This approach could be revised to keep the goodies of TMF
MTNM and gain the goodies of ITU-T. However, even
after revision it is neither backward nor forward compatible
and so it had to be rejected by the MTNM team.
In the past the only choice for the definition of secondlevel object state was to use CORBA data structures, i.e.
CORBAs record type struct, which is a list of record
members. The approach to model second-level objects by
structures is workable but tedious since no inheritance capability as for interfaces is given. Now the introduction of
the Objects-By-Value (OBV) paradigm with CORBA 2.3
also introduced the value type entities which share many of
the characteristics of struct and interface. In its simplest form a valuetype can be considered as a struct
which can singly inherit from another valuetype, i.e.
struct, and whose record members are termed state members and can be qualified as public or private. That
state is marshalled and sent to the receiver when the value
type is passed as a parameter to a CORBA operation. If an
ORB claims to be fully CORBA 2.3 compliant it must support value types and should achieve considerable performance advantages when operations parameters are passed as
value types instead of being passed as structures since value
type instances are always local to their creating context.
D. Coexistence of TMF and ITU-T CORBA
The foregoing discussion showed that, due to compatibility issues, the coexistence of the TMF and ITU-T CORBA
NML-EML interfaces is currently only possible through the
use of a mediation function that could become thinner and
thinner when the interfaces evolutions would move towards each other. A mediation function would be realized
by a mediator that implements an NBI and uses an SBI.
When designing a mediator the basic rule is: the NBI
must be simpler than the SBI in every respect. In simplified terms this is because the implementation of the NBI
relies exclusively on data received by the SBI and so can
only coarsen the SBI but not refine it. Figure 23 shows examples of potential mediators involving TMF814. The case
of ITU-T as NBI and TMF814 as SBI is crossed out since

ITU-T is not simpler than TMF814 (see Section VII.B.).
NBI
TMF814
Mediator
SBI
ITU-T
ITU-T
ONC RPC
SNMP
SOAP/XMLP
TMF814
TMF814
TMF814
TMF814
Figure 23 Examples of TMF814 Mediators.
In each case the mediator may leverage for the NBI functionality only part of the functionality offered at the SBI.
For example, the TMF814 & SNMP mediator could be an
SNMP agent that translates CORBA notifications to SNMP
traps. The NBI may serve different types of clients. For
example, a multi-media mediator, not shown in Figure 23,
could implement alarm handlers that transmit TMF814
alarms to external media such as sound, Short Message
Service (SMS), a pager, a mobile phone, or even visual
media (fax, e-mail, HTML pages, WML pages). When both
NBI and SBI are standardized interfaces, the standards development organization that is responsible for the NBI
should standardize the mediator to the SBI as well.
The information model of the ITU-T CORBA-based
NML-EML interface is carefully considered and designed,
and fully object-oriented, but there are reservations about it
since it is a full equivalent of ITU-Ts GDMO/ASN.1-based
TMN model that did not find wide practical acceptance in
the industry. Quite the reverse, the information model of
TMF MTNM is intentionally (and not accidentially) not
clean but clear. What is sometimes identified (e.g., by [44])
as shortcomings are in reality distinctive advantages (e.g.,
IDL module structure including proper coarse granularity,
multi-layering, comprehensive non-object-oriented use of
layer-specific name/value pairs for technology-specific and
vendor-specific extensions, containment hierarchy, various
profile mechanisms). TMF814 received broad acceptance in
the industry exactly because of these distinctions.
TMF MTNM has its roots in work by the gang-of-seven
(G7) group 25 during the late-1990s. Since then there is the
obligation to develop an interface that focuses directly on
the practical needs of carriers but has nevertheless a robust
and flexible information model for all kinds of technology
that is (scheduled to be) deployed in the network. When
working on alignment of the TMF and ITU-T models for
network management, it will be important to align as well
the underlying paradigms, design philosophy, and flavour.
ACKNOWLEDGEMENTS
The author is indebted to the members of TMFs MTNM
team and IPNM team for their contributions, e-mail discussions, and participation in face-to-face meetings. Likewise
the work of ITU-Ts SG 4, SG 13, and SG 15 as well as
discussions with some of their members are appreciated.
25
Alcatel, Fujitsu, Lucent, Nortel, Siemens, Telcordia, Tellabs

29
REFERENCES
[1] TeleManagement Forum, Multi-Technology Network
Management (MTNM) NML-EML Interface, CORBA
IDL Solution Set (SS), TMF814 v2.1, August 2002,
http://www.tmforum.org/browse.asp?catID=926&sNode=926
&Exp=Y&linkID=24231.
[2] TeleManagement Forum (TMF), MTNM NML-EML

Interface, Implementation Statement (IS) Template and
Guidelines, TMF814A v2.1, August 2002,
[3] TMF, MTNM NML-EML Interface, Information Agreement (IA), TMF608 v2.1, August 2002,
[4] TMF, MTNM NML-EML Interface, Business Agreement (BA), TMF513 v2.1, September 2002,
[5] Object Management Group, The Common Object Request Broker: Architecture and Specification, Revision
2.3.1, Document formal/99-10-07, October 1999.
[6] Object Management Group (OMG), Naming Service
Specification, Revised Edition, Document formal/
01-02-65, February 2001.
[7] ITU-T SG 4, CORBA-Based TMN Services: Extensions
to Support Coarse-Grained Interfaces (CCBTS), Rec.
Q.816.1, August 2001.
[8] ITU-T SG 4, TMN Guidelines for Defining CoarseGrained CORBA Managed Object (GDCCMO) Interfaces, Rec. X.780.1, August 2001; Corrigendum 1,
Rec. X.780.1/Cor.1, May 2002; Amendment 1: System
Faades and User Guide for Bulk Attribute Retrieval,
Rec. X.780.1/Amd.1, May 2002.
[9] ITU-T SG 4, CORBA Generic Network and NE Level
Information Model, Rec. M.3120, October 2001;
Amendment 1: Protection Switching, Rec. M.3120/
Amd.1, May 2002; Amendment 2: CORBA Generic
Network and NE Level Information Model, Rec.
M.3120/Amd.2, March 2003.
[10] ATM Forum (ATMF), M4 Network View Interface
CORBA MIB Version 2, AF-NM-0185, August 2002.
[11] DSL Forum (DSLF), CORBA Specification v2 for
ADSL EMS-NMS Interface, TR-050, April 2002.
[12] MetroEthernet Forum (MEF), Draft EMS-NMS Information Model, Revision 4, Document D00012_004,
24 April 2003.
[13] ITU-T SG 13, Generic Functional Architecture of
Transport Networks, Superseded Rec. G.805, November 1995, Rec. G.805, March 2000.
[14] ITU-T SG 4, Enterprise Viewpoint Description of
Transport Network Resource Model, Rec. G.852.2,
March 1999.
[15] ITU-T SG 13, Architecture of Transport Networks
Based on the Synchronous Digital Hierarchy (SDH),
Rec. G.803, March 2000.
[16] ITU-T SG 15, Architecture of Optical Transport

Networks (OTNs), Rec. G.872, November 2001.
[17] ITU-T SG 13, Functional Architecture of Transport
Networks Based on ATM, Superseded Rec. I.326,
November 1995, Rec. I.326, March 2003.
[18] ITU-T SG 13, Requirements for Automatic Switched
Transport Networks (ASTNs), Rec. G.807, July 2001.
[19] ITU-T SG 15, Architecture for the Automatically
Switched Optical Network (ASON), Rec. G.8080,
November 2001; Amendment 1: Architecture for the
ASON, Rec. G.8080/Amd.1, April 2003.
[20] ITU-T SG 13, Functional Architecture of Connectionless Layer Networks, Rec. G.809, March 2003.
[21] ITU-T SG 4, Framework for the Integrated Management of Hybrid Circuit/Packet Networks, Draft new
Rec. M.3017, to be published 2003.
[22] OMG, Notification Service Specification, Version
1.0.1, Document formal/02-08-04, August 2002.
[23] OMG, Telecom Log Service Specification, Version 1.1,
Document formal/02-11-12, November 2002.
[24] Siemens AG, Inverse Multiplexing for ATM (IMA),
TMF MTNM Contribution, 15 February 2003.
[25] Siemens AG, Transmission Descriptors (TMDs), TMF
MTNM Contribution, 20 February 2003.
[26] Alcatel Group, Alarm Severity Assignment Profile
(ASAP) Management, TMF MTNM Contribution,
11 March 2003.
[27] Fujitsu Network Communications, Ethernet Modelling,
TMF MTNM Contribution, 4 February 2003.
[28] Siemens AG, Digital Subscriber Line (DSL) Technology, TMF MTNM Contribution, 7 March 2003.
[29] MEF, Metro Ethernet Network (MEN) Architecture
Framework, Part 1: Generic Framework, Revision
0.3.2, Document D00007_030323, March 2003.
[30] ITU-T SG 15, Ethernet Layer Network Architecture,
Draft new Rec. G.ethna, to be published 2003.
[31] Siemens AG, TL Semantics, Trails, Link Connections,
TMF MTNM Contribution, 21 June 2002.
[32] ITU-T SG 4, CORBA-Based TMN Services (CBTS),
Rec. Q.816, January 2001; Corrigendum 1, Rec. Q.816/
Cor.1, August 2001; Corrigendum 2, Rec. Q.816/
Cor.2, August 2002; Amendment 1: OMG Services Profile, Rec. Q.816/Amd.1, August 2001; Amendment 2:
User Guide for Local Name Resolution, Rec. Q.816/
Amd.2, May 2002.
[33] ITU-T SG 4, TMN Guidelines for Defining CORBA
Managed Objects (GDCMO), Rec. X.780, January
2001; Corrigendum 1, Rec. X.780/Cor.1, October
2001; Corrigendum 2, Rec. X.780/Cor.2, May 2002;
Amendment 1: System Objects and User Guide for Bulk
Attribute Retrieval, Rec. X.780/Amd.1, May 2002.
[34] ITU-T SG 4, CORBA-Based TMN Alarm Surveillance
Service, Rec. Q.821.1, September 2001.
[35] ITU-T SG 4, CORBA-Based TMN Performance Management Service, Rec. Q.822.1, October 2001; Amend-

30
ment 1: Generic Transport Performance Management,

Rec. Q.822.1/Amd.1, March 2003.
[36] ITU-T SG 4, CORBA-Based TMN Software Management Service, Rec. X.744.1, March 2003.
[37] ITU-T SG 4, A CORBA Interface Specification for
Broadband Passive Optical Networks (PONs) Based on
UML Interface Requirements, Draft new Rec. Q.834.4,
to be published 2003.
[38] Nortel Networks, Proposal for Backward & Forward
Compatibility, TMF MTNM Contribution, 13 November 2001.
[39] Nortel Networks, Extension Mechanism for the MTNM
Interface, TMF MTNM Contribution, 31 May 2002.
[40] Telcordia Technologies, ValueTypes for MTNM Extensions, TMF MTNM Contribution, 9 September 2002.
[41] Telcordia Technologies, Extension Mechanism for
ENUMs, TMF MTNM Contribution, 19 March 2003.
[42] OMG, Objects By Value (OBV), Final Revision,
Document orbos/98-01-18, February 1998.
[43] Telcordia Technologies, Phase III Support for Value
Types, TMF MTNM Contribution, 29 June 2001.
[44] Telcordia Technologies and SBC Technology Resources, Alignment of the MTNM Information Model
with the ITU-T CORBA Framework, TMF MTNM
Contribution, 15 October 2001.
REFERENCED IETF DOCUMENTS
[45] Yakov Rekhter and Tony Li, Eds., A Border Gateway Protocol 4 (BGP-4), RFC 1771, March 1995.
[46] Bob Braden, Ed., Lixia Zhang, Steve Berson, Shai Herzog,
and Sugih Jamin, Resource ReSerVation Protocol (RSVP) -Version 1 Functional Specification, RFC 2205, September
1997.
[47] Steven Blake, David L. Black, Mark A. Carlson, Elwyn
Davies, Zheng Wang, and Walter Weiss, An Architecture
for Differentiated Services, RFC 2475, December 1998.
[48] Eric C. Rosen and Yakov Rekhter, BGP/MPLS VPNs,
RFC 2547, March 1999.
[49] Gregory Bathrick and Faye Ly, Definitions of Managed
Objects for the ADSL Lines, RFC 2662, August 1999.
[50] Dan Grossman and Juha Heinanen, Multiprotocol
Encapsulation over ATM Adaptation Layer 5, RFC 2684,
September 1999.
[51] Shai Herzog, RSVP Extensions for Policy Control,
RFC 2750, January 2000.
[52] Raj Yavatkar, Dimitrios Pendarakis, and Roch Guerin,
A Framework for Policy-based Admission Control,
[53] Bryan Gleeson, Arthur Lin, Juha Heinanen, Grenville
Armitage, and Andrew G. Malis, A Framework for IP Based
Virtual Private Networks, RFC 2764, February 2000.
[54] Dino Farinacci, Tony Li, Stan Hanks, David Meyer, and Paul
Traina, Generic Routing Encapsulation (GRE), RFC 2784,
March 2000.
[55] Tony Bates, Yakov Rekhter, Ravi Chandra, and Dave Katz,
Multiprotocol Extensions for BGP-4, RFC 2858,
June 2000.
[56] Eric C. Rosen, Arun Viswanathan, and Ross Callon,

Multiprotocol Label Switching Architecture, RFC 3031,
January 2001.
[57] Eric C. Rosen, Dan Tappan, Guy Fedorkow, Yakov Rekhter,
Dino Farinacci, Tony Li, and Alex Conta, MPLS Label
Stack Encoding, RFC 3032, January 2001.
[58] Loa Andersson, Paul Doolan, Nancy Feldman, Andre
Fredette, and Bob Thomas, LDP Specification, RFC 3036,
January 2001.
[59] Andrea Westerinen, John Schnizlein, John Strassner, Mark
Scherling, Bob Quinn, Shai Herzog, An-Ni Huynh, Mark
Carlson, Jay Perry, and Steve Waldbusser, Terminology for
Policy-Based Management, RFC 3198, November 2001.
[60] Bilel Jamoussi, Ed., Loa Andersson, Ross Callon, Ram
Dantu, Liwen Wu, Paul Doolan, Tom Worster, Nancy
Feldman, Andre Fredette, Muckai K. Girish, Eric Gray, Juha
Heinanen, Timothy E. Kilty, and Andrew G. Malis,
Constraint-Based LSP Setup using LDP, RFC 3212,
January 2002.
[61] Dan Grossman, New Terminology and Clarifications for
Diffserv, RFC 3260, April 2002.
[62] Jonathan Rosenberg, Henning Schulzrinne, Gonzalo
Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark
Handley, and Eve Schooler, SIP: Session Initiation
Protocol, RFC 3261, June 2002.
[63] Bob Ray and Rajesh Abbi, Definitions of Managed Objects
for High Bit-Rate DSL - 2nd generation (HDSL2) and
Single-Pair High-Speed Digital Subscriber Line (SHDSL)
Lines, RFC 3276, May 2002.
[64] Yoram Bernet, Steven Blake, Dan Grossman, and Andrew
Smith, Ed., An Informal Management Model for Diffserv
Routers, RFC 3290, May 2002.
[65] Faye Ly and Gregory Bathrick, Definitions of Extension
Managed Objects for Asymmetric Digital Subscriber Lines,
RFC 3440, December 2002.
[66] Lou Berger, Ed., Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description,
[67] Loa Andersson and Tove Madsen, PPVPN Terminology,
draft-andersson-ppvpn-terminology-03, 30 April 2003.
[68] Bob Ray and Rajesh Abbi, Definitions of Managed Objects
for Very High Speed Digital Subscriber Lines (VDSL),
draft-ietf-adslmib-vdsl-09, 1 May 2003.
[69] Eric Mannie, Ed., Generalized Multi-Protocol Label
Switching Architecture, draft-ietf-ccamp-gmpls-architec
ture-06, 28 April 2003.
[70] Christian Groves, Marcello Pantaleo, Terry L. Anderson, and
Tom Taylor, Eds., The Megaco/H.248 Gateway Control
Protocol (MGCP), version 2, draft-ietf-megaco-h248v2-04,
3 April 2003.
[71] Kireeti Kompella and Yakov Rekhter, LSP Hierarchy with
Generalized MPLS TE, draft-ietf-mpls-lsp-hierarchy-08,
11 September 2002.
[72] Jeremy De Clercq, Olivier Paridaens, and Andrew
Krywaniuk, An Architecture for Provider Provisioned
CE-based Virtual Private Networks using IPsec,
draft-ietf-ppvpn-ce-based-03, 7 March 2003.
[73] Ross Callon and Muneyoshi Suzuki, Eds., A Framework for
Layer 3 Provider Provisioned Virtual Private Networks,
draft-ietf-ppvpn-framework-08, 26 March 2003.
[74] Loa Andersson and Eric C. Rosen, L2VPN Framework,
draft-ietf-ppvpn-l2-framework-03, 3 March 2003.

31
[75] Eric C. Rosen et al., BGP/MPLS VPNs, draft-ietf-ppvpnrfc2547bis-03, 25 October 2002.

[76] Luca Martini et al., Encapsulation Methods for Transport of
Ethernet Frames Over IP/MPLS Networks, draft-ietf-pwe3ethernet-encap-02, 19 February 2003.
[77] XiPeng Xiao et al., Requirements for Pseudo-Wire
Emulation Edge-to-Edge (PWE3), draft-ietf-pwe3-require
ments-05, 27 March 2003.
[78] Marc Lasserre, Vach Kompella, et al., Virtual Private LAN
Services over MPLS, draft-lasserre-vkompella-ppvpnvpls-04, 7 March 2003.
[79] Luca Martini et al., Encapsulation Methods for Transport of
Layer 2 Frames Over IP and MPLS Networks, draft-martinil2circuit-encap-mpls-05, 28 April 2003.
[80] Arnold Sodder et al., Virtual Hierarchical LAN Services,
draft-sodder-ppvpn-vhls-02, 29 April 2003.
TABLE OF CONTENTS
I. Introduction
II. Granularity of CORBA IDL Interfaces
III. Connection-Oriented and Connectionless
Transmission Layering (G.805 and G.809)
IV. TMF MTNM CORBA Information Model
A.
B.
Managing CORBA Objects

Managed MTNM Objects
V. TMN Functionality Supported by TMF MTNM

A.
B.
C.
D.
E.
Network Exploration and Monitoring

Network and NE Configuration and Control
SLAs and Rapid Service Provisioning
PM Points, TCA Parameter Profiles, ASA Profiles
Further Features and Interface Design Paradigm
VI. Integration of Specific Technologies

A.
B.
C.
D.
E.
F.
G.
H.
I.
3
7
7
8
9
9
9
9
11
12
12
Figure 1 Basic G.805 Modelling Concepts.

4
Figure 2 G.852.2 Transport Network Resource Model. 4
Figure 3 Fragment of TMF MTNM CORBA Model.
7
Figure 4 TMF MTNM Managed Objects Containment. 8
Figure 5 ATM and SDH Capable STM-4 Port.
8
Figure 6 IMA Group TP with Contained CTPs.
8
Figure 7 Relationships of TPs, TMDs, and TMCs.
10
Figure 8 State Transition Diagram of TMD State.
11
Figure 9 Gigabit Ethernet Port in an SDH/SONET NE. 13
Figure 10 DSL Reference Model with ATM Support. 13
Figure 11 Unstructured E1 PTP that Adapts to ATM. 14
Figure 12 Unstructured E1 PTP that Adapts to FR.
15
Figure 13 Structured E1 PTP.
15
Figure 14 Network Scenario for VoATM and VoDSL. 16
Figure 15 Control Plane Call, NC, MTNM Connection. 19
Figure 16 IP VPN according to RFC 2547bis.
21
Figure 17 MPLS Label Stack Examples.
22
Figure 18 Taxonomy of PP VPN Technologies.
22
Figure 19 PWE3 Reference Model.
23
Figure 20 Q-in-Q and MAC-in-MAC Separation.
24
Figure 21 Interconnected Provider Bridge Islands.
25
Figure 22 ITU-T CORBA Framework.
26
Figure 23 Examples of TMF814 Mediators.
28
TABLE OF TABLES
Table 1 Traditional Transmission Technologies
Table 2 TMF814 Managers and Managed Objects
Table 3 Interface Design Paradigm of TMF MTNM
Table 4 V5 Signalling Objects of TMF MTNM
PDH, SDH, SONET, OTN, ATM

13
Inverse Multiplexing, Ethernet, DSL
13
AAL, CE, FR, Channel Groups
14
CES, ATM-FR Interworking, Ethernet-over-ATM 15
Access Network Scenario for VoATM and VoDSL 16
Provisioning of Switched Voice Services
17
Dynamic Connection Provisioning (ASTN)
18
VoMSDN, IP Services, MPLS, PP VPN, GMPLS
19
Separation, MAC-in-MAC, Provider Bridges
24
VII. TMF CORBA versus ITU-T CORBA

A.
B.
C.
D.
2
3
TABLE OF FIGURES
ITU-Ts CORBA Framework

Mediation between ITU-T and TMF CORBA
Version Compatibility and Extension Mechanisms
Coexistence of TMF and ITU-T CORBA
Acknowledgements
References
Referenced IETF Documents
25
25
26
27
28
28
29
30
6
7
12
17

32
EDITORS NOTES
1) The 30 April 2003 issue of the document 26 was submitted as a paper proposal for the Design of Reliable
Communication Networks (DRCN) 2003 proceedings
(19-22 October 2003, see http://www.drcn.org/).
2) Important work on MTNM, with active Siemens participation, is in progress in SDOs during the next months.
While connection-oriented transmission layering and service provisioning are well understood (including inverse
multiplexing), the management issues of connectionless
layers, packet flows, topological link partitioning, hybrid
circuit/packet networks (HCPNs), automatically switched
transport networks (ASTNs), and traffic conditioning for
IP and Ethernet are currently under study by TMF, MEF,
OIF, and ITU-T. Siemens therefore announces the possibility to shorten general text and text on traditional technologies (PDH, SDH/SONET, OTN/DWDM, core ATM)
in future issues of the paper for the benefit of enhancing
text on emerging network technologies (IP, Ethernet,
MPLS, DSL, PP VPNs, HCPNs, ASTNs).
3) The proposals in this document have been formulated
to contribute to The Promotion and Evolution of TMF
MTNM. The document is not binding to the contributor(s),
the contributing company or any of their subsidiaries or
affiliates. Its contents are subject to change after further
study. Siemens specifically reserves the right to add to,
amend, or withdraw statements contained herein.
4) This work contains information supplied by Siemens
Aktiengesellschaft (AG) and all such information is supplied without liability for errors or omissions. No part
may be reproduced, disclosed, stored electronically, or
used except as authorized by contract or other written
permission by Siemens AG. The copyright and the foregoing restrictions on reproduction and use extend to all
media in which the information may be embodied. No
third party intellectual property right (IPR) liability is
assumed with respect to the use of the information contained herein. Siemens AG assumes no responsibility for
errors or omissions contained in this work. This document
and features described herein are subject to change or
omission without notice.
26
(i.e., without Section VI.I. and some updates to Section VI.H.)

Using Corba For MTNM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Using Corba For MTNM

Uploaded by

Copyright:

Available Formats

TM FORUM PROJECT:

MTNM Phase III Modelling Team

Using CORBA for MTNM

+49 89 722 62175

MTNM Exploder (MTNM@tmforum.org)

Using CORBA for Multi-Technology Network

A Contribution to The Promotion and Evolution of TMF MTNM

The Network Management Layer (NML) and Element Management

MTNM in the following. It applies to TOMs Network and

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

or more clients to leverage the functionality offered by the

called servants or incarnations. The Portable Object

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

so-called tandem connections, i.e. alternating sequences of

Figure 1 Basic G.805 Modelling Concepts.

Figure 2 (which is Figure 2/G.852.2 of [14]) provides an

network architectural components; these abstractions are

Port defined in Recommendation G.805

Figure 2 G.852.2 Transport Network Resource Model.

The inclusion of inverse multiplexing, adaptation and

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

tracts ATM header information; it consists of the upper

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

TABLE 1 TRADITIONAL TRANSMISSION TECHNOLOGIES

An SC is any connection that is established, as a result of

using the control plane. In the network portion of the SPC,

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

For examples of CO-PS and CLPS transport networks see

MTNM v2.1 Managed Object

By means of these object managers and managed objects

create and use traffic descriptors for TP and SNC bulk

NmsSession_I (at NMS)

TMF814 v2.1 and v3.x

GUI Cut Through Mgr

TMF814 v2.1 (continued)

Configurable Transmission Mode

TMF814 v2.1 (concluded)

Figure 3 Fragment of TMF MTNM CORBA Model.

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

cross-connected. The ATM VP CTP can be cross-connected

CTPs (per VC4)

Figure 5 ATM and SDH Capable STM-4 Port.

Figure 4 TMF MTNM Managed Objects Containment.

Figure 4 also shows a Proxy EMS that rehangs managed

Figure 6 shows the IMA model of TMF814 v3.0 (see

IMA Group TP (non-connectable FTP)

IMA Link (End) TP (server CTP)

Figure 6 IMA Group TP with Contained CTPs.

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

The model fully complies with the IMA Layer Reference

The core configuration and control tasks are provisioning

TMF814 v3.x adds the new Common operation setAdditionalInfo().

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

Using CORBA for Multi-Technology Network Management (MTNM)

A service profile, or service level specification (SLS), is a

specific representation, and the OSS has means to import/