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. For your convenience, a list of acronyms can be found at the end of this document.
2801 Telecom Parkway, Richardson, Texas 75082-3515
Telephone: (972) 690-6000 1
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
 WAVE
FLASH 0 0
WAVE
FLASH 0 0
Client
4 0 4 0

AVE
FLASHW0 0
7 0
AVE WAVE
FLASHW0 0 FLASH 0 0
7 0
kC
etwor
AVE 4 0
FLASHW0 0

Sub-N
AVE 7 0
FLASHW0 0
7 0
WAV0E WAV0E AVE
FLASHW0 0
FLASH 0 FLASH 0
4 0 4 0 7 0
kB UNI
etwor etwor
k
Sub-N Sub-N
tion
n n e c
Client WAVE
FLASH 0 0
E-NNI Co
kA ction
etwor
4 0
etwor
k Conne
Call Sub-N Sub-N
tion
e c
st n n
Reque E-NNI Co
ction n
twork Conne n nectio
Sub-Ne h ed Co
onnection Switc
C
UNI

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

latform
ware P
T 15 00 Soft
NETSMAR

st
WAVE
FLASH 0 0
WAVE
FLASH 0 0 Client
eque 4 0 4 0

Call R AVE
FLASHW0 0
7 0
AVE WAVE
FLASHW0 0 FLASH 0 0
C
twork
AVE 7 0
FLASHW0 0 4 0
e
Sub-N
AVE 7 0
FLASHW0 0
7 0
WAVE WAVE AVE anent
FLASH 0 0 FLASH 0 0 FLASHW0 0 Perm
4 0 4 0
ection
7 0
kB
etwor etwork Conn
Sub-N Sub-N
ction
Con n e
E-NNI
Client
WAVE
FLASH 0 0
kA ction
etwor
4 0
etwor
k Conne
Sub-N Sub-N
ction
E-NNI Conne
ction ion
etwork Conne Co nnect
Sub-N wit ched
ction port S
Co n n e Trans
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 2
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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

t em
nt Sys
a geme
k Man
N etwor
ace EML
Interf
MTNM EMS C

EMS B
latform
ware P
00 Soft
EMS A NETSM
A RT 15

tform
re Pla
oftwa
1500 S
NETSM
ART
NEL
Pla tform
ftware
500 So
ART 1
NETSM AVE AVE
FLASHW0 0 FLASHW0 0
4 0 4 0

AVE
FLASHW0 0
7 0
AVE AVE
kC
etwor
FLASHW0 0 FLASHW0 0
AVE 7 0
4 0
Sub-N
FLASHW0 0
AVE 7 0
FLASHW0 0
7 0
AVE AVE AVE
FLAS0HW0 0 FLAS0HW0 0 FLASHW0 0 B
4 4 7 0
e twork
Sub-N Sub-N
etwork
Top-Lev
el ction
Conne
AVE
kA gical
FLASHW0 0
4 0 etwor Topolo
Sub-N etwork Links
Sub-N
Top-Lev
el ction
Conne
gical
Topolo
etwork Links
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 3
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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 top-
level 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 e quest
ent Sy Call R
nagem SNCc
rk Ma
Netwo Set-u
p
SNCb
ects ace
Cross
-conn Interf EML
Creat
e
MTNM EMS C
SNCa

EMS B
latform
ware P
00 Soft
EMS A NETSM
ART 15

rm
Platfo
500 So
ftware Call
NE TSMA
RT 1
Reque
st NEL
tform e
ftw are Pla Creat -
500 So
NETSM
ART 1 Cross AVE
FLASHW0 0
AVE
FLASHW0 0
ects 4 0 4 0
Conn AVE
e
Creat -
FLASHW0 0
7 0

Cross AVE AVE C

twork
FLASHW0 0 FLASHW0 0
ects e
AVE 7 0

Sub-N
FLASHW0 0 4 0
Conn AVE
FLASHW0 0
7 0

7 0
AVE AVE
FLAS0HW0 0 FLAS0HW0 0
AVE
kB
etwor
FLASHW0 0
4 4 7 0

Sub-N
vel SNCc
Top-Le
AVE
kA gical
FLASHW0 0
etwor Topolo
Sub-N
4 0
Links
vel SNCb
Top-Le
gical
Topolo
Links ection
Conn
SNCa o-End
End-t

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 4
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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 sub-
networks. 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 EMSs 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 5
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
 NML

A
CORB

stem
gem ent Sy
Mana
Ne twork
ace EML
Interf
MTNM EMS C

EMS B
latform
ware P
00 Soft
EMS A NETSM
ART 15

rm
Platfo
ftware
500 So
ART 1
NETSM
la tform NEL
ware P
T 15 00 Soft N6
SMAR
NET
Client
AVE AVE
FLASHW0 0 FLASHW0 0
4 0 4 0

N3ASHWAVE
FL 0 0
7 0 N4
AVE
N5
FLASHW0 0 AVE
AVE
FLASHW0 0
7 0 FLASHW0 0
4 0 I-NNI ne
in C ol Pla
Doma
7 0
Contr tions
AVE
FLASHW0 0
N2 7 0
c
UNI ne
AVE
FLAS0HW0 0
AVE
FLAS0HW0 0
AVE
FLASHW0 0 Con
7 0
NI ection
B I-N
4 4

in etwork
Conn ection
Doma Sub-N Conn
n n ection Type
N1
E-NNI Co
Client
AVE

I-NNI
FLASHW0 0
4 0
in A etwork Conne
ction MTNM
Doma Sub-N
e ction Mode
l
t n n
eques
o
E-NNI C
Call .,RClient EMStion) Conne
ction n SNCc
(i.e ra etwork n nectio vel
Initiate
d O pe Sub-N h ed Co Top-Le ical
ction Switc Topolok
g
Conne Lin
UNI
SNCb
ection vel
Conn Top-Le ical
g
Topolok
Lin
SNCa

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 6
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
Soft Permanent Connection Call
As discussed in the previous section, the MTNM interfaces 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 7
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
 NML

A
CORB

em
en t Syst
nagem
rk Ma
Netwo
Inte rface
uest MTNM EML
ll Req EMS C
(1) Ca

EMS B
rm
Platfo
ftware
500 So
EMS A NE TSMA
RT 1

tform
are Pla
500 Softw
NETSM
ART 1 NE L
rm Z
Platfo
ftware MEZ
NETSM
ART 1
500 So
WAVE
FLASH 0 0
WAVE
FLASH 0 0
Client
4 0 4 0

AVE
FLASHW0 0
( 2) 7 0

Call
AVE WAVE
FLASHW0 0
I-NNI
FLASH 0 0
AVE 7 0
4 0
est FLASHW0 0
in C
Requ Doma
AVE 7 0
FLASHW0 0
7 0
ne
WAVE WAVE AVE
ol Pla
FLAS0H 0 0 FLAS0H 0 0 FLASHW0 0
Contrections
I-NNI
4 4 7 0

in B Conn
Doma etwork
Sub-Nection
Conn ection
MEAWAVE Conn
E-NNI n
Client I-NNI
FLASH 0
Type
0
ctio
A 4 0
in A Conne
etwork
Doma Sub-Nection
Conn MTNMl
E-NNI n Mode
Conne
ctio on SNCc
etwork o nnecti vel
Sub-Nection hed C Top-Le ical
Switc Topolok
g
Conn
Lin
SNCb
vel
Top-Le ical
g
Topolok
Lin
SNCa

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 EMSs domain. This
notation is called remoteaddress and its syntax is /remoteaddress=<ra>, where <ra> 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=<ipaddress>/tna=<ipaddress>/label=1-2.

FUJITSU NETWORK COMMUNICATIONS INC.

2801 Telecom Parkway, Richardson, Texas 75082-3515
Telephone: (972) 690-6000 8
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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

em
n t Syst
geme
rk Mana
Netwo
e
In terfac
uest MTNM EML
ll Req EMS C
(2) Ca

EMS B
tform
are Pla
Softw
EMS A
00
A RT 15
NETSM
tform
are Pla
Softw
T 1500
NETSM
AR NEL
tform
re Pla
oftwa N6
A RT 1
500 S AVE AVE Client
(1) NETSM FLASHW0 0
4 0
FLASHW0 0
4 0
N3
e
Servic r (3)
AVE
FLASHW0 0

Orde
7 0 N4
N5
Call AVE
FLASHW0 0
AVE
FLASHW0 0
kC
etwor
AVE 7 0
est FLASHW0 0 4 0
Requ N2 AVE
FLASHW0 0
7 0
Sub-N
7 0
ne
AVE AVE AVE
ol Pla
FLAS0HW0 0 FLAS0HW0 0 FLASHW0 0
7 0
B Contrections
work
4 4
et Conn
Sub-N etwork
Sub-Nection
Conn ection
N1 AVE E-NNIon Conn
Client FLASHW0 0
kA ti Type
4 0
twor Connec
Sub-Ne etwork
Sub-Nection
Conn MTNMl
E-NNIon SNCc1 Mode
ti
Connec tion
etwork onnec el
Top-Levical SNCc2
Sub-Nection hed C
Switc Topolok
g
Conn
SNCb1 Lin
el SNCb2
Top-Levical
g
Topolok
SNCa1 Lin
SNCa2

Figure 7: End-to-End Virtual Concatenated Connection

FUJITSU NETWORK COMMUNICATIONS INC.

2801 Telecom Parkway, Richardson, Texas 75082-3515
Telephone: (972) 690-6000 9
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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 10
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
 NML

A
CORB

m
Syste
nage ment
rk Ma
Netwo
Inte rface
quiry MTNM EML
(1) In EMS C

EMS B
Platform
ftware
500 So
EMS A NETSM
ART 1

tform
re Pla
oftwa
1500 S
NETSM
ART NEL
rm
Platfo
ftware
ART 1
500 So AVE AVE Client
NETSM FLASHW0 0
4 0
FLASHW0 0
4 0

AVE
FLASHW0 0
7 0

uiry
AVE AVE
FLASHW0 0 FLASHW0 0
(2) Inq AVE
FLASHW0 0
7 0
4 0
e twork
C
Sub-N
AVE 7 0
FLASHW0 0
7 0
AVE AVE AVE
FLAS0HW0 0 FLAS0HW0 0 FLASHW0 0
th
4 4
kB 7 0
ing Pa th
etwor Work a
Sub-N ct io n P
E-NNI n
Prote
AVE
Client FLASHW0 0
kA Conne
ctio
etwor
4 0

Sub-N
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 11
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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 12
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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 13
(800) 777-FAST (U.S.)
us.fujitsu.com/telecom
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.

FUJITSU NETWORK COMMUNICATIONS INC.

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