Control Plane and Management System Integration Scenarios

Introduction Different standards organizations such as the IETF, ITU-T and OIF are working towards standardization of the 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 element and provide topology discovery and accurate inventory, both of which are necessary for reliable path computation and connection management. Standardization, followed by control plane interoperability, should ultimately allow setting up and tearing down end-to-end connections within a multi-vendor network environment with minimum intervention by management systems. On the other hand, work on the specification of an interoperable interface (TMF-814) between NMS and EMS by organizations, such as the TMF, will ultimately allow an NMS to manage a multi-vendor network through respective vendors’ EMS products. This interface currently supports connection management, fault management, performance management, inventory and other functions. The connection management interface uses the divide-and-conquer approach where the NMS can break end-to-end connections within a multi-vendor network environment into multiple sub-connections delimited by different EMS-controlled sub-networks. The EMS is responsible for computing the path and setting up the end-to-end sub-connection within the sub-network. This paper shows how the TMF-814 (MTNM interface) may be upgraded to support control plane enabled networks so that management systems can set up and tear down end-to-end connections across hybrid networks (i.e., a mix of control plane enabled networks and legacy networks). Control Plane Call/Connection The control plane supports two types of connections: SC and SPC. PC, a third type, was defined to represent connections 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 control plane establishes the connection (connection request) via signaling (see Figure 1).

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

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

1

Client

WAVE FLASH 0 0 4 0

WAVE FLASH 0 0 4 0 AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

WAV0E FLASH 0 4 0

WAV0E FLASH 0 4 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

kB

etwor

WAVE FLASH 0 0 4 0

kA etwor twork Sub-Ne ction e n n o C

UNI

E-NNI ction Conne

h Switc

k etwor Sub-N tion c e n n Co

E-NNI ction Conne

k etwor Sub-N tion c e n n Co

Sub-N

Call st Reque

kC

etwor

Sub-N

Sub-N Client

WAVE FLASH 0 0 4 0

UNI

n nectio

n ed Co

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

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

00 Soft

T 15 SMAR

tform

la ware P

NET

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

WAVE FLASH 0 0 4 0

WAVE FLASH 0 0 4 0

WAVE FLASH 0 0 4 0

kA etwor Sub-N etwork Sub-N ction e n n Co

AVE FLASHW0 0 7 0

WAVE FLASH 0 0 4 0

twork

e Sub-N

C

AVE FLASHW0 0 7 0

Sub-N Client

Client

WAVE FLASH 0 0 4 0

WAVE FLASH 0 0 4 0

st

eque Call R

E-NNI ction Conne

kB etwor E-NNI ction Conne

k etwor Sub-N ction Conne

anent Perm ection Conn

ion

nnect

Co ched

wit port S Trans

etwork Sub-N ction e n Con

anent Perm ection Conn

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

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

2

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 path computation of SPC and SC. Only limited topology information is exchanged over the E-NNI, while full topology information is exchanged in the sub-networks over the I-NNI interface (not shown in the figures). MTNM CORBA Interface Architecture The MTNM interface provides a CORBA-based interface between two management systems (e.g., between an NMS and an EMS). This interface provides a level of abstraction to an NMS of the network to be managed by supporting a common set of objects and operations. The main functions supported by this interface are topology and inventory discovery, fault management, performance management and connection management.

NML A

CORB

em

t nt Sys geme

a k Man etwor

N

MTNM

ace

Interf

EML

EMS C

EMS B EMS A ART NETSM

oftwa

1500 S

latform

ware P

00 Soft

RT 15

A NETSM tform

re Pla

NEL

tform

Pla ftware 500 So

ART 1

NETSM

AVE FLASHW0 0 4 0

AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLAS0HW0 0 4

AVE FLAS0HW0 0 4

AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

twork

e Sub-N etwor

Sub-N

AVE FLASHW0 0 4 0

etwork Sub-N ction Conne

kC

B

kA el Top-Lev gical Topolo Links

etwor

Sub-N

etwork Sub-N ction Conne

el Top-Lev gical Topolo Links

etwork Sub-N ction Conne

Figure 3: Distributed Network Management System using MTNM interface

In a distributed network management system using the MTNM interface (see Figure 3), the NMS has an abstract view of the entire network, where the EMS plays the role of middleman, providing the NMS an abstract segment of this network (i.e., the sub-network). FUJITSU NETWORK COMMUNICATIONS INC. 2801 Telecom Parkway, Richardson, Texas 75082-3515 Telephone: (972) 690-6000 (800) 777-FAST (U.S.) us.fujitsu.com/telecom

3

In the MTNM architecture, sub-networks are interconnected by topological links. If these interconnected sub-networks are managed by different EMSs, then these interconnections are represented by top-level topological links. In this interface, an EMS has no knowledge of other EMSs participating in the management of the network. As a consequence, an EMS can only report single-ended top-level topological links. The NMS is responsible for interconnecting these sub-networks by manually associating these toplevel topological links. The topology and inventory retrieved from the underlying sub-networks, combined with the top-level topological links, provide the necessary information to allow the NMS to compute and set up end-to-end connections. 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 itself supports control planes, then the EMS may initiate a call request (i.e., SPC).

NML A

CORB

stem ent Sy

nagem rk Ma

Netwo

SNCb

ects

e Creat SNCa

-conn Cross

SNCc

p Set-u

ace

Interf

MTNM

quest

e Call R

EML

EMS C

EMS B EMS A ftware

500 So

NE ftw

500 So

ART 1

NETSM

tform are Pla

e Creat Cross ects Conn

RT 1 TSMA

e Creat Cross ects Conn

rm

Platfo

Sub-N

NEL

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 4 0

vel Top-Le gical Topolo Links

SNCb

o-End

End-t

C

kB etwor

kA etwor vel Top-Le gical Topolo Links

twork

e Sub-N

Sub-N

SNCa

AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

AVE FLAS0HW0 0 4

AVE FLASHW0 0 4 0

Call st Reque AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

AVE FLAS0HW0 0 4

latform

ware P

00 Soft

RT 15

A NETSM

SNCc

ection

Conn

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

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

4

Figure 4 shows an example of an end-to-end connection established via the MTNM interface. Assuming that EMS A is not capable of path computation, EMS B supports path computation, and EMS C is capable of initiating call requests (i.e., sub-network C supports control planes), the NMS may decide to take advantage of the underlying EMS B and EMS C capabilities to compute the end-to-end connection. Therefore, the NMS path computation crossing sub-network A, sub-network B and sub-network C may result in specifying only the 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 B provisions 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 only be 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 by multiple EMSs. Control Plane Integration Within the MTNM Interface There are issues to be resolved and decisions to be made for enhancing the MTNM interface in order to support 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-level topological 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 subnetworks. For simplification, this section assumes that an EMS supports only one top-level sub-network, the EMS domain. Switched Connection In the switched connection scenario, the client device initiates a call request by sending a call setup request message to its peer transport network element (i.e., N1 as per Figure 5). When the transport network element N1 receives the request, it initiates the connection request operation. Upon successful establishment of the end-to-end connection, the NMS receives the creation notifications of SNCs via the MTNM interface from the EMS’s domains participating in the connection route. These SNCs carry a particular 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 and EMS C. Upon receipt of these notifications, the NMS realizes that an end-to-end connection was established via the control plane (i.e., SNC with networkRouted attribute set). At this point, the NMS correlates the end points of SNCa, SNCb, and SNCc in order to reconstruct the end-to-end connection route crossing the NMS management domain.

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

5

NML A

CORB

stem ent Sy

gem Mana twork

Ne

ace

Interf

MTNM

EML

EMS C

EMS B EMS A ftware

500 So

ART 1

NETSM

latform

ware P

00 Soft

RT 15

A NETSM rm

Platfo

NEL

tform

la ware P

00 Soft

T 15 SMAR

N6

NET

N3ASHWAVE FL 7 0

0

N4

AVE FLAS0HW0 0 4

N1

AVE FLASHW0 0 4 0

in Doma

t eques Call .,RClient EMStion) (i.e ra d O pe Initiate

UNI ection

in C

I-NNI

AVE FLASHW0 0 7 0

I-NNI

A

AVE FLASHW0 0 4 0

Doma

in Doma Client

N5

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

N2 AVE FLAS0HW0 0 4

0

Client

AVE FLASHW0 0 4 0

AVE FLASHW0 0 4 0

etwork Sub-N ction Conne

Conn

SNCa

E-NNI ction Conne

NI B I-N etwork Sub-N ction e n n o C

h Switc vel Top-Le ical g Topolok Lin

n nectio

n ed Co SNCb

E-NNI ction Conne

vel Top-Le ical g Topolok Lin

etwork Sub-N ction e n n Co

UNI ection Conn

ne ol Pla Contr tions c e n Con ection Conn Type MTNM l Mode

SNCc

Figure 5: Call Setup Request Initiated Outside NMS Management Domain

In order to facilitate the NMS correlation task, the MTNM team decided to add a new attribute in the SNC called correlationId. The SNCs created by SC are expected to have the correlationId attribute assigned with the 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 MTNM Version 3.0 specification. Due to the limited time remaining for the completion of this version and the complexity involved in extending this interface to support SPC crossing multiple EMS domains, only the minimum support described in this section was reasonably possible.

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

6

Soft Permanent Connection Call As discussed in the previous section, the MTNM interface’s support for SPC was left for future versions following MTMN Version 3.0. There are a number of challenges that need to be resolved in order to support SPCs crossing multiple EMS domains. An SPC is an end-to-end connection, which is initiated by a management system and established via signaling. In the control plane, the end-points of an SPC are identified by A-end user name (e.g., source TNA), 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 class and associated operations to allow SNC to cross multiple EMS domains. CTP objects (i.e., A-end and Z-end CTPs) identify the end-points of a SNC. The CTP object is a tuple composed of: EMS name, managed element 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 6 depicts a scenario where the NMS initiates a call request (i.e., SPC). Assuming that this action reuses SNC creation operation, EMS A is responsible for translating the A-end and Z-end CTPs into control plane attributes.

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

7

NML A

CORB

em

t Syst

en nagem rk Ma

Netwo

rface

Inte MTNM

uest ll Req (1) Ca

EML

EMS C

EMS B 500 So

EMS A

NE 500

ART 1

NETSM ftware 500 So

are Pla Softw

RT 1 TSMA

tform

MEZ

Client

WAVE FLASH 0 0 4 0

WAVE FLASH 0 0 4 0 AVE FLASHW0 0 7 0

( 2) Call est Requ

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

WAVE FLAS0H 0 0 4

Client

NE L

Z

rm Platfo

ART 1

NETSM

rm Platfo ftware

WAVE FLAS0H 0 0 4

MEAWAVE

A

FLASH 0 4 0

0

in A Doma

AVE FLASHW0 0 7 0

WAVE FLASH 0 0 4 0

in C Doma

I-NNI

AVE FLASHW0 0 7 0

I-NNI in B Doma

I-NNI

etwork Sub-Nection Conn

SNCa

E-NNI n ctio Conne

vel Top-Le ical g Topolok Lin

E-NNI n ctio Conne

etwork Sub-Nection Conn on

nnecti

o hed C Switc

SNCb

vel Top-Le ical g Topolok Lin

etwork Sub-Nection Conn

SNCc

ne ol Pla Contrections Conn on

ecti Conn Type MTNMl Mode

Figure 6: NMS Initiates an SPC Request

The translation of the A-end CTP should not pose any major challenges to EMS A, as this CTP is in the scope of its domain. However, the translation of Z-end CTP is a problem for EMS A. Even if EMS A has the possibility to retrieve from MEA some topology information of sub-network C in the form of control plane attributes, 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. This notation is called remoteaddress and its syntax is /remoteaddress=, where is a free-format identifier. This identifier must be unique across all EMSs (e.g., /remoteaddress=4539875455). In order to reuse the identifier for the control plane, the syntax of remoteaddress must be enhanced. An example of such enhancement could be /remoteaddress=/nodeid=/tna=/label=1-2.

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

8

Another approach to support a call request is to introduce a new object class and operations with some parameters supporting control plane attributes. In this case, the NMS can initiate a call request with [A-end user name, initiating signaling agent name, source SNP ID] and [Z-end user name, terminating signaling agent name, source SNP ID] without requiring the EMS A to translate the end points before forwarding the request to the initiating MEA. Note that both approaches described assume that the MTNM interface has been enhanced to allow the NMS to retrieve control plane mapping information from the EMS. Call/Connection Separation In the case of an SC, a client device initiates the call request by sending a call setup request message to the peer transport network element, represented by N1 in Figure 7. As a result of the call request, N1 initiates the 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.

NML A CORB

rk Netwo

Mana

em

t Syst

n geme

e

terfac

In MTNM

uest ll Req (2) Ca

EML

EMS C

EMS B EMS A

A NETSM

AR NETSM

(1) e Servic r Orde

NETSM

A RT 1

T 1500

00 RT 15

tform are Pla

Softw

tform are Pla

Softw

NEL

tform re Pla oftwa

N6

500 S

N3 AVE FLASHW0 0 7 0

(3) Call est Requ

AVE FLASHW0 0 7 0

N2 AVE FLAS0HW0 0 4

AVE FLAS0HW0 0 4

N4

N5

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

work

B

N1

AVE FLASHW0 0 4 0

Client

kA

twor ub-Ne

S

etwork Sub-Nection Conn

SNCa1

E-NNIon ti Connec

el Top-Levical g Topolok n Li

kC

etwor

Sub-N

et Sub-N

Client

AVE FLASHW0 0 4 0

AVE FLASHW0 0 4 0

etwork Sub-Nection Conn tion onnec

hed C Switc SNCb1

E-NNIon ti Connec

etwork Sub-Nection Conn

SNCc1 el Top-Levical g Topolok Lin

ne ol Pla Contrections Conn on

ecti Conn Type MTNMl Mode

SNCc2

SNCb2

SNCa2

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

9

The call and connection separation may require extensions to the MTNM interface. The second approach described in the previous section introduced the call object class. This object can represent a call and the SNC represents a connection. One of the control plane requirements is that an end-to-end connection may be a composition of multiple connections (e.g., virtual concatenated connections). This requirement implies that the call object class has an attribute that contains a list of SNCs. Also, this requirement implies that the call object class will support operations such as adding and removing a connection to allow increasing and decreasing of bandwidth allocation (e.g., LCAS). Call/Connection Fault Management In general, the control plane (and/or transport plane) should handle SC protection and restoration with little intervention from an NMS. Currently, in the IETF organization, the control plane is being designed to provide 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 recovery after network faults. As a result, a stringent network restoration time (e.g., 50 ms) can be met and a single bottleneck cannot adversely slow down the overall recovery operation. Although an NMS does not participate in the recovery operations, the NMS can still correlate relevant protection and restoration data for other network management tasks. For example, after the control plane establishes a protected SC, an NMS might need to retrieve the route information of the working path and corresponding 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 protection paths are explicitly routed by the control plane, the ingress node (N1) has complete information to respond to the inquiry from the EMS. By contrast, if local (e.g., segment or link) protection is utilized for the SC and the nodes along the working paths compute the protection path for each protected segment, the ingress node (N1) would not readily have the route information of associated protection paths.

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

10

NML A CORB ment

nage rk Ma Netwo (1) In

m

Syste

rface

Inte MTNM

quiry

EML

EMS C

EMS B 500 So ART 1 NETSM

EMS A

latform

P ftware

tform

ART NETSM ART 1

NETSM

500 So

ftware

re Pla oftwa

1500 S

NEL

rm Platfo

Client

AVE FLASHW0 0 4 0

AVE FLASHW0 0 4 0 AVE FLASHW0 0 7 0

uiry

(2) Inq

AVE FLAS0HW0 0 4

Client

AVE FLAS0HW0 0 4

AVE FLASHW0 0 4 0

etwor Sub-N

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 7 0

AVE FLASHW0 0 4 0

AVE FLASHW0 0 7 0

kB etwor Sub-N

kA

twork

e Sub-N

E-NNI n ctio Conne

C th ing Pa th Work a P n io ct Prote

E-NNI n ctio Conne

Figure 8: Protection and Restoration Information Correlation

Two approaches can be used to retrieve the route information of protection paths. One can have the ingress node probe every node along the working path for such information. This feature may require an extension to the signaling protocol of the current control plane design. The ingress node then provides both 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 and labels) back to the EMS and NMS. The corresponding EMSs along the working path in question are responsible for retrieving the protection path information for each protected segment. To obtain accurate route information, the NMS requires data correlation. On the control plane, an end-to-end path does not have a global path ID that is recognizable by all nodes on the path. Instead, each node typically relies on label information for traffic cross-connect, switching and restoration. Thus, the NMS needs to correlate the path with corresponding label information when dispatching the EMS to inquire about the protection paths. To achieve this, an extension to the MTNM interface may be needed.

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

11

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 discussed earlier, each network element typically only has local information (e.g., labels) that they can report to the EMS and NMS. Thus, the NMS needs to correlate such data with call/connection data in order to construct a complete picture. For another example, to assess the risk of call/connection interruption, the NMS may need to know what calls are protected by a particular link and how much resource (e.g., bandwidth) has been reserved for protection purposes. Part of such information is available on the control plane, as they may be carried in opaque LSA extensions of OSPF (e.g., [12, 13] ) to assist route computation. To obtain network 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 NMS needs to correlate with call/connection data to assess the vulnerability of a particular call. Conclusion The reuse of the SNC object class and its operations to support call requests was discussed late in the process of the MTNM Version 3.0 specification. As the endeavor of this task seemed more complex than expected, 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 plane capabilities. Additional work is needed in multiple areas, including topology/neighbor discovery, service discovery and policy management. Incremental support of the control plane approach seems more appropriate, as the specification of the control plane features become more mature and reach the standard level. Phasing out the specification of the MTNM interface for supporting control plane management can then better accommodate the progression of the control plane standardization process. And the integration of control plane call/connection support seems to be the next logical step for the MTNM interface.

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

12

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.

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

13

Acronym CORBA CTP EMS EML E-NNI G-MPLS IETF I-NNI ITU LCAS LMP LSA MTNM NE NEL NML NMS NNI OIF OSPF PC PTP RSVP SC SNC SNP SPC TE TMF TNA UNI

Descriptor Common Object Request Broker Architecture Connection Termination Point Element Management System Element Management Layer Exterior Network-to-Network Interface Generalized Multiprotocol Label Switching Internet Engineering Task Force Interior Network-to-Network Interface International Telecommunication Union Link Capacity Adjustment Scheme Link Manager Protocol Link Statement Advertisement Multi-Technology Network Management Network Element Network Element Layer Network Management Layer Network Management System Network-to-Network Interface Optical Internetworking Forum Open Shortest Path First Permanent Connection Physical Termination Point Resource Reservation Protocol Switched Connection SubNetwork Connection Sub-Network Point Soft Permanent Connection Traffic Engineering Tele-Management Forum Transport Network Address 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.

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

14