Control Plane and Management System Integration Scenarios ......This paper shows how the TMF-814...

Control Plane and Management SystemIntegration Scenarios

1

FUJITSU NETWORK COMMUNICATIONS INC.2801 Telecom Parkway, Richardson, Texas 75082-3515Telephone: (972) 690-6000(800) 777-FAST (U.S.)us.fujitsu.com/telecom

IntroductionDifferent standards organizations such as the IETF, ITU-T and OIF are working towards standardization ofthe control plane (e.g., G-MPLS) protocol suite including neighbor discovery (e.g. LMP), routing (e.g. OSPF-TE) and signaling (e.g. RSVP-TE) protocols. These protocols are integrated in the network elementand provide topology discovery and accurate inventory, both of which are necessary for reliable pathcomputation and connection management. Standardization, followed by control plane interoperability,should ultimately allow setting up and tearing down end-to-end connections within a multi-vendornetwork environment with minimum intervention by management systems.

On the other hand, work on the specification of an interoperable interface (TMF-814) between NMS andEMS by organizations, such as the TMF, will ultimately allow an NMS to manage a multi-vendor networkthrough respective vendors’ EMS products. This interface currently supports connection management, faultmanagement, performance management, inventory and other functions. The connection managementinterface uses the divide-and-conquer approach where the NMS can break end-to-end connections withina multi-vendor network environment into multiple sub-connections delimited by different EMS-controlledsub-networks. The EMS is responsible for computing the path and setting up the end-to-end sub-connectionwithin the sub-network.

This paper shows how the TMF-814 (MTNM interface) may be upgraded to support control plane enablednetworks so that management systems can set up and tear down end-to-end connections across hybridnetworks (i.e., a mix of control plane enabled networks and legacy networks).

Control Plane Call/ConnectionThe control plane supports two types of connections: SC and SPC. PC, a third type, was defined to representconnections setup explicitly by management planes (i.e., provisioning of cross-connects).

The SC is a connection type where a client device initiates the setup request (call request) and the controlplane establishes the connection (connection request) via signaling (see Figure 1).

For your convenience, a list of acronyms can be found at the end of this document.

2


The SPC consists of two PC segments at both ends of the end-to-end connection with one SC segment inbetween. The EMS requests the creation of the SC segment (call request) while the control planeestablishes the connection (connection request) via signaling (See Figure 2).

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Sub-Network

Connection

UNI

UNI

E-NNI

Connection

E-NNI

Connection

Sub-Network

Connection

Switched Connection

Client

Call

Request

Client

Sub-Network A

Sub-Network B

Sub-Network C

Sub-Network

Connection

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Figure 1: Control Plane Connection Initiated by a Client Device (Switched Connection)

Figure 2: Control Plane Connection Initiated by an EMS (SPC)

Permanent

Connection

NETSMART 1500 Software Platform

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Sub-Network

Connection

E-NNI

Connection

E-NNI

Connection

Sub-Network

Connection

Transport Switched Connection

Permanent

Connection

Client

Client

Call Request

Sub-Network

Connection

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

Sub-Network A

Sub-Network B

Sub-Network C

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

3


The topology information of the transport network (i.e., sub-network A, sub-network B and sub-network C)is exchanged over the NNI (i.e., I-NNI and E-NNI), which provides the information necessary for the pathcomputation of SPC and SC. Only limited topology information is exchanged over the E-NNI, while fulltopology information is exchanged in the sub-networks over the I-NNI interface (not shown in the figures).

MTNM CORBA Interface ArchitectureThe MTNM interface provides a CORBA-based interface between two management systems (e.g., betweenan NMS and an EMS). This interface provides a level of abstraction to an NMS of the network to bemanaged by supporting a common set of objects and operations. The main functions supported by thisinterface are topology and inventory discovery, fault management, performance management andconnection management.

Figure 3: Distributed Network Management System using MTNM interface


NETSMART 1500 Software PlatformNETSMART 1500 Software Platform

EML

NEL

CORBA

MTNM Interface

NML

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Sub-Network

Connection

Top-Level

Topological

Links

Top-Level

Topological

LinksSub-Network

Connection

Sub-Network C

Sub-Network B

Sub-Network A

EMS A

EMS B

EMS C

Network Management System

Sub-Network

Connection

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

In a distributed network management system using the MTNM interface (see Figure 3), the NMS has anabstract view of the entire network, where the EMS plays the role of middleman, providing the NMS anabstract segment of this network (i.e., the sub-network).

4


In the MTNM architecture, sub-networks are interconnected by topological links. If these interconnectedsub-networks are managed by different EMSs, then these interconnections are represented by top-leveltopological links. In this interface, an EMS has no knowledge of other EMSs participating in themanagement of the network. As a consequence, an EMS can only report single-ended top-level topologicallinks. The NMS is responsible for interconnecting these sub-networks by manually associating these top-level topological links.

The topology and inventory retrieved from the underlying sub-networks, combined with the top-leveltopological links, provide the necessary information to allow the NMS to compute and set up end-to-endconnections. The NMS computes the end-to-end connection path, which may cross multiple EMS domains,and sets up the connection. If the EMS supports path computation, the NMS may delegate this task,allowing the EMS to compute and set up the connection within its sub-network. If the sub-network itselfsupports control planes, then the EMS may initiate a call request (i.e., SPC).

Figure 4: End-to-End Connection Created via the MTNM Interface

End-to-End Connection



EML

NEL

MTNMInterface

NML

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

SNCa

Top-Level

Topological

Links

Top-Level

Topological

LinksSNCb

Sub-Network C

Sub-Network B

Sub-Network A

SNCa Create Cross-connects

Create

Cross-

Connects

Create

Cross-

Connects

Call

Request

SNCb Set-up

SNCc Call Request

SNCc

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

EMS A

EMS C

CORBA


FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

EMS B


5


Figure 4 shows an example of an end-to-end connection established via the MTNM interface. Assumingthat EMS A is not capable of path computation, EMS B supports path computation, and EMS C is capable ofinitiating call requests (i.e., sub-network C supports control planes), the NMS may decide to take advantageof the underlying EMS B and EMS C capabilities to compute the end-to-end connection. Therefore, the NMSpath computation crossing sub-network A, sub-network B and sub-network C may result in specifying onlythe end points of SNCb and SNCc, while providing the full path for SNCa.

In the set-up process, the NMS provisions each cross-connect of the SNCa path via EMS A, while EMS Bprovisions cross-connects of its computed path, and EMS C initiates a call request.

Note that the current specification of the MTNM interface supports SPC. However, the call request can onlybe invoked for end-to-end connections crossing multiple sub-networks managed by a single EMS.Extensions are necessary in order to support call requests crossing multiple sub-networks managed bymultiple EMSs.

Control Plane Integration Within the MTNM InterfaceThere are issues to be resolved and decisions to be made for enhancing the MTNM interface in order tosupport SC and SPC crossing multiple sub-networks managed by multiple EMSs.Details will be based on the following assumptions:

• The interface type between two adjacent nodes managed by different EMSs is a UNI or E-NNI interface.The link connections between these adjacent nodes are represented in the MTNM interface by top-leveltopological links.

• The interface type between two adjacent nodes managed by the same EMS may be a UNI, I-NNI or E-NNI interface.

• A sub-network may be composed of many sub-networks and an EMS may manage one or more sub-networks. For simplification, this section assumes that an EMS supports only one top-level sub-network,the EMS domain.

Switched ConnectionIn the switched connection scenario, the client device initiates a call request by sending a call setup requestmessage to its peer transport network element (i.e., N1 as per Figure 5). When the transport networkelement N1 receives the request, it initiates the connection request operation. Upon successfulestablishment of the end-to-end connection, the NMS receives the creation notifications of SNCs via theMTNM interface from the EMS’s domains participating in the connection route. These SNCs carry aparticular attribute, networkRouted, indicating that this SNC was created via the control plane.

From the example depicted in Figure 5, the NMS receives SNC creation notifications from EMS A, EMS B andEMS C. Upon receipt of these notifications, the NMS realizes that an end-to-end connection was establishedvia the control plane (i.e., SNC with networkRouted attribute set). At this point, the NMS correlates the endpoints of SNCa, SNCb, and SNCc in order to reconstruct the end-to-end connection route crossing the NMSmanagement domain.

6


In order to facilitate the NMS correlation task, the MTNM team decided to add a new attribute in the SNCcalled correlationId. The SNCs created by SC are expected to have the correlationId attribute assigned withthe call request attribute value call name, which is a unique name with an end-to-end scope.

The support of control planes by the MTNM interface was first discussed late in the process of the MTNMVersion 3.0 specification. Due to the limited time remaining for the completion of this version and thecomplexity involved in extending this interface to support SPC crossing multiple EMS domains, only theminimum support described in this section was reasonably possible.

Figure 5: Call Setup Request Initiated Outside NMS Management Domain



EML

NEL

MTNM Interface

NML

EMS A

EMS B

EMS C

UNI

ConnectionFLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Sub-Network

Connection

E-NNI

Connection

E-NNI

Connection

Sub-Network

Connection

UNI

Connection

Control Plane

Connections

Connection

Type

MTNM

ModelClient

Call Request

(i.e., Client EMS

Initiated Operation)

Client

Domain C I-NNI

Domain B I-NNI

Domain A I-NNI

Sub-Network

Connection

SNCa

Top-Level

Topological

Link

Top-Level

Topological

LinkSNCb

SNCc

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

CORBA


Switched Connection

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0N1

N2

N3

N4N5

N6

7


Soft Permanent Connection CallAs discussed in the previous section, the MTNM interface’s support for SPC was left for future versionsfollowing MTMN Version 3.0. There are a number of challenges that need to be resolved in order to supportSPCs crossing multiple EMS domains.

An SPC is an end-to-end connection, which is initiated by a management system and established viasignaling. In the control plane, the end-points of an SPC are identified by A-end user name (e.g., sourceTNA), Z-end user name (e.g., destination TNA), initiating signaling agent or sub-network controller (e.g., source Node Id), terminating signaling agent or sub-network controller (e.g., destination Node Id),and source and destination SNP ID (e.g., source and destination time-slots).

One approach to support SPC by the MTNM interface is to extend the semantics of the SNC object classand associated operations to allow SNC to cross multiple EMS domains. CTP objects (i.e., A-end and Z-endCTPs) identify the end-points of a SNC. The CTP object is a tuple composed of: EMS name, managedelement name, PTP name and CTP name, where:

• The EMS name identifies the EMS managing the network element• The managed element name identifies the network element for management purposes • The PTP name identifies the containment hierarchy of the equipment (e.g., rack, shelf, slot and port)• The CTP name identifies the containment of transmission layer hierarchy

Clearly, SNC A-end and Z-end CTPs must be translated by an EMS before initiating a call request. Figure 6depicts a scenario where the NMS initiates a call request (i.e., SPC). Assuming that this action reuses SNCcreation operation, EMS A is responsible for translating the A-end and Z-end CTPs into control planeattributes.

8


The translation of the A-end CTP should not pose any major challenges to EMS A, as this CTP is in the scopeof its domain. However, the translation of Z-end CTP is a problem for EMS A. Even if EMS A has thepossibility to retrieve from MEA some topology information of sub-network C in the form of control planeattributes, EMS A does not have enough information to translate it back into MTNM attribute values.

The MTNM interface provides a notation for supporting CTPs that are outside of the EMS’s domain. Thisnotation is called remoteaddress and its syntax is /remoteaddress=<ra>, where <ra> is a free-formatidentifier. This identifier must be unique across all EMSs (e.g., /remoteaddress=4539875455). In order toreuse the identifier for the control plane, the syntax of remoteaddress must be enhanced. An example ofsuch enhancement could be /remoteaddress=/nodeid=<ipaddress>/tna=<ipaddress>/label=1-2.

Sub-Network

Connection

E-NNI

Connection

E-NNI

Connection

Sub-Network

Connection

Sub-Network

Connection

SNCa

Top-Level

Topological

Link

Top-Level

Topological

LinkSNCb

SNCc

Switched Connection



EML

NEL

MTNM Interface

NML

(1) Call Request

(2)Call

Request

EMS A

EMS C

CORBA


EMS B

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Control Plane

Connections

Connection

Type

MTNM

Model

Client

Client

Domain C I-NNI

Domain B I-NNI

Domain A I-NNI

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

A

ZMEZ

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0MEA


Figure 6: NMS Initiates an SPC Request

9


Another approach to support a call request is to introduce a new object class and operations with someparameters supporting control plane attributes. In this case, the NMS can initiate a call request with [A-enduser name, initiating signaling agent name, source SNP ID] and [Z-end user name, terminating signalingagent name, source SNP ID] without requiring the EMS A to translate the end points before forwarding therequest to the initiating MEA.

Note that both approaches described assume that the MTNM interface has been enhanced to allow theNMS to retrieve control plane mapping information from the EMS.

Call/Connection SeparationIn the case of an SC, a client device initiates the call request by sending a call setup request message to thepeer transport network element, represented by N1 in Figure 7. As a result of the call request, N1 initiatesthe connection setup request. To support SPC, the call process is handled by the management system,which requests the peer transport network element N1 to establish connections in support of the call.

Sub-Network

Connection

E-NNI

Connection

E-NNI

Connection

Sub-Network

Connection

Sub-Network

Connection

SNCa1

Top-Level

Topological

Link

Top-Level

Topological

LinkSNCb1

SNCc1

Switched Connection

Control Plane

Connections

Connection

Type

MTNM

Model

EMLMTNM Interface

NML

(2) Call Request

(3)Call

Request

(1)

Service

Order

EMS A

EMS C

CORBA




EMS B

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

Client

Client

Sub-Network C

Sub-Network B

Sub-Network A

SNCa2

SNCb2

SNCc2

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

NEL

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

N6

N5N4

N3

N2

N1

Figure 7: End-to-End Virtual Concatenated Connection

10


The call and connection separation may require extensions to the MTNM interface. The second approachdescribed in the previous section introduced the call object class. This object can represent a call and theSNC represents a connection.

One of the control plane requirements is that an end-to-end connection may be a composition of multipleconnections (e.g., virtual concatenated connections). This requirement implies that the call object class hasan attribute that contains a list of SNCs. Also, this requirement implies that the call object class will supportoperations such as adding and removing a connection to allow increasing and decreasing of bandwidthallocation (e.g., LCAS).

Call/Connection Fault ManagementIn general, the control plane (and/or transport plane) should handle SC protection and restoration withlittle intervention from an NMS. Currently, in the IETF organization, the control plane is being designed toprovide efficient and timely recovery mechanisms in a distributed and automatic manner (e.g., [9, 10, 11]).Centralized information correlation via an NMS is not required in order to carry out a successful recoveryafter network faults. As a result, a stringent network restoration time (e.g., 50 ms) can be met and a singlebottleneck cannot adversely slow down the overall recovery operation.

Although an NMS does not participate in the recovery operations, the NMS can still correlate relevantprotection and restoration data for other network management tasks. For example, after the control planeestablishes a protected SC, an NMS might need to retrieve the route information of the working path andcorresponding protection path to review their fitness.

If 1+1, end-to-end path protection is supported for the SC in Figure 8, and both working and protectionpaths are explicitly routed by the control plane, the ingress node (N1) has complete information to respondto the inquiry from the EMS. By contrast, if local (e.g., segment or link) protection is utilized for the SC andthe nodes along the working paths compute the protection path for each protected segment, the ingressnode (N1) would not readily have the route information of associated protection paths.

11


Two approaches can be used to retrieve the route information of protection paths. One can have theingress node probe every node along the working path for such information. This feature may require anextension to the signaling protocol of the current control plane design. The ingress node then providesboth working and protection path information back to the EMS and NMS.

In the second approach, the ingress node relays only the working path information (e.g., node ID andlabels) back to the EMS and NMS. The corresponding EMSs along the working path in question areresponsible for retrieving the protection path information for each protected segment. To obtain accurateroute information, the NMS requires data correlation. On the control plane, an end-to-end path does nothave a global path ID that is recognizable by all nodes on the path. Instead, each node typically relies onlabel information for traffic cross-connect, switching and restoration. Thus, the NMS needs to correlate thepath with corresponding label information when dispatching the EMS to inquire about the protectionpaths. To achieve this, an extension to the MTNM interface may be needed.

EMLMTNM Interface

NML

(1) Inquiry

(2) Inquiry

EMS A

EMS C

CORBA




EMS B

FLASHWAVE

4 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0FLASHWAVE

4 0 0 0

FLASHWAVE

4 0 0 0

E-NNI

Connection

E-NNI

ConnectionClient

Client

Sub-Network C

Sub-Network B

Sub-Network A

Working Path

Protection Path

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

7 0 0 0

FLASHWAVE

4 0 0 0

NEL

Figure 8: Protection and Restoration Information Correlation

12


Data correlation is also essential in other scenarios. If traffic has been recovered following network faults,the NMS needs to know what call/connections have been interrupted and then restored. As discussedearlier, each network element typically only has local information (e.g., labels) that they can report to theEMS and NMS. Thus, the NMS needs to correlate such data with call/connection data in order to construct acomplete picture. For another example, to assess the risk of call/connection interruption, the NMS mayneed to know what calls are protected by a particular link and how much resource (e.g., bandwidth) hasbeen reserved for protection purposes. Part of such information is available on the control plane, as theymay be carried in opaque LSA extensions of OSPF (e.g., [12, 13] ) to assist route computation. To obtainnetwork status information automatically, the EMS may listen to the flooding of LSAs as a passive interface.Alternatively, the EMS may poll the network element periodically for status updates. In either case, the NMSneeds to correlate with call/connection data to assess the vulnerability of a particular call.

ConclusionThe reuse of the SNC object class and its operations to support call requests was discussed late in theprocess of the MTNM Version 3.0 specification. As the endeavor of this task seemed more complex thanexpected, the MTNM group acknowledged the fact that this enhancement needed more reflection time,and could only be done during the following version specification period.

Much work needs to be done to enhance the MTNM interface to support the management of control planecapabilities. Additional work is needed in multiple areas, including topology/neighbor discovery, servicediscovery and policy management.

Incremental support of the control plane approach seems more appropriate, as the specification of thecontrol plane features become more mature and reach the standard level. Phasing out the specification ofthe MTNM interface for supporting control plane management can then better accommodate theprogression of the control plane standardization process. And the integration of control planecall/connection support seems to be the next logical step for the MTNM interface.

13


References[1] TMF-814 Version 2.1 – “Multi-Technology Network Management Solution Set,” August 2002.[2] GMPLS ARCH – “Generalized Multi-Protocol Label Switching Architecture,”

draft-ietf-ccamp-gmpls-architecture-06.txt, April 2003.[3] G.8080/Y.1304 – “Architecture for the automatic switched optical networks (ASON),”

November 2001 and “Amendment 1,” March 2003.[4] G.7713/Y.1704 – “Distributed call and connection management (DCM)," December 2001.[5] OIF-UNI-01.0 – “User Network Interface (UNI) 1.0 Signaling Specification," October 1, 2001.[6] oif2002.353.04 – “Draft OIF Intra-Carrier E-NNI Signaling Specification (OIF E-NNI 1.0),”

November 12, 2002.[7] oif2003.041.00 – “Requirements for the Management Plane in Support of NG-OTN

Control Plane Functions.”[8] oif2003.046.00 – “NML-EML Interface Considerations for Support of Automated Neighbor Discovery,”

Dimitrios Pendarakis.[9] J. Lang and B. Rajagopalan (Eds.),“Generalized MPLS Recovery Functional Specification,”

draft-ietf-ccamp-gmpls-recovery-functional-00.txt, January 2003.[10] D. Papadimitriou and E. Mannie (Eds.),“Analysis of Generalized MPLS-based Recovery Mechanisms

(including Protection and Restoration),” draft-ietf-ccamp-gmpls-recovery-analysis-00.txt, January, 2003.[11] P. Czezowski and T. Soumiya (Eds.),“Optical Network Failure Recovery Requirements,”

draft-czezowski-optical-recovery-reqs-01.txt, February 2003.[12] K. Kompella and Y. Rekhter (Eds.),“OSPF Extensions in Support of Generalized MPLS,”

draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, December 2002.[13] X. Su and C.F Su,“An Online Distributed Protection Algorithm in WDM Networks,” in proceeding

of IEEE ICC 2000.

14


Acronym Descriptor

CORBA Common Object Request Broker Architecture

CTP Connection Termination Point

EMS Element Management System

EML Element Management Layer

E-NNI Exterior Network-to-Network Interface

G-MPLS Generalized Multiprotocol Label Switching

IETF Internet Engineering Task Force

I-NNI Interior Network-to-Network Interface

ITU International Telecommunication Union

LCAS Link Capacity Adjustment Scheme

LMP Link Manager Protocol

LSA Link Statement Advertisement

MTNM Multi-Technology Network Management

NE Network Element

NEL Network Element Layer

NML Network Management Layer

NMS Network Management System

NNI Network-to-Network Interface

OIF Optical Internetworking Forum

OSPF Open Shortest Path First

PC Permanent Connection

PTP Physical Termination Point

RSVP Resource Reservation Protocol

SC Switched Connection

SNC SubNetwork Connection

SNP Sub-Network Point

SPC Soft Permanent Connection

TE Traffic Engineering

TMF Tele-Management Forum

TNA Transport Network Address

UNI User Network Interface

© Copyright 2004 Fujitsu Network Communications Inc. All rights reserved.FUJITSU (and design)® and THE POSSIBILITIES ARE INFINITE™ are trademarks of Fujitsu Limited.All other trademarks are the property of their respective owners.

Date post:	28-Oct-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Control Plane and Management System Integration Scenarios ......This paper shows how the TMF-814...

Documents