This Recommendation is a part of a series of Recommendations defining the TMN paradigms for management of large-scale carrier networks. It is the scope of this Recommendation to provide an overview of:

Ÿ The evolving telecommunications networks architectures that provide for multi-service networking over packet-switched networks (e.g. IP and ATM).

Ÿ The interworking architectures and scenarios to allow interworking between traditional circuit-switched and HCPNs.

Ÿ The services and applications to be provided over the above architectures (e.g. Voice over IP).

Ÿ Management paradigms employed in managing IP Networks.

Ÿ Considerations for the extension of TMN toward the management of HCPNs.

Connections across administrative domains are included in the scope, however in this Recommendation no explicit provisions are made for these.

2 References

The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is published regularly.

- ITU-T, G.805 (2000), Generic Functional Architecture of Transport Networks.

- ITU-T, G.872 (2001), Architecture of Optical Transport Networks.

- ITU-T, M.3020 (2000), TMN Interface Specification Methodology.

- ITU-T, M.3010 (2000), Principles for a Telecommunications Management Network.

- IETF RFC 1901 (1996), Introduction to Community-based SNMPv2

- IETF RFC 3411 (2002), An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

- ITU-T X.720 (1992), Management information model

- ITU-T X.722 (1992), Guidelines for the definition of managed objects

- ITU-T Q.812 (1997), Upper layer protocol profiles for the Q3 and X interfaces

- ITU-T Q.811 (1997), Lower layer protocol profiles for the Q3 and X interfaces

- OMG Document formal/99-10-07, The Common Object Request Broker: Architecture and Specification, Revision 2.3.1.

- ITU-T X.780 (2001), TMN guidelines for defining CORBA managed objects

- ITU-T Q.816 (2001), CORBA-based TMN services

- ITU-T Q.816.1 (2001), CORBA based TMN services: Extensions to support coarse-grained interfaces

- ITU-T Q.814 (2000), Specification of an electronic data interchange interactive agent

- ITU-T Q.815 (2000), Specification of a security model for whole message protection

3 Definitions

For the purposes of this Recommendation, the following definitions apply.

3.1 Definitions Imported from ITU-T G.805

- access group;

- connection;

- layer network;

- link;

- link connection;

- subnetwork;

- subnetwork connection protection;

- trail.

3.2 Other Definitions in This Recommendation

This Recommendation defines the following terms:

3.2.1 Paradigm

A paradigm is a set of management functionalities that includes a protocol and associated services, as well as a supporting information definition language. It can be used to produce collections of management information including relationships among the management information to accomplish a given management objective. A paradigm must have mechanisms to support the definition of a library of management information.

3.2.2 Hybrid Circuit/Packet IP Network

A Hybrid Circuit/Packet IP Network is a network composed of both circuit-switched and IP packet-based layer (sub) networks.

3.2.3 Topology

See Section 6.2.1 for details.

3.2.4 Technology-Specific Network

A Technology-Specific Network(TSN) is a single layer network of the layer-based network model, which is only concerning about one technology, e.g. IP, ATM, SDH or Optical network.

3.2.5 Multi-Technology Networks

For the purpose of providing multiple services, assuring QoS and reducing operating costs, the core networks of service providers are usually composed of several technology-specific communication networks. There are various relations between these networks, and they may cooperate with each other to provide services. In this Recommendation, core networks composed of several interacting TSNs belonging to the same operator, are called Multi-Technology Networks(MTS).

3.2.6 Integrated Network Management System

Integrated Network Management System (INMS) is the managing system performing the integrated management of MTN. It is responsible for analyzing and processing of the management information collected from TSNs, and the integrated management of topology, configuration, fault and performance of several TSNs.

3.2.7 Technology-Specific Network Management System

Technology-specific Network Management System (TS-NMS) is the managing system performing the management of a TSN, including the management of the sub-networks and their relations. TS-NMS provides INMS the management information of topology, configuration, fault and performance of this TSN.

4 Abbreviations

This Recommendation uses the following abbreviations:

AAA	Authorization Authentication Accounting
ADM	Add and Drop Multiplexer
ATM	Asynchronous Transfer Mode
BLSR	Bidirectional Line Switched Ring
CMIP	Common Management Information Protocol
COPS	Common Open Policy Service
CORBA	Common Object Request Broker Architecture
DCS	Digital Crossconnect System
DEN	Directory Enabled Networking
EDI	Electronic Data Interchange
EMS	Element Management System
FCAPS	Fault management, Configuration management, Accounting management, Performance management, Security management
GSM	Global System for Mobile Communications
HCPN	Hybrid Circuit/Packet Network
HTTP	HyperText Transfer Protocol
IIOP	Internet Inter-ORB Protocol
IMS	IP Multimedia Subsystem
INML	Integrated Network Management sub-Layer
INMS	Integrated Network Management System
IP	Internet Protocol
LC	Link Connection
LDAP	Lightweight Directory Access Protocol
MS SPRING	Multiplex Section Shared Protection Ring
MTN	Multi-Technology Networks
NE	Network Element
NML	Network Management Layer
NMS	Element Management System
OS	Operations System
OSI	Open System Interconnection
OTN	Optical Transfer Network
POTS	Plain Old Telephone Service
PSTN	Public Switched Telephone Network
QoS	Quality of Service
RMI	Remote Method Invocation
SDH	Synchronous Digital Hierarchy
SMS	Service Management System
SNCP	Sub-Network Connection Protection
SNMP	Simple Network Management Protocol
SONET	Synchronous Optical Network
SS7	Signalling System No.7
STM-N	Synchronous Transport Module (level) N
TCP	Transfer Control Protocol
TMN	Telecommunications Management Network
TSN	Technology-Specific Network
TS-NML	Technology-Specific Network Management sub-Layer
UDP	User Datagram Protocol
UML	Unified Modeling Language
UPSR	Unidirectional Path Switched Ring
USM	User-based Security Model
VC	Virtual Circuit
VP	Virtual Path
WDM	Wavelength-Division Multiplexing
XC	Cross Connect
XML	eXtensible Markup Language

5 Overview

This Recommendation describes a framework for the integrated management of Hybrid Circuit/Packet Networks (HCPN). It begins in Section 6, with a description of the network environments in an HCPN that need to be supported within the integrated management framework. This description includes reference architectures and topologies. Section 7 describes Service environment, namely the relationship between technology-specific networks in the HCPN environment. Section 8 describes the management environment itself.

6 Network Environment of HCPN

This section proposes transport network architectures for use as a description of the network environment applicable to integrated management of HCPNs. The focus is on the transport view of network architectures. Signaling and control architectures are beyond the scope of this version of the Recommendation. Transport services for the control plane are supported by the transport architectures.

6.1 Overview

A set of reference architectures is provided. The architectures were developed on the basis of collective architectural input from service providers and are intended to provide the basis for multi-technology network architectures subject to study by the service providers.

Each reference architecture captures a grouping of technologies and configurations. The set of architectures exhibit a progression from current technology networks to future networks that will be based on technologies that in some cases are just now beginning to emerge. Due to the ample options allowed in the reference architectures, refinements will generally be needed to define use cases for specific network management functions.

Each reference architecture is constructed by overlaying a physical architecture with a layer domain architecture. The physical architecture identifies relationships among network elements and transport media; the layer domain architecture identifies specific adaptation relationships among transport layer domains. Four reference architectures are defined building on three distinct physical architectures.

Section 6.2 provides an overview concepts pertaining to generic network topology. Section 6.3 presents the reference architectures including an explanatory overview, a description of three physical architectures, and descriptions of the four reference architectures.

6.2 Network Topology Overview

In order to compare network topologies and examine the interactions of topologies across different technologies it is necessary to agree upon some generic terminology. ITU-T Recommendation G.805 Generic Functional Architecture of Transport Networks provides a good model for examining topology, allowing networks to be decomposed into layer networks that handle the different characteristic information. However, common usage architectural terms, such as SDH MS SPRING, (Multiplex Section Shared Protection Ring) while containing topological terms, such as ring, are not solely topological terms, but describe a combination of connectivity (topology) and equipment functionality across multiple layers (i.e., a ring configuration of physical links, Multiplex Section protection switching, ability to inhibit protection switching on selected Administrative Units). In order to relate common usage terms from different technologies to one another, a set of common terms needs to be agreed upon.

6.2.1 Topology Definitions

In this Recommendation, Topology is defined as the principle arrangement or relations of the objects/components used in describing a network to one another without regard to their actual occurrence in any real network.G.805 defines topological component as an architectural component, used to describe the transport network in terms of the topological relationships between sets of points within the same layer network.

6.2.1.1 Topology Components

G.805 describes four topology component types: layer network, sub-network, link, and access group. These terms can be used and in some cases simplified for our purposes.

A layer network refers to resources that support a specific characteristic information (e.g., STM-1). A layer network’s transport entities are identified by links, and its transport processing functions are identified by sub-networks and access groups. A lower, server layer network provides connectivity for higher, client layer networks at its access groups. Access groups indicate where paths may be terminated in a layer network. Each layer network has the potential to have its own unique topology.

G.805 allows portions of a layer network to be aggregated into larger sub-networks. However, when considering a layer network’s complete topology, we generally need to decompose all sub-networks to their lowest level, which correspond to fabrics.

Links represent fixed connectivity for a particular layer network. They are established by setting up trails between termination functions in a lower server layer network.

6.2.1.2 Layer Network Types

G.805 divides layer networks into two types:

- Transmission media layer network - a "layer network" which may be media dependent and which is concerned with the transfer of information between transmission media layer network "access points" in support of one or more "path layer networks".

- Path layer network - a "layer network" which is independent of the transmission media and which is concerned with the transfer of information between path layer network "access points".

For use in considerations of network management, it is useful to define two types of views of network architecture that are in the spirit of G.805 but with hooks into some of the more tangible elements of a network:

- Physical architecture – the configuration of 1) transport media and 2) Network Elements(NEs) or other devices that provide the ability to terminate physical transport layer signals.

- Layer network topology – the configuration of links connecting cross-connect fabrics (or sub-networks) or termination points (access groups) within a given transport layer.

The physical architecture is analogous to the configuration of transmission media layer network combined with specification of network elements. It is noted that in the transmission media layer for an optical transport network (in terms of fibers, not WDM optical paths, which are associated with a separate layer network) all paths are point-to-point between devices, or network equipment. The layer network topology is basically the topological configuration of a path layer network.

6.2.2 Generic Topology Types

Having defined different topological components, we need to agree on some generic terms for topology types. While these terms are familiar, they are often not well defined in common usage. The following definitions for generic topology types are proposed. Where possible, they are based on discrete mathematics terminology.

The simplest topology is point-to-point (see Figure 1) which is comprised of a link connecting two nodes.

Figure 1/M.3017 – Point-to-Point Topology

Stringing several nodes together serially with point-to-point links forms a linear chain topology (see Figure 2). The intermediate nodes provide cross-connect as well as termination functionality.

Figure 2/M.3017 – Linear Chain Topology

In a star topology (see Figure 3) all other nodes in the topology are only connected to one hub node. Only the hub node needs to provide cross-connect functionality; however, all connectivity is lost if the hub node is removed.

Figure 3/M.3017 – Star Topology

Sometimes in common usage the term “tree” is used to imply hierarchical routing. But in terms of connectivity it just indicates that there is only one route between any two nodes in the topology. Linear chain and star topologies are sub-classes of tree topology (see Figure 4), but any node in a generic tree topology may have links to more than two other nodes.

Figure 4/M.3017 – Tree Topology

A ring topology (see Figure 5) differs from the previous topologies in that it provides route diversity. Specifically, in a ring topology each node has exactly two links connected to it, so that the links form a ring. Thus, there are exactly two paths between any two nodes. (Logical rings may not have physical route diversity because of the underlying layer network topologies.)

Figure 5/M.3017 – Ring Topology

The term “mesh” is particularly ill defined in common usage, being neither a discrete mathematics term, nor a clear pictorial description. It is often used to mean a fully connected topology (described below), but sometimes it is just used to describe a more complex topology that cannot be described using one of the more restrictive terms defined above. In this Recommendation a mesh topology (see Figure 6) is defined simply as one in which there are two or more paths between at least two of its nodes. Using this definition, a mesh topology is one that contains a loop, so that it is not a type of tree topology, but may contain other links than those that form a single loop, which would be a ring. A simple mesh topology can be thought of as a conglomeration of several of the topologies above.

Figure 6/M.3017 – Mesh Topology

A fully connected mesh topology (see Figure 7) is sometimes referred to simply as a mesh topology; however, it is much more specific. There is a direct link between each node and every other node in this topology. No cross-connect functionality is required to connect any of the nodes, and should a point-to-point link fail, there is a high degree of route diversity to ensure continued connectivity. Fully connected mesh topologies do not scale well because N*(N-1)/2 links are required for N nodes.

Figure 7/M.3017 – Fully Connected Mesh Topology

There is another type of mesh that is of interest in terms of survivability. A highly connected mesh topology (see Figure 8) is defined as one that has at least two paths between each node and every other node. In such a topology, loss of any single link would not cause loss of potential connectivity between any of the nodes, and loss of any single node would not cause loss of potential connectivity between any of the other nodes. The simplest form of such a topology would of course be a ring.

Figure 8/M.3017 – Highly Connected Mesh Topology

6.2.3 Topology versus Architecture

What many people may consider as topologies, such as SDH MS SPRING or VC virtual ring, may be more accurately be described by the more generic terms, architectures or transport architectures, because they have implications on both topological (connectivity) and transport network functionality. G.805 defines an architectural component as any item used to generically describe transport network functionality.

For example, an SDH MS SPRING can be described as being composed of a ring physical architecture (point-to-point fiber terminating on successive pairs of ADMs arranged to form a ring) that supports a ring logical topology (comprised of e.g. point-to-point STM links connecting successive pairs of STM/VC cross-connect fabrics).

Note that in SDH/SONET, the term link refers to a bundle of pre-provisioned point-to-point link connections between two endpoints; in ATM (in a topology context) it more accurately represents a quantity of bandwidth between two endpoints.

An SDH VC virtual ring provides an example of how topologies at different layers are somewhat independent. An SDH VC virtual ring architecture does not define a particular physical topology, which could be a mesh (as in Figure 9) or even a linear chain. In the linear case, diverse routing is not achieved since the ring is collapsed. In the case of a DCS physical mesh, a ring could be configured through the mesh in conjunction with DCS ring functionality; diverse routing would need to be guaranteed by selection of non-overlapping ring segments.

A virtual ring topology could be formed in the VC-3 Path Layer, for example, by creating point-to-point VC-4 trails as clients of the STM-4 and STM-1 layers to form a ring. If Sub-Network Connection Protection (SNCP) switching functionality is available at the VC-3 layer, the virtual ring could operate as a protection ring.

Continuing with the example in Figure 9, assume that all of the equipments have ATM VP termination capability and the equipment on the STM-4 ring also have ATM VP cross-connect capability. VC-3 trails were created from each node to the one on the far left then the ATM VP layer network would have a star topology. If instead, VC-3 trails were created among all of the nodes on the STM-4 ring then the ATM VP layer would have a fully connected mesh network. The other equipment would not appear at the ATM VP layer because there was no connectivity provided to them by VC-3 trails.

Figure 9/M.3017 – Topologies at Physical and Logical Layers

6.3 Reference Architectures

In this section, four reference architectures are presented. Each reference architecture consists of two views of a network:

- Physical Architecture – the configuration of physical transport media and NEs. The possible types of NEs that may be included are identified. NE types are defined in terms of the types of cross-connect or switching fabric(s) supported and may include supported adaptations of transport layers at trail terminations.

- Layer Domain Architecture – the configuration of transport layers related through adaptation of server layer bandwidth to client layer connections. This view indicates support of flexible connections or inflexible connections within each transport layer. In addition, it shows mappings of services to layer domains

Each reference architecture is formed by associating a specific layer domain architecture with one of three physical architectures.

Other network views may be overlaid on a reference architecture comprised of these components. It is expected that the reference architectures described in this Recommendation will be refined via additional specifications when applied to specific use cases. These refinements may include:

- Specific combinations of NEs and NE connectivity

- Protection architecture of the physical transport layer

- Subnetwork topologies and protection architectures of logical transport layers

- Subnetwork topologies specific to component transport layers within a technology layer

- Specific connections between termination points

- Specific segment of the network (e.g. long haul, metropolitan area, secondary/access)

Subnetwork topology gives the configuration of transport bandwidth and cross-connect/switching resources representing the potential connections within a single transport layer. An example of component transport layers within a technology layer is STM regenerator section, STM multiplex section, VC-11, VC-12, VC-2, VC-3, VC-4 component layers within the aggregate SDH layer.

6.3.1 Physical Architectures

Three physical architectures are described. They are presented in the time order in which they will likely appear in implementations. For each physical architecture, the potential NE types are listed and the configuration of physical transport media is identified. An example configuration is constructed for each architecture and is shown in a figure. It is noted that the figures are intended to depict example configurations to help visualize the architectures; they should not be viewed as excluding other example configurations. In particular it is noted that hybrid NEs may include cross-connect or switching fabrics for any combination of technologies supported by a given architecture. The use of the term SDH in the figures below is meant to refer to either SDH or SONET.

6.3.1.1 SDH/SONET Ring-Based Physical Architecture

This physical architecture has the following properties:

- Physical topology is based on SDH/SONET ring – either MS SPRING (SONET BLSR) or SONET UPSR(Unidirectional Path Switched Ring).

- NE types connected by ring include: SDH/SONET ADMs and DCS; hybrid SDH/SONET/ATM/IP NEs are possible.

- Ring interconnection via DCSs or ADMs via dual node interconnection.

- SDH/SONET ring protection plus ATM protection mechanisms possible.

An example configuration is shown in Figure 10.

Figure 10/M.3017 – Example Physical Configuration of SDH/SONET Ring-based Physical Architecture

Although the DCS is included in this ring scenario, it does not have widespread acceptance as a viable SDH/SONET ring element. It is noted that a variety of protection architectures are possible for protecting services in the ATM layer.

6.3.1.2 Optical ADM Ring-Based Physical Architecture

This physical architecture has the following properties:

- OTN (Optical Transport Network) - architecture based on ITU-T G.872

- Physical topology is a fiber optic ring transporting multiple wavelengths

- NEs on the fiber optic ring include OTN ADMs and hybrid ADMs comprised of any combination of OTN/SDH/ATM/IP

- Dual interconnection to other subnetworks

- Variety of protection methods possible

An example configuration is shown in Figure 11.

Figure 11/M.3017 – Example Physical Configuration of Optical ADM Ring-based Physical Architecture

The standards basis in G.872 is referenced as a goal, with the understanding that pre-standard implementation agreements are allowed. An OTN ADM can add/drop Optical Channel signals each of which is transported as a distinct wavelength.

6.3.1.3 Optical Mesh-Based Physical Architecture

This physical architecture has the following properties

- OTN - architecture based on ITU-T G.872

- Physical topology is a fiber optic mesh; fiber carries multiplexed wavelengths

- NEs on the optical mesh include OTN Cross-Connect(XC) and hybrid NEs based on OTN and any combination of SDH, ATM, and/or IP.

- A variety of protection and restoration methods are possible.

An example configuration is shown in Figure 12.

Figure 12/M.3017 – Example Physical Configuration of Optical Mesh -based Physical Architecture

An OTN XC can cross-connect Optical Channel signals each of which is transported as a distinct wavelength.

6.3.2 Key for Reference Architecture Figures

The legend used in the reference architecture diagrams is described in the following text and in Figure 13. A technology layer domain is indicated by an oval shape. The downward thick arrow indicates an adaptation relationship between a client transport layer on top and a server layer below. A client layer may be supported by several server layers. Mappings of services (rectangular boxes) to layer domains are identified. Different symbols are used to indicate flexible transport layers and fixed transport layers. A flexible layer allows flexible routing of connections via cross-connect or switching functionality.

The composition of a domain may be based upon a single transport layer (e.g., Virtual Path) or a grouping of layers such as that included within a technology (e.g., ATM, including both VP and VC). The term layer is used in the G.805 sense, referring to transport of signals of a given characteristic information (e.g. VC-3 path). It is useful to select a domain based on collective behaviour, for example, common capabilities for connection set up. For the purposes of developing reference architectures, aggregate layers associated with a given technology are used without splitting out component transport layers.

Figure 13/M.3017 – Legend for Reference Architecture Figures

In the reference architecture figures below, colour coding is used to match NEs in the physical architecture with the supported transport layers in the layer domain architecture (not visible in black and white/grayscale editions).

6.3.3 Reference Architecture 1A

This reference architecture combines Physical Architecture 1 with a layer domain architecture that transports ATM and IP over SDH and carries circuit-switched services over ATM and SDH.

Figure 14/M.3017 – Reference Architecture 1A

6.3.4 Reference Architecture 1B

This reference architecture combines Physical Architecture 1 with a layer domain architecture that transports ATM and IP over a flexible SDH infrastructure and over an (inflexible) SDH framing mechanism. In addition, this architecture enables IP to be transported over ATM. Circuit-switched services are carried over ATM and SDH as in the previous architecture.

Figure 15/M.3017 – Reference Architecture 1B

6.3.5 Reference Architecture 2C

This reference architecture combines Physical Architecture 2 with a layer domain architecture that builds on the capabilities of layer domain architecture B. Wavelength (l) services are supported via the flexible OTN layer. Circuit-switched services may be carried over SDH, ATM, and/or IP. IP may be transported via ATM, SDH framing, and/or directly over the OTN, assuming suitable digital framing/wrapper is provided. ATM traffic may be carried over a flexible SDH network, SDH framing, or directly over the OTN. Both flexible and inflexible (point-to-point) SDH signals may be transported over OTN.

Figure 16/M.3017 – Reference Architecture 2C

6.3.6 Reference Architecture 3C

This reference architecture combines Physical Architecture 3 with the layer domain architecture C described in the previous reference architecture. It is noted that protection may be provided via OTN mesh techniques, SDH rings, and/or ATM and IP layer methods depending upon the protection strategy implemented.

Figure 17/M.3017 – Reference Architecture 3C

7 Service Environment of HCPN

7.1 The relationship between technology-specific networks in HCPN environment

According to the provided functions, telecommunication networks in the HCPN environment may be divided into several TSNs, such as IP network, ATM network, SDH network, and Optical network. There are bearing or interworking relationships between these TSNs, as shown in Figure 18.

Figure 18/M.3017 –The Layer Network Architecture of HCPNs

A service layer network is composed of several service sub-networks. The relationship between service sub-networks can be client/server or peer/peer. GSM, PSTN and SS7 are examples of the service sub-networks, where SS7 provides signalling transmission service for GSM and PSTN. A service layer network can be borne by Optical transport network, SDH transport network, ATM transport network, and IP transport network.

In an HCPN environment, the bearing relationship is the most important vertical association among related TSNs.The bearing relationship indicates that a client layer service is actually carried by a server layer network. Figure 18 shows some applicable bearing relations in HCPN environment. A server layer network may have more than one client layer network. For example, both IP and ATM networks may be supported by SDH transport networks, and SDH itself can also be borne by Optical network.

In the future, interworking relations among MTNs are expected. When two interworking TSNs do not have a client/server relationship, they are peers from the services point of view. There are some typical examples of interworking relations between TSNs: an IP network interacts with a circuit switching network, and a GSM network interacts with a PSTN network. The inter-connection between two TSNs is usually implemented by gateways.

8 Management Environment in hybrid circuit/packet networks

8.1 TMN Management Architectures for HCPN

8.1.1 Logical Architecture

Figures 19-22 show different possible scenarios that may be used to configure management functionality. It should be noted that the approaches assume that a management layer approach is used to configure network management capabilities.

A Semantic mediator function acts to normalize the information model between the two types of networks. In these logical architectures, the existence of a semantic mediator embedded in an operations system is implicit at the point where the management of the two networks is integrated. Only external semantic mediators are shown explicitly.

8.1.1.1 Descriptions for Logical Architecture Option 1

Figure 19/M.3017 – Integrated Management of HCPNs Option 1

Figure 19 shows the first option of the integrated management of HCPNs. In this figure, the NEs may be classified into three kinds, the circuit-switched NEs, the packet-switched NEs and the interworking NEs, which can be viewed as bridges between circuit-switched and packet-switched NEs.

The Infrastructure EMS is the Element Management Layer systems that are responsible mainly for managing the circuit-switched NEs and interworking NEs through interface 1A. Here the ellipse of EMS is just a conceptual EMS, which may actually represent many EMS instances which may be EMSs of the same vendor performing different functionalities or EMSs of different vendors managing different network domains. It is considered as the infrastructure EMS because it may provide basic management functions that are domain or technology-independent, and may be used to perform some management functions across different technologies. For some legacy reason, vendors may choose to use the infrastructure EMS to manage both circuit-switched and packet-switched NEs for some specific management function (alarm management, for example). In this case, the packet-switched NEs shall also provide Interface 1A to the appropriate Infrastructure EMS, which is the same interface as provided by circuit-switched NEs.

The IP EMS is responsible for the element layer management for packet-switched NEs as well as interworking NEs through Interface 1B, which is different from Interface 1A (for example, Interface 1B may be an SNMP-based interface).

Both Infrastructure EMS and IP EMS provide Interface 3 to an NMS, and the NMS performs the network layer integrated management functions of HCPNs, and may manage several technology-specific networks. The NMS also provides Interface 5 to Service Management System (SMS).

8.1.1.2 Descriptions for Logical Architecture Option 2

Figure 20/M.3017 – Integrated Management of HCPNs Option 2

Option 2 (see Figure 20) is the same as option 1, except that it is that in this case, the circuit-switched NEs shall also provide Interface 1B to the appropriate Infrastructure EMS, which is the same interface as provided by packet-switched NEs. The packet-based NEs only provide a typical interface for the IP EMS.

8.1.1.3 Descriptions for Logical Architecture Option 3

Figure 21/M.3017 – Integrated Management of HCPNs Option 3

Option 3 (see Figure 21) is the same as option 1, except that there is an explicit semantic mediation function in-between the packet-switched NEs and the infrastructure NEs.

This option releases the burden of packet NEs, which may just provide the same interface to EMSs of different kind; while the “Semantic Mediator” becomes a complex function for implementors.

8.1.1.4 Descriptions for Logical Architecture Option 4

Figure 22/M.3017 – Integrated Management of HCPNs Option 4

Option 4 (see Figure 22) is the same as option 1, except that the semantic mediation function has been moved up in the management layer. While option 1 shows a single NMS providing the semantic mediation function to the separate EMSs, option 4 shows separate NMS feeding into an additional NMS that is providing the semantic mediation function.

Option 4 shows the possibility of integrated management of an HCPN in a layer-based approach in which the network management layer(NML) can be divided into two sub-layers: the technology-specific network management sub-layer (TS-NML) and the integrated network management sub-layer (INML). These sub-layers differ in management scope, management objectives and management functions.

The Infrastructure EMS and IP EMS are EML OSs and provide Interface 3A and Interface 3B to the Infrastructure NMS and IP NMS respectively.

The Integrated Network Management System(INMS) is an INML OS which mainly manages the relations between TSNs. The Infrastructure NMS and IP NMS are TS-NML OSs, each of which manages a single technology-specific network, and provides the necessary management information to INMS through Interface 4. There are not necessarily any interfaces between different TS-NML OSs. Based on the management information collected form Interface 4, INMS provides the provisioning of transmission service across two or more TSNs, maintains the end-to-end view of MTN facilities and supports the management of services involving two or more TSNs, and analyses the source fault or/and predicts the future performance trends involving two or more TSNs. The TS-NMS does not need to provide all the resources to INMS through Interface 4. Generally, only the resources connecting two or more TSNs are visible to INMS. In cases where special purpose management operations are required, such as a specific protection assignment for a bearing network, more resources information should be stored in INMS to achieve this goal, which may show information of two adjacent layers in different TSNs.

The service management system (SMS) just interacts with the INMS in HCPN environment through Interface 5, which avoids the potential costs of an SMS interacting with several TS-NML OSs. The main purpose for this management architecture is to decrease the coupling of related TSNs in HCPN environment, and to provide operators a cross-border view of an HCPN. The INMS is responsible to maintain the relationship information among TSNs, and does the work which one single TS-NML OS cannot achieve. It works as a coordinator for cross-network border management activities.

8.1.2 IP-Based Management Architectures

In its simplest form, the IP-based management architecture can be described as management protocols providing for the exchange of messages which convey management information between the managed elements and the management stations. RFC1901 In IP-based management, the management station does not always have as clear a distinction between EMS and NMS as is typically found in TMN-based networks. The term mid-level manager is often used to indicate the case where there is a management station acting as an intermediary between another management station and a managed element.

While management is not always formally discussed in terms of Fault, Configuration, Accounting, Performance and Security (FCAPS), these areas are all present in varying degrees. Given the connectionless nature of IP routing, monitoring functions have historically placed more emphasis on performance management compared with other functions. Other areas such as alarm management, have received more attention in recent years, though.

8.1.3 SNMP-based Architectures

RFC3411 defines an SNMP management system as containing:

- several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator applications, which have access to management instrumentation (traditionally called agents);

- at least one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and,

- a management protocol, used to convey management information between the SNMP entities.

RFC3411 defines managed elements as devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.

SNMPv1 defines the following protocol operations: get, get-next, set and trap and allows for many simple data types based on integer and strings. SNMPv2c added get-bulk, 64bit counters and changed the PDU format. SNMPv3 added security and introduced new terminology.

Management information consists of “managed objects” which are individual data items, e.g., integers and strings, defined using the Structure of Management Information (SMI). These are accessed via a virtual information store, termed the Management Information Base (MIB). The scope of the MIB is typically one managed entity. Managed objects are organized into simple groups or into tables.

8.2 Protocol Architectures and Interworking

In this Recommendation, TMN management paradigms are classified as general purpose paradigms (suitable for all management applications) and special purpose paradigms (designed to satisfy some specific management application(s)).

To be considered as a general purpose paradigm, the paradigm must satisfy the following criteria:

- Scalability (10⁶ – 10⁷ objects)

- Compatibility with existing models

- Support for multiple managers

- Support for query capabilities

- Support for data modification capabilities

- Support operations on set valued attributes

- Support multiple object access

- Selective access of attributes

- Support operations on multiple objects

- Support of autonomous notifications

- Subscription to receipt of autonomous notifications

- Well defined notifications

- Support for modeling of the containment relationship

- Support of unique names

- Support of creation and deletion semantics

Special purpose paradigms will be accompanied by a description of the management space that they are addressing.

Special purpose paradigms will exist because for their particular application they may offer a performance advantage or economic benefit.

For example it may be possible to classify HTTP, SNMP, XML and JINI as special purpose protocols and CMIP, IIOP and Java RMI as general purpose protocols. The special purpose protocols would be associated with information models that are semantically consistent with the general purpose protocols and the protocol and functional transformations would be done at a gateway. For instance, SNMP may run to a gateway, provide none of the event filtering capabilities required, be collected via traps at the gateway and then filtered and further processed at the gateway.

8.2.1 General Purpose Paradigms

General-purpose paradigms support the overall functioning of the TMN. They can be used at both Qx and X interfaces. They support a common object oriented semantic model of resources. They provide protocols and services that allow these resources to be managed.

8.2.1.1 OSI System Management

The OSI System Management paradigm is based on the architecture of systems management found in ITU-T Recommendation X.720. The resources are modeled using the notation of ITU-T Recommendation X.722 (GDMO). The protocols specified in ITU-T Recommendation Q.812 for the Upper Layer Protocol Specification of the OSI Paradigm are used. These protocols may use a variety of lower layer protocols specified in ITU-T Recommendation Q.811 including Internet Protocols.

8.2.1.2 CORBA

OMG CORBA can be used in a variety of ways within TMN. When used as a general purpose paradigm the guidelines found in ITU-T Recommendations X.780 and/or X.780.1 are followed. In addition the services found in ITU-T Recommendations Q.816 and/or Q.816.1 are used. The protocol used is found in ITU-T Recommendation Q.812 in the section on the protocol profile for CORBA based services. This protocol profile uses the Internet Protocol profile found in ITU-T Recommendation Q.811.

8.2.2 Special Purpose Paradigms

8.2.2.1 EDI

EDI/EDIFACT may be used at the TMN X interface to support TMN service layer interactions. The protocol profile used to support EDI/EDIFACT is found in ITU-T Recommendation Q.812 in the section on Protocol Profile for EDI/EDIFACT Based Services. This protocol profile used ITU-T Recommendation Q.814 to the Interactive Agent protocol and, if needed, ITU-T Recommendation Q.815 to provide whole message security. This protocol used the Internet Protocol lower layers specified in ITU-T Recommendation Q.811.

8.2.2.2 SNMP

SNMP is suitable for use in interfaces between Network Elements and Element Management Systems. The details for using this protocol are part of Q.811/Q.812

The fundamental reason that SNMP is not available as a general purpose paradigm is that it may not support the existing models. There does not seem to be a prescriptive way of mapping the existing models into SNMP. It is also the case that a paradigm must be capable of being used in an object-oriented manner, and capable of multiple object addressing and multiple object operations. In addition, support for modeling of the containment relationship, unique names, and creation and deletion semantics is conceivable, but not trivial.

_________________

INTERNATIONAL TELECOMMUNICATION UNION		STUDY GROUP 4
TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 2001-2004		TD 81 (PLEN)
		Original: English
Question(s):	10/4	5 - 14 February 2003
TEMPORARY DOCUMENT (Ref. : COM 4 – D 109 – E)
Source:	Rapporteur, Q.10/4
Title:	Framework for the Integrated Management of Hybrid Circuit/Packet Networks