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 +49 89 722 62175 Email Address [email protected] DATE: 12 May 2003 FILE NAME: Using-CORBA-for-MTNM-12-May-2003.doc DISTRIBUTION: MTNM Exploder ([email protected])

SUMMARY This document is a contribution to The Promotion and Evolution of TMF MTNM. It provides an intro-duction to MTNM’s CORBA information model including important agreed features of v3.x and a cou-ple 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 MTNM’s CORBA model to ITU-T’s 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 specifi-cally reserves the right to add to, amend, or withdraw statements contained herein. See also the EDITOR'S NOTES.

Copyright 12 May 2003 Siemens AG. All Rights Reserved.

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: [email protected]

A Contribution to The Promotion and Evolution of TMF MTNM

Abstract – TeleManagement Forum (TMF) develops the in-dustry standard for MTNM through its specification of the NML-EML interface (TMF814). The current version 2.1 in-cludes PDH, SDH/SONET, OTN/DWDM, and core ATM. Version 3.0 will add inverse multiplexing, Ethernet tributary interfaces, DSL, various profile mechanisms, and further en-hancements. 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 TMF’s 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 connec-tionless transmission layering thereby enabling the seamless integration of any desired transmission technology. It outlines the principal behaviour of TMF MTNM’s 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 TMF’s MTNM model in a straightfor-ward 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 ongo-ing activities, the development of the Multi-Technology Network Management (MTNM) NML-EML Interface.1 TMF’s 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 group-ings called logical layers and describes the relationships between these layers to deal with telecom management complexity.

MTNM in the following. It applies to TOM’s Network and Systems Management Processes, including Network Plan-ning & Development, Network Provisioning, Network In-ventory 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], im-plementation statement template and guidelines [2], a pro-tocol neutral information model with UML diagrams and class dictionary [3], and requirements and use cases [4].

The paper is not a summary of TMF MTNM’s deliver-ables but focuses on two really unique aspects of MTNM’s CORBA information model that are not found elsewhere and enable seamless integration of new or currently emerg-ing technologies into TMF MTNM. The supporting docu-ments Overview of the NML-EML interface.htm and lay-ers.pdf (Functional Modelling Concepts) of [1] are the start-ing point for these considerations. The range of CORBA features required for CORBA-based telecom management are Revision 2.3 of OMG’s CORBA specification (see [5]) and the OMG Naming Service (see [6]).

TMF MTNM is a client/server interface between an Ele-ment Management System (EMS) and a Network Manage-ment 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 particu-lar 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 de-tailed compliance list that states all interface implementa-tion details that are actually available for clients as well as applicable restrictions, e.g. [2] and a vendor-specific sup-plement. The description of an SBI requires the full specifi-cation of the corresponding NBI as a prerequisite. It in-cludes the main use case packages that can be used by one

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 façade or a first-level object while an object that is managed by a façade is referred to as a light object or a second-level object.

Generally the design of façades is application-specific but the weakest form of coarse granularity, the class granular-ity, 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 façade 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 cli-ent), 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 suffer-ing, with fine-grained CORBA environments for telecom management purposes. Object-oriented network manage-ment interfaces typically model umpteen millions of enti-ties, 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 vendor’s system design must take into consideration how an extremely large number of distributed CORBA ob-jects can be handled efficiently. This issue addresses the way how the objects are implemented within their respec-tive 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 speci-fied 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 implementa-tion code route covered to connect to the respective servant and execute the request. Moreover, the POA allows to per-sistently 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 ser-vants 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 façade may manage several related managed object classes, [9]-[12] refer to ITU-T’s class-grained approach.

III. CONNECTION-ORIENTED AND CONNECTIONLESS TRANSMISSION LAYERING (G.805 AND G.809)

A transport network conveys telecommunications infor-mation 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-T’s famous Rec. G.805 (see [13]) considers each specific signal to be bound to a con-nection-oriented transmission layer and introduces the term characteristic information (CI) for the signal. It decom-poses the transport network into a number of independent single layer networks with a client/server association be-tween 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 con-cepts of partitioning and layering are orthogonal: a down-wards vertical transmission layering is supplemented by a recursive horizontal layer network partitioning. A single layer network describes the generation, transport, and ter-mination of a particular characteristic information.

Layer networks are partitioned into appropriate subnet-works and links between them, and subnetworks and links may be further partitioned. A network partitioning implies the connection partitioning of its network connections into



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 net-works, 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 underly-ing 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 repre-sents 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 accompany-ing 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 differ-ent reference point and pipe concepts used in connection-oriented TMN functional models.

T1304480-95

TrailAP AP

Trailtermination

Network connection

TCP SNCCP

Link connection

Trailtermination

TCP

Client toserver

adaptation

Clientlayer

network

Trail

Client toserver

adaptation

APAP

Trailtermination

Trailtermination

Serverlayer

network

TCP

SNC

CP

LC

CP

LC

CP

LC

CP

SNC

TCP 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-T’s 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 net-work resource model is termed Transport Network Enter-prise Model (TEM). The most important resources are the Connection Termination Point (CTP) and the Trail Termi-nation 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 trail-termination part of the TCP and the accompanying trail termination together with the server-layer part of the adap-tation 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.

T0410250-98

AP TCPSNC CP

LC TCP AP

AP TCPSNC

CP LC TCP AP

Clientlayer

Trailtermination

Subnetwork Link Trailtermination

Connection termination pointClient to

server adaptation

Serverlayer

Trailtermination

Subnetwork

Connection termination

point Connectiontermination

point

Link

Connection termination point

Trailtermination

point

Trailtermination

Port defined in Recommendation G.805

Trailtermination

point

Network connection Trail

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 lay-ers, 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 sec-tions, 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. inde-pendently of the underlying networking technologies. Its power is revealed when applying it to technologies of a concrete environment. The application consists of the iden-tification of the individual layers, their characteristic infor-mation, 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



voice channel.2 A PDH layer corresponds to one of the ba-sic 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 com-monly 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 struc-ture 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 mul-tiplexing 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-2-Xv, 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 trans-mission media layer (SONET line or SONET section) STS-n or OC-n (n = 1, 3, 12, 24, 48, 192, 768), which corre-spond to SDH section layers. Here -Xc resp. -Xv refers to the contiguous resp. virtual concatenation of X equal Vir-tual 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 trans-mission of digital signals with prescribed block frame struc-tures 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 opti-cal section layer OCh, OChr, OMSn, OTSn, OPSn (n >= 0). Here -Xv refers to the virtual concatenation of X equal Op-tical 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 OCh’s resp. OChr’s (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 ODU1’s resp. for up to 16 ODU1’s and/or up to 4 ODU2’s.

The ATM Protocol Reference Model (PRM) according to ITU-T Rec. I.321 defines two path layers above the physi-cal 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 ex-

2 For some applications DS0 paths may need to be channelizable into inde-pendent 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) to-wards 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 pay-load 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 accord-ingly. It performs VCI and VPI translation at ATM switch-ing or cross-connect nodes to redirect the cell streams. The VC layer CI is a stream of VC layer AI and F5 OAM in-formation. The VP layer CI is a stream of VP layer AI, which includes multiplexed VC layer CI, and F4 OAM in-formation. 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 Sec-tion VI. INTEGRATION OF SPECIFIC TECHNOLOGIES.

A connection can be a permanent connection (PC) or a semi-permanent connection (semi-PC) or a switched con-nection (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 cross-connection 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 technology-dependent PC types may be configurable to become semi-permanent, i.e. they are still dedicated to a subscriber but created and then separately activated. Semi-PCs are ready-to-use configured in the network (i.e., persistently created) but only activated or deactivated when requested by a dial-up or shut-down call from the end user’s CPE.



TABLE 1 – TRADITIONAL TRANSMISSION TECHNOLOGIES

Technology Layer Type Layers Digital Prime DS0

E-Carrier E1, E2, E3, E4, E5 PDH (CO-CS)

G.703, G.705

T-Carrier T1, T2, T3

LOVC TPath 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)

HOVC TPath VC-3, VC-3-Xv, VC-4, VC-4-Xc,

VC-4-Xv Multiplex Section

STM-n (n = 0, 1, 4, 8, 16, 64, 256)

SDH (CO-CS)

G.707, G.783,

G.803

Regenerator Section

STM-n (n = 0, 1, 4, 8, 16, 64, 256)

VT TPath VT-1.5, VT-1.5-Xv, VT-2, VT-2-Xv,

VT-3, VT-6, VT-6-Xc, VT-6-Xv

STS TPath STS-SPE, STS-Xc, STS-Xv, STS-3c-SPE, STS-3c-Xc,

STS-3c-Xv SONET Line STS-n, OC-n

(n = 1, 3, 12, 24, 48, 192, 768)

SONET (CO-CS)

T1.105, GR-253

SONET Section

STS-n, OC-n (n = 1, 3, 12, 24, 48,

192, 768) Digital Path OPUk, OPUk-Xv,

ODUk (k = 1, 2, 3) Digital Section

OTUk, OTUkV (k = 1, 2, 3)

Optical Path OCh, OChr

OTN (CO-CS)

G.709, G.798,

G.872

Optical Section

OMSn, OTSn, OPSn (n >= 0)

Path VC, VP ATM (CO-PS)

I.150, I.326, I.731, I.732

TPath UNI, NNI

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 ele-ments within the control plane(s). An SPC is a user-to-user connection where the user-to-network portion of the end-to-end connection is established by the network management system as a PC (e.g., a link connection). The network por-tion 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 envi-ronments (see ITU-T Recs. Q.2766.1 and Q.2767.1), re-quirements 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 connec-tionless 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 con-tain 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 connec-tionless (CL) layer interworking, M.3017 considers the cir-cuit-switched (CS) and packet-switched (PS) layer inter-working, 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 im-plemented with IP (using best effort, destination-based for-warding) and those implemented with Ethernet. M.3017 defines a Hybrid Circuit/Packet Network (HCPN) as a net-work 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 tech-nologies of a concrete environment (e.g., specification of IP and Ethernet flow points over transport networks).



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 CON-NECTIONLESS TRANSMISSION LAYERING (G.805 AND G.809) provide broad background to two unique aspects of TMF MTNM’s CORBA information model (see [1]) not found elsewhere that enable seamless integration of new or cur-rently emerging technologies into TMF MTNM: façades 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 façades of TMF814, called object man-agers, and the MTNM managed objects they manage.

TABLE 2 – TMF814 MANAGERS AND MANAGED OBJECTS

TMF814 Manager (CORBA façade object with IOR)

MTNM v2.1 Managed Object managed by, or used by, CORBA façade object

ME Manager managed element (ME), termination point (TP) (PTP, CTP, TPPool), alarm,

AID, cross-connection, TD, MLSN MLSN Manager multi-layer sub-network (MLSN)

(includes singleton), sub-network connection (SNC) (includes cross-connection), topological link (TL),

TPPool, CTP, PTP, route, TD EQP Manager equipment (EQP), equipment holder

(EQPH) (various types), PTP EMS Manager element management system (EMS)

object, TL, alarm, AID, MLSN TD Manager traffic descriptor (TD), TP PM Manager performance management (PM) object

(PM location, granularity, PM parame-ter, TCA parameter, PM data), TP, ME

Protection Manager protection group (PGP), TP Maintenance Mgr maintenance operations, TP

GCT Manager GUI cut-through (GCT) widget data, GCT launch command data

root interfaces (are not façades)

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 man-

aged 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 Connec-

tions (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 con-figure new measures and schemes as required

• receive notifications (alarms, TCAs, events) in a stan-dardized format and configurable way, with filter capa-bilities, and without receiving unsolicited notifications

• pull on demand active alarms and TCAs in the notifica-tion 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 documen-ted 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 hier-archy 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 exten-sions”, “TMF814 v2.1 (continued)”, “proprietary exten-sions (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.

Core Functionality

ME Mgr MLSN Mgr EQP Mgr EMS Mgr TD Mgr

Protection Mgr Maintenance Mgr GUI Cut Through Mgr

TMF814 v2.1 and v3.x

proprietary extensions

TMF814 v2.1 (continued)

Notifications

Observable Observer(at NMS)

proprietary extensions (concluded)

ProcessingFailureException TMF814 v2.1 (concluded)CosNotification::*

Configurable Transmission Mode

Version_I

Session_I

EmsSession_I Common_IEmsSessionFactory_I

NmsSession_I (at NMS) EventChanneluser name& password

root interfaces

PM Mgr

TMD Mgr

inheritance

containment

<TMF814 Mgr>

Figure 3 – Fragment of TMF MTNM CORBA Model.

The six rows are now explained. The row “root inter-faces” 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 façades of the EMS can be obtained. The row also includes the virtual interface Common from which all façades inherit.

The row “TMF814 v2.1 and v3.x” shows the core man-agers ME, MLSN, EQP, and the further managers EMS and TD. The Transmission Descriptor (TMD) Mgr is a gener-alization of the TD Manager from ATM to any technology. It will be part of TMF814 v3.x (see Section V.C.).



The row “proprietary extensions” shows a proprietary fa-çade <TMF814 Mgr> that inherits from the core managers. The row “TMF814 v2.1 (continued)” shows further stan-dardized managers. Refer to TMF814A (see [2]) for imple-mentation 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 excep-tion 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 support-ing document iterators.html of [1]) are important CORBA interfaces of TMF814 but are not shown in Figure 3. B. Managed MTNM Objects

While façades are identified by CORBA IORs light ob-jects are identified by (full) distinguished MTNM names, which are name/value pair lists (see supporting document objectNaming.html of [1]). Relationships between light ob-jects are modelled by a naming hierarchy. Figure 4 shows the corresponding MTNM object hierarchy of TMF814.

EMS

TL TDMLSN

SNC TPPool

TMD (v3.x)

Proxy EMS

EQPH

ME

AID

EQPCTP PMP (v3.x)

TMC (v3.x) TCAPP (v3.x)

ASAP (v3.x)

GTP (v3.x)

PGPPTPorFTP (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 scale-ably 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 ex-tend the layering concepts set out there by using multi-layer encapsulations identified from real network element behav-iour 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 capa-ble 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

cross-connected. The ATM VP CTP can be cross-connected or further terminated to provide ATM VC CTPs.

CTPs (per VC4)63 x LR_VT2_and_TU12_VC12and3 x LR_Low_Order_TU3_VC3

CTPs4 x LR_STS3c_and_AU4_VC4

PTP

LR_Line_OC12_STS12_and_MS_STM4

LR_Section_OC12_STS12_and_RS_STM4

LR_DSR_OC12_STM4

LR_OPTICAL_SECTION

LR_PHYSICAL_OPTICAL

CTPs (per VC4)1 x LR_ATM_NI

CTPs (per ATM NI)n x LR_ATM_VP

CTPs (per ATM VP)n x LR_ATM_VC

Figure 5 – ATM and SDH Capable STM-4 Port.

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 contain-ing FTP with respect to their common connectable layer (e.g., LR_E1_2M) by use of an index.

LR_ATM_NI(degraded)

LR_ATM_VP

* 4095

LR_Fragment

e.g., LR_E1_2M

* n

IMA Group TP (non-connectable FTP)<PTPStyleName>/atmnetworkinterface=1

IMA Link (End) TP (server CTP)e.g., .../atmnetworkinterface=1/e1=<e>

ATM VP CTP.../vpi=<p>

SNC Supporting CTP Figure 6 – IMA Group TP with Contained CTPs.



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 interface-specific (lower) TC sublayer is represented by the fragment layer of its server CTPs. The IMA Virtual Link can be rep-resented 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 imple-mented by its responsible CORBA façade. The best over-view of managed object behaviour, i.e. supported TMN functionality, can be obtained by reading TMF MTNM’s 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 attrib-utes 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) façade 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 façades) 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 Notifi-cation 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 unso-licited notifications, and then connects to the Notification Service to be able to receive notifications matching the fil-ter 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 se-lected 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 “Provision-ing 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 op-eration setTPData() that is used to change the TP mapping mode, to assign and unassign TDs and TMDs, and to mod-ify the multi-layered transmission parameters.

Regarding SNCs refer to the use case package “Connec-tion 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 activa-tion 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 pack-age “Equipment use cases” and the EQP manager opera-tions 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 net-work 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 synchro-nization 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 de-fining 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 specifica-tion 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().



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 archi-tecture, 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 con-nection and flow provisioning. Each extremity of a connec-tion 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 pro-vider domain) defining provider responsibilities in terms of service profile characteristics (especially grades of service), times of availability, methods of measurement, conse-quences if service levels are not met by the provider (ser-vice degradation or failure) or granted traffic levels are ex-ceeded 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 spec-ify classifier rules and a traffic profile whose rules are to apply to the traffic streams selected by the classifier. A traf-fic 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 band-width 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 net-work, 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 im-plicit 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 manage-ment (ATMF AF-TM-0121, ITU-T I.371), DSL line con-figuration on a massive scale (ITU-T G.997.1, IETF RFC 2662/3440/3276, DSLF TR-057), IP DiffServ traffic condi-tioning (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 serv-ice provisioning and conditioning through appropriate man-aged 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 pro-files 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 par-ticularly 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 load-ing 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

TMC-1-1

TMC-1-2

...TMC-2 eTMD-2

iTMD-2...

iTMD-1

Figure 7 – Relationships of TPs, TMDs, and TMCs.

The containment of a TMC in a TP enforces traffic con-ditioning on the TP when the TMC is applicable to the traf-fic received at the TP. The containment of TMCs in a TMC



represents the TMC as a TCB. Similarly TMDs can be con-tained 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 modifica-tion 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 configura-tions 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 de-gree of consistency of a TMD assignment on a TP the TMD state is introduced to the MTNM model. Its transition dia-gram 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

PENDING

APPLIED

TMD_MISSING

MISMATCH

setTPData() w/o TMD

deleteTMD() or internal fault

setTPData() with TMD

setTPData() with TMD

TP configuration in progress

setTPData() with null

TMD

setTPData() w/o TMD

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 re-source that can be applied to multiple network elements (in multiple subnetworks). Therefore the determination of cur-rent 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 over-head 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 verifi-cation operation verifyTMDAssignment().

The configuration of TMCs is quite similar to TP con-figuration (see Section V.B.). If an ME hosting a TMC be-longs to a policy-enabled environment according to IETF RFC 2753, the TMC can be regarded as a policy enforce-ment point (PEP). If a service provisioning policy is defined for the network, or at least for a subnetwork resp. flow do-main 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 us-ing these profiles. Refer to TMF053, The New Generation Operations Systems and Software (NGOSS) Technology-Neutral Architecture (TNA), with Annexes TMF053C and TMF053P, the Business Agreement TMF514, EML-NML Requirements for Management of IP Networks and Ser-vices, of TMF’s IPNM team, and IETF RFC 3198, Termi-nology 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 benefi-cial 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 over-all dynamic network performance objectives. D. PM Points, TCA Parameter Profiles, ASA Profiles

TMF814 v3.x supports further automation features be-sides service profiles and traffic profiles through new object types; these are Performance Monitoring Point (PMP), TCA Parameter Profile (TCAPP), and Alarm Severity As-signment 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 MTNM’s 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 loca-tion, 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 TCAPP’s layer rate. With TCAPPs the thresholds of PMPs can be configured in an automated way and on a large scale similar to the con-figuration of TP and TMC parameters with TMDs.



An ASAP parameter is an association of an alarm type, identified by a Probable cause value, and a perceived se-verity, identified by an Alarm status value. An Alarm Se-verity 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 pa-rameters, an ASAP can also be written to a layer by using the transmission parameter ASAPpointer. An ASAP assign-ment 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 (includ-ing ITU-T’s 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 (façade) since MTNM façades 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 façades; try to keep operations technology-independent since technology-specific issues are meant to be placed inside managed objects as attrib-ute 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 parame-ters or the use of existing parameters

• for objectives not yet modelled otherwise, define addi-tional 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 MTNM’s performance manage-ment 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 MTNM’s 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 parame-ters. All these attributes are strings or name/value pairs with string names and values. Therefore it is straightforward, in principle, how to integrate into TMF’s MTNM information model technology-specific layered architectures and man-agement details specified somehow by other standards de-velopment 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 transmis-sion 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)



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 agree-ments 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

LR_Line_OC12_STS12_and_MS_STM4

LR_Section_OC12_STS12_and_RS_STM4

LR_DIGITAL_SIGNAL_RATE

LR_OPTICAL_SECTION

LR_PHYSICAL_OPTICAL

LR_DSR_Gigabit_Ethernet

LR_PHYSICAL_ELECTRICAL

CTP

PTP

CC

LR_STS3c_and_AU4_VC4

1

LR_Encapsulation

N

LR_Ethernet

LR_Fragment

LR_STS3c_and_AU4_VC4

LR_Fragment

Fragmentationadaptation

Figure 9 – Gigabit Ethernet Port in an SDH/SONET NE.

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

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. MEF’s Metro Ethernet Network (MEN) Architecture Framework (see [29]) and ITU-T’s 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. TMF’s MTNM team will use this basic work to introduce Ethernet bridging and VLAN in TMF814 v3.x and align MEF’s EMS-NMS infor-mation model (see [12]) with TMF MTNM’s CORBA in-formation model (see Section IV.) and TMF IPNM’s infor-mation model (TMF611, see Section VI.H.). Refer to Sec-tion VI.I. for some preliminary details.

Figure 10 shows TMF MTNM’s DSL reference model with ATM support. TMF814 v3.x defines MTNM models for DSL lines (with autonomous, integrated, and unman-aged TU-Rs), transmission layer rates for DSL technology, probable cause identifiers for alarms raised by these layers, use cases for DSL line provisioning, transmission parame-ters for ADSL, SHDSL, and VDSL (i.e., the current/read-only and desired/configurable characteristics of these basic DSL types), DSL states and statuses, DSL maintenance operations, and DSL performance parameters (see [28]).

DSL TU-R(Transceiver Unitat the Remote site)

DSL TU-C(Transceiver Unit

at the Central office)

DSL TU-O(Transceiver Unit at theOptical network unit)

- or -

remote DSL PTP (zEndTP)(e.g., on DSL modem at CP)

local DSL PTP (aEndTP)(on plug-in unit of DSLAM or MSAP)


LR_ATM_NI

LR_DSL

LR_DIGITAL_SIGNAL_RATE

TLATM Link

TLDSL Line

interconnectivity

physical

upstream

downstream

Figure 10 – DSL Reference Model with ATM Support.

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 SNMP’s SMI syntax having many G.997.1 parameters as attributes and also further attributes. DSL Forum’s 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.



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 Forum’s TR-057 and IETF’s draft-ietf-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 parame-ters 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 tim-ing, and with loss and error indication; AAL2 for band-width-efficient connection-oriented real-time or non real-time variable bit rate services with high delay sensitivity, and with loss and error indication; AAL3/4 for connection-oriented/connectionless variable or available bit rate ser-vices with delay tolerance and with sophisticated delivery assurance; AAL5 for connection-oriented and connec-tionless 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 Cir-cuit (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 func-tion (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 en-capsulates 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 chan-nels 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

LR_E1_2M (Encapsulated CP)

LR_DSR_2M


CTP (of kind F) with layers

LR_E1_2M (Encapsulated CP)

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 con-figuration 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 interwork-ing 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.



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 chan-nel 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.

PTP (of kind A) with layers

LR_E1_2M

LR_DSR_2M


CTP (of kind C) with layer

LR_FR_IF

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 configur-able 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.

PTP (of kind A) with layers

LR_E1_2M

LR_DSR_2M


CTP (of kind D) with layer

LR_DS0_64K

* 32

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 struc-turing of an E1 PTP into 32 DS0 CTPs.

CE terminology uses the terms unstructured data trans-mission (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 unstruc-tured 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 re-ducing 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 con-tained in the physical T1/E1 link. Since all time slots can be assigned to some channel group no idle time slots need ex-ist. 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 broad-band TDM services have to be adapted so that they can be transported across the ATM infrastructure without reduc-tion 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 AF-VTOA-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 provi-sioning of an enhanced ATM VC CTP. This amounts to the definition of appropriate transmission parameters. The sup-port of DBCES that enhances CES (and AAL1) with detec-tion and reutilization of inactive time slots (AF-VTOA-0085) and the AAL2-based Broadband Loop Emulation



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 net-work and service interworking between Frame Relay and ATM technologies according to FRF.5 and FRF.8.1 respec-tively. 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 de-mand 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 sup-plementing 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 high-speed connections of the ATM channels and Ethernet links to the subscribers and inverse multiplexing techniques con-tribute 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 in-tegrated way over DSL - whether ADSL or SHDSL or VDSL - are referred to as Voice over DSL (VoDSL). It re-fers 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.

OTN/DWDM

Cascade

SDH

MSAP

DSLAM

DSLAM

DSLAMIMA

IMA

DSLAM

PSTNAMGW ATM-XC

ATM-XC

TDMFrame Relay

ATM

IP BRAS

IAD

IAD

IAD

ATM

Frame Relay

TDM / CES

IP

Internetaccess

ISDN

POTS

Video

LANInterconnection

Service (LIS)

ISDN

IP IAD

IAD

ISDNPBX access (S2M/V2M)

POTS

IAD

DSL

DSL

DSL

voice data voice and data

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 traf-fic 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 Re-mote Access Server (BRAS), to an Internet service pro-vider 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 ser-vices 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 perma-

nent, 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 sig-

nalling capabilities derives from the requirement to enable



seamless integration of TMF814-based EMSes into multi-vendor and multi-technology management environments for VoATM and VoDSL networks. F. Provisioning of Switched Voice Services

The access domain is concerned with integrated multi-service 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 Inte-grated 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 opti-cal network unit (ONU) that bundles the voice-grade chan-nels 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 termina-tion (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 al-ways completely ATM-based, namely VoATMoDSL be-tween 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 SDH-based (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 func-tions 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 signal-ling channels. In case of Classic Voice these interfaces are also used at the subscriber side, while for VoATM the 7 Classic Voice with its ONUs and OLTs is not shown in Figure 14.

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 intro-duced 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 c-channels 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 struc-tured 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 corre-spond to the supporting CTPs of IMA and are cross-connected 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 V5 link PTP or CTP with upper layer LR_E1_2M

physical V5 c-channel

DS0 CTP contained in a V5 link and carrying signalling information

V5 user port CTP with layer LR_POTS or LR_ISDN_BRI, contained in a V5 interface at its client side

V5 c-channel CTP with upper layer LR_FRAGMENT and lower layer LR_COMM_CHAN,

contained in a V5 interface at its server side V5 c-path third-level object embedded in a c-channel

and specifying common signalling information

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-time-slots 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)



• a vital protocol (i.e., a signalling protocol that is man-datory 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 man-agement 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 ATM-based it is important to point out that the same model ap-plies for other transmission technologies between the ONU and the OLT. It applies in particular to the case of IP trans-mission 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 char-acteristic voice information at the edges of the NGN, com-ing 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 TMF’s IPNM team (see Section VI.H.). G. Dynamic Connection Provisioning (ASTN)

An automatically switched transport network (ASTN) en-compasses 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 be-tween one or more user applications and the network to control the establishment of sets of connections. Call con-trol must provide co-ordination of connections (in a multi-connection 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 glob-ally 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 destina-tion 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 implementa-tions 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: User-Network Interface (UNI), Internal Network-to-Network In-terface (I-NNI), External Network-to-Network Interface (E-NNI). The UNI is a bidirectional signalling interface be-tween service requester and service provider entities. The I-NNI is a bidirectional signalling interface between entities belonging to one or more domains having a trusted relation-ship (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 in-formation while the UNI requires some security information from a peer entity. The UNI is generally used between un-trusted 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



used between untrusted interface networks, there is no to-pology information exchange. The I-NNI allows the ex-change 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 representa-tion of the NC in the management plane in MTNM terms.

Domain A

UNI

Client E-NNI

Domain B

E-NNI

Domain C

UNI Connection

UNI

Client

UNIConnection

SubnetworkConnection

Subnetwork Connection

Subnetwork Connection

E-NNI Connection

E-NNI Connection Control Plane

MLSN B SNC b

MTNM Model MLSN C SNC c

MLSN A SNC a

TL 1 LC 1

TL 3 LC 3

TL 2 LC 2

TL 4 LC 4

Transport Plane Network Connection (SC, SPC)

Figure 15 – Control Plane Call, NC, MTNM Connection.

Note, however, that the MTNM information model cur-rently 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 OIF’s OAM&P working group and as core part of the TMF814 v3.x evolution, TMF’s MTNM team has begun studies regarding enhance-ments of SNC management in support of dynamic connec-tion 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 SNPs in SNP state Busy or Potential are not available for allocation.

A, EMS B, EMS C) managing the three MLSNs. It is gen-erally 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 ses-sion 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 notifica-tions, 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 in-stead 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, how-ever, 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 tradi-tional 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 IETF’s 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



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 gener-ated 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 evo-lution 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 informa-tion from input they receive by Customer Premises Equip-ment (CPE). A CPE can be a multi-service-capable Inte-grated Access Device (IAD) or a simple Network Termina-tion (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 con-nected to the ONU through a DSL modem.

The AGWs of VoMSDN networks generate or concen-trate 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, Packet-Based Multimedia Communications Systems, are of great importance, and even more are SIP-enabled devices accor-ding 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 inte-grated 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 capa-bilities of the CPE. The service provider may retain owner-ship of the managed CPE or, alternatively, it may be pur-chased 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, revenue-generating IP services. Examples are business-class Internet access, LAN interconnection service (LIS), secure IP VPN, VoIP, converged services like IP Centrex, managed band-width by class-based queuing (CBQ) or low-latency queu-ing (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 ser-vices directly but to be able to establish e2e connectivity for the IP domain thereby supporting the delivery of IP ser-vices. 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 TMF’s 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 Re-quirements for Management of IP Networks and Services, the IA TMF611, IPNM NML-EML Interface, Information Agreement, and the SS TMF8IP, IPNM NML-EML Inter-face, CORBA IDL Solution Set. TMF’s 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, draft-ietf-ppvpn-rfc2547bis-03) and MGCP-based VoIP (respec-tively Open Packet Telephony (OPT)). Besides it is the team’s ambition to study the feasibility of enhancing TMF814-like EMSes by Policy-Based Network Manage-ment (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 MTNM’s own Ethernet and VLAN modelling (see Section VI.B. and Section VI.I.).

An IP service of particular interest to the corporate cus-tomers 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 parti-tioned for use by individual users; and the VPN employs the security, management, and throughput policies of a pri-vate 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 cus-tomer to create IP connectivity between the sites. IP VPNs have therefore occasionally been hailed as the killer appli-cation 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 com-mon IP network called the backbone (e.g., a private IP net-work or the public Internet). From the perspective of a par-ticular IP backbone, a site is a set of (ports of) IP systems (i.e., hosts or IP routers) having mutual IP connectivity that



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 sub-sets 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 provid-ers. 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 pro-vider core (PC) router. Since the backbone is assumed to be all IP the layer 2 service that attaches a CE to a PE is termi-nated at the edge of the backbone, where the customer’s 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 con-nectivity and services (e.g., only one SP operates the subset over the backbone). An AS uses one or more interior gate-way 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 forward-ing mechanisms must be integrally aware of the IP VPN partitioning without having to use overlay models to estab-lish 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 run-ning IP over ATM because they needed greater bandwidth, deterministic forwarding performance, and traffic engineer-ing (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 pro-tocol architectures of IP and ATM, and has inherent scale-ability 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 site’s 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 Bor-der 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 multi-protocol 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 SP’s backbone, it is encapsulated with the MPLS label that corresponds, in the customer’s VPN, to the route that is the best match to the packet’s destination ad-dress. 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 back-bone PC routers do not need to know the VPN routes.

Figure 16 summarizes the outlined IP VPN concepts. 9 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].



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

• specify IP sites as PTP pools11, 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.

• make a check on suitability of existing façades and managed objects for use with MPLS according to the in-terface design paradigm of TMF MTNM (see TABLE 3)

• introduce the control plane and MBGP

• phrase a complete use case package for IP VPN confi-guration, monitoring, and control

IETF working groups have introduced the concepts of Provider-Provisioned (PP) VPN and Pseudo Wire Emula-tion Edge to Edge (PWE3). PP VPNs generalize and sup-plement the RFC 2547-style VPNs and are based on cus-tomer edges (CEs), provider edges (PEs), attachment cir-cuits (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 draft-sodder-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 provi-sioned) 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.

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 Net-work (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 PE-based 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



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 attrib-utes 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 (vir-tual 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 Customer Edge 1 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 in-cludes 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-l2circuit-encap-mpls-05). The industry is now standardizing on Mar-tini 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 Pri-vate 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 co-ordination of MPLS work in TMF’s MTNM and IPNM teams and MEF Technical Committee’s Management Sub-Group, similar to the planned co-operation on Ethernet bridging and VLAN modelling (see Section VI.B.), is there-fore 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 ca-pable 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-gmpls-architecture-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 capa-ble (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 avail-able in the traditional MPLS by the label stack mecha-nism13, 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)



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 man-agement (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

VPNs can be considered as logical connectivity objects to which sites may be attached and which may be intercon-nected 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 connec-tion-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 packet-switched 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-to-multipoint (P2MP, also known as hub-and-spoke), multi-point-to-multipoint (MP2MP, also known as full or partial mesh), and hierarchical topologies.

The used separation technology should include a multi-plexing/demultiplexing facility to allow for multiple cus-tomers and optimized resource usage in the same edge-to-edge connection or flow. If the separation mechanism does not provide multiplexing, this can be accomplished by a stacking/nesting procedure that repeats the payload encap-sulation 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 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.

Q-in-Q

MAC-in-MAC

Provider network Customer network

Customer #A

Customer #B

Customer #C

Customer #A

Customer #B

Customer #C

Customer network

Figure 20 – Q-in-Q and MAC-in-MAC Separation.14

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 pro-vider 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 SP’s backbone network.16 Customer VLAN identifiers are assigned to unique L2VIDs. The VHL Service (VHLS) reference model places L2PEs between CEs 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 SP’s 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 SP’s backbone network may support up to 224-2 = 16777214 VPN instances.



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 today’s 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 further-reaching 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.

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-1ad-provider-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].

VII. TMF CORBA VERSUS ITU-T CORBA

TMF MTNM as summarized in Section IV.A. Managing CORBA Objects and Section IV.B. Managed MTNM Ob-jects is now related to the CORBA NE and network man-agement 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 is-sues that are also briefly discussed.

It is explicitly recommended not to (try to) adopt TMF MTNM’s information model to ITU-T’s information model, as proposed e.g. in [44], since it would eliminate important goodies of the TMF MTNM model. Instead a co-operation of TMF’s MTNM team and ITU-T’s SG 4 is recommended to bring TMF MTNM’s goodies into ITU-T’s framework. A. ITU-T’s 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: • protocol requirements, CORBA Common Object Ser-

vice (COS) usage requirements, and TMN-specific sup-port services for basic capabilities of managed systems (including support of coarse-grained interfaces), regard-less of the type of network technology being managed (CBTS Q.816 [32], CCBTS Q.816.1 [7], fault manage-ment 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 (façades) inherit basic capa-bilities 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 be-comes 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



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 spe-cific to a particular network technology before being in-cluded in a commercial interface specification

Managed Object

Managed Object Factory

Standard Data Types

GDMO to IDL Other Conventions

Managed Element

Link

Inherits……

Application-specific Objects: Notification

Service

Telecom Log Service

Notification Specifications

TerminatorService

Multiple Object Operation Service

NamingService

Channel Finder

Factory Finder

Names

CORBA 2.3 ORB

Heartbeat Service

Containment Service

Names

Services:

Managed Element Factory

LinkFactory

Managed Object Façade

Managed Element Façade

Q.816.1 M.3120AF-NM-0185DSLF TR-050Q.834.4etc.

Q.816Q.821.1Q.822.1X.744.1etc.

X.780X.780.1

Superclasses:

Conventions:

etc. etc.

etc. etc.

…

Network Façade

Link Façade

Connection Façade

Network

ConnectionConnection

Factory

NetworkFactory

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 net-work 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 MEF’s 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 diffi-cult. 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.

B. Mediation between ITU-T and TMF CORBA

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 customer’s 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 • 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 exten-sion (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-T’s 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 sec-ond 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 con-sent nor resources in the MTNM team to do this work.

For the same inherent reasons, and even more impor-tantly for customers, it is much easier and cheaper to de-velop 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 cus-tomers 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 pre-sent 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)



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 technology-neutral templates and technology-specific templates for the technologies supported by the respective TMF814 version.

The starting point of the TMF814 mediation layer speci-fication 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 appli-cable 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 run-time 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-T’s SG 4 and TMF’s MTNM team.21 As a consequence TMF MTNM could be enhanced step-by-step by the goodies of ITU-T’s 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, façades 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 ver-sion compatibility issues for their respective interface.

It is explicitly recommended not to (try to) adopt TMF MTNM’s information model to ITU-T’s current informa-tion model, as proposed e.g. in [44], since this would elimi-nate 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 high-est priority for TMF814 v3.0 has been backward compati-bility of NBI, to protect investments in v2.x EMSes, pref-erably 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 com-patible and interface forward compatible starting with ver-sion 2.0. For example, TMF814 v2.1 fulfils the require-ment. 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 under-stood that the agreement is too stringent and does not allow proper implementation of a significant feature, then inter-face 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 with-out 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 includ-ing 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 declara-tions (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 de-

scribed 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 MTNM’s versioning concept(s). 23 A general purpose extension mechanism applies to any MTNM man-aged object class (see Figure 4), allows to specify supplementary informa-tion 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 façade, and can be attached to the object by some defined means (e.g., by repeating the object identifier within the extension specifi-cation, or by an inheritance mechanism). Multiple extensions, all of differ-ent types, can be attached to the same managed object. 24 The introduction of the hybrid valuetype & struct extension mecha-nism 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.



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 parame-ters 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 recast-ing of TMF814’s managed objects according to the ITU-T framework thereby replacing the MTNM façades (see TABLE 2) by new façades 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 second-level object state was to use CORBA data structures, i.e. CORBA’s 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 ca-pability 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 sim-plest 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 mem-bers 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 sup-port value types and should achieve considerable perform-ance 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 compatibi-lity 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 to-wards 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 simpli-fied 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 ex-amples 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.).

TMF814

ITU-T TMF814

ITU-T ONC RPC

TMF814 TMF814

SNMP

TMF814

SOAP/XMLPNBI

SBI

Mediator X

Figure 23 – Examples of TMF814 Mediators.

In each case the mediator may leverage for the NBI func-tionality 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 de-velopment 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-T’s 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 TMF’s MTNM team and IPNM team for their contributions, e-mail discus-sions, and participation in face-to-face meetings. Likewise the work of ITU-T’s 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



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, http://www.tmforum.org/browse.asp?catID=926&sNode=926&Exp=Y&linkID=24230.

[3] TMF, MTNM NML-EML Interface, Information Agree-ment (IA), TMF608 v2.1, August 2002, http://www.tmforum.org/browse.asp?catID=926&sNode=926&Exp=Y&linkID=20309.

[4] TMF, MTNM NML-EML Interface, Business Agree-ment (BA), TMF513 v2.1, September 2002, http://www.tmforum.org/browse.asp?catID=926&sNode=926&Exp=Y&linkID=24195.

[5] Object Management Group, The Common Object Re-quest 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 Coarse-Grained CORBA Managed Object (GDCCMO) Inter-faces, Rec. X.780.1, August 2001; Corrigendum 1, Rec. X.780.1/Cor.1, May 2002; Amendment 1: System Façades 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 Infor-mation Model, Revision 4, Document D00012_004, 24 April 2003.

[13] ITU-T SG 13, Generic Functional Architecture of Transport Networks, Superseded Rec. G.805, Novem-ber 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 Connection-less Layer Networks, Rec. G.809, March 2003.

[21] ITU-T SG 4, Framework for the Integrated Manage-ment 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) Technol-ogy, 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 Pro-file, 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 Man-agement Service, Rec. Q.822.1, October 2001; Amend-



ment 1: Generic Transport Performance Management, Rec. Q.822.1/Amd.1, March 2003.

[36] ITU-T SG 4, CORBA-Based TMN Software Manage-ment 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 Novem-ber 2001.

[39] Nortel Networks, Extension Mechanism for the MTNM Interface, TMF MTNM Contribution, 31 May 2002.

[40] Telcordia Technologies, ValueTypes for MTNM Exten-sions, 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 Re-sources, 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 Pro-tocol 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,” RFC 2753, January 2000.

[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,” RFC 3471, January 2003.

[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.



[75] Eric C. Rosen et al., “BGP/MPLS VPNs,” draft-ietf-ppvpn-rfc2547bis-03, 25 October 2002.

[76] Luca Martini et al., “Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks,” draft-ietf-pwe3-ethernet-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-ppvpn- vpls-04, 7 March 2003.

[79] Luca Martini et al., “Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks,” draft-martini-l2circuit-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 2 II. Granularity of CORBA IDL Interfaces 3 III. Connection-Oriented and Connectionless

Transmission Layering (G.805 and G.809) 3 IV. TMF MTNM CORBA Information Model 7

A. Managing CORBA Objects 7 B. Managed MTNM Objects 8

V. TMN Functionality Supported by TMF MTNM 9 A. Network Exploration and Monitoring 9 B. Network and NE Configuration and Control 9 C. SLAs and Rapid Service Provisioning 9 D. PM Points, TCA Parameter Profiles, ASA Profiles 11 E. Further Features and Interface Design Paradigm 12

VI. Integration of Specific Technologies 12 A. PDH, SDH, SONET, OTN, ATM 13 B. Inverse Multiplexing, Ethernet, DSL 13 C. AAL, CE, FR, Channel Groups 14 D. CES, ATM-FR Interworking, Ethernet-over-ATM 15 E. Access Network Scenario for VoATM and VoDSL 16 F. Provisioning of Switched Voice Services 17 G. Dynamic Connection Provisioning (ASTN) 18 H. VoMSDN, IP Services, MPLS, PP VPN, GMPLS 19 I. Separation, MAC-in-MAC, Provider Bridges 24

VII. TMF CORBA versus ITU-T CORBA 25 A. ITU-T’s CORBA Framework 25 B. Mediation between ITU-T and TMF CORBA 26 C. Version Compatibility and Extension Mechanisms 27 D. Coexistence of TMF and ITU-T CORBA 28

Acknowledgements 28 References 29 Referenced IETF Documents 30

TABLE OF FIGURES

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 6 Table 2 – TMF814 Managers and Managed Objects 7 Table 3 – Interface Design Paradigm of TMF MTNM 12 Table 4 – V5 Signalling Objects of TMF MTNM 17



EDITOR’S NOTES

1) The 30 April 2003 issue of the document 26 was sub-mitted 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 par-ticipation, is in progress in SDOs during the next months. While connection-oriented transmission layering and ser-vice 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 possi-bility to shorten general text and text on traditional tech-nologies (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 sup-plied 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 fore-going 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 con-tained 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

Documents

mtnms corba model

mtnm phase

mtnm source

mtnm exploder

mtnms corba information

corba idl

overview of tmfs mtnm

corba object modelling