06.02.2013 Views

Journal of Networks - Academy Publisher

Journal of Networks - Academy Publisher

Journal of Networks - Academy Publisher

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

136 JOURNAL OF NETWORKS, VOL. 5, NO. 2, FEBRUARY 2010<br />

communication overhead involved in the process.<br />

Furthermore, it becomes too difficult for a single<br />

centralized NMS to manage the entire network when this<br />

becomes very large. In contrast, decentralized methods<br />

are usually much faster and more efficient than a<br />

centralized NMS, even in small networks with only a few<br />

nodes. This is not only because distributed methods<br />

involve low communication overheads, but also because<br />

certain management functions require rapid and accurate<br />

actions to be taken in response to failed conditions. For<br />

example, if rapid rerouting is required, it is not possible<br />

to rely on a centralized management system to compute a<br />

recovery route for each failed lightpath on demand after a<br />

failure has been detected. Distributed systems would<br />

clearly not have this difficulty.<br />

Network management is performed in a hierarchical<br />

manner involving multiple management systems, which<br />

are usually implemented in a master-slave relationship<br />

between managers and associated agents. The key<br />

concept applied in this manner <strong>of</strong> implementation is that<br />

<strong>of</strong> a layering architecture, illustrated in Fig. 2a. Layering<br />

refers to the ability <strong>of</strong> a network to nest finer-granularity<br />

over coarser-granularity by hiding details and<br />

complexities in different management levels. Thus, these<br />

levels would advertise only a standardized abstraction <strong>of</strong><br />

their state information. In such a layered model, the<br />

management functions with associated information can<br />

be decomposed into several layers <strong>of</strong> abstractions. At the<br />

border between two adjacent layers, for example Layer n-<br />

1 and Layer n, the management view is presented to<br />

Layer n-1. It is presented in the form <strong>of</strong> management<br />

information that is contained within the agent at Layer n.<br />

For security and other reasons, the management view that<br />

is presented to a higher layer need not unveil all details <strong>of</strong><br />

a lower layer. An agent at an arbitrary layer is then<br />

responsible for providing the management information<br />

that is needed at the immediately higher layer. Since the<br />

principle <strong>of</strong> layering can be applied in a recursive<br />

fashion, the management view <strong>of</strong> Layer n+1 can be<br />

presented to Layer n, and so on.<br />

In such a hierarchical model, the individual<br />

components to be managed are referred to as Network<br />

Elements (NEs). For AONs, these include Optical Line<br />

Terminals (OLTs), Optical Add/Drop Multiplexers<br />

(OADM), optical amplifiers and Optical-Cross-Connects<br />

(OXCs). Each NE is managed by an Element<br />

Management System (EMS). The NE is represented by an<br />

information model that contains a variety <strong>of</strong> attributes<br />

associated with it and a set <strong>of</strong> control and measurement<br />

parameters for monitoring purposes. Typically, a NE<br />

consists <strong>of</strong> built-in agents that are responsible for<br />

performing control functions such as monitoring and<br />

reporting any performance degradation. As shown in Fig.<br />

2b, an EMS is usually connected to one or more agents<br />

and communicates with neighboring EMSs using<br />

separated control channels. Hence, the EMS has a view<br />

only <strong>of</strong> the NEs that it can manage and may not have a<br />

comprehensive view <strong>of</strong> the entire network.<br />

In this model, a lightpath is considered as a sequence<br />

<strong>of</strong> detection points. An agent therefore, may be able to<br />

© 2010 ACADEMY PUBLISHER<br />

manage one or more detection points, simultaneously. For<br />

example, an OXC node, which is composed <strong>of</strong> several<br />

active and passive optical components, can be considered<br />

as a transmission segment or a subset <strong>of</strong> several detection<br />

points that may be managed by one or more agents at the<br />

same time. Accordingly, the corresponding EMS may<br />

communicate with certain agents to examine or alter<br />

some information, without the difficulty <strong>of</strong> handling each<br />

detection point individually. It will in fact need to collect<br />

a view <strong>of</strong> performance information, which is only part <strong>of</strong><br />

the information illuminated at each detection point. In<br />

short, an agent may act as a proxy for certain EMSs<br />

hosted elsewhere which only need to contact the agent to<br />

get the information they need. In conclusion, additional<br />

management functions need to be implemented at the<br />

agent and EMS components. Special attention needs to be<br />

paid by analyzing and specifying interfaces, protocols<br />

and the control information that should be exchanged<br />

between EMS-EMS and EMS-Agent pairs. Consequently,<br />

the vulnerability analysis <strong>of</strong> specified interfaces and<br />

protocol stacks from a security perspective is an<br />

important prerequisite. To do so, it is necessary to<br />

generate a detailed picture <strong>of</strong> the state information <strong>of</strong><br />

transmission links in a manner that can be communicated<br />

to EMSs and other control entities involved in the<br />

management process. To satisfy this requirement, control<br />

information should be expanded to include additional<br />

performance measurements, which will be carried and<br />

shared among EMSs. In particular, this needs a<br />

comprehensive synthesis <strong>of</strong> optical attributes to<br />

distinguish the parameters that change frequently,<br />

requiring continuous exchanges between EMSs, from<br />

those that change infrequently and <strong>of</strong>ten depend on the<br />

configuration properties <strong>of</strong> the individual NEs.<br />

VI. CONTROL PLANE ARCHITECTURES<br />

The design <strong>of</strong> an optical network is an important and<br />

very practical issue. As stated above, a desirable<br />

architecture should feature, inter alia, flexible<br />

management, automatic lightpath protection and<br />

restoration, and the ability to compile an inventory.<br />

Moreover, network architectures should support the<br />

gradual introduction <strong>of</strong> new technologies into the network<br />

without time consuming and costly changes to embedded<br />

technologies. However, network architectures currently<br />

used may be categorized in two main models, namely the<br />

overlay model and the peer model. Although both models<br />

consist essentially <strong>of</strong> an optical core that provides<br />

wavelength services to client interfaces, which reside at<br />

the edges <strong>of</strong> the network, they are intrinsically different<br />

and <strong>of</strong>fer up two key concepts for managing traffic flows<br />

in the network.<br />

The overlay model hides the internals <strong>of</strong> the optical<br />

network and thus requires two separate, yet interoperable,<br />

control mechanisms for provisioning and managing<br />

optical services in the network. One mechanism operates<br />

within the core optical network and the other acts as<br />

interface between the core and edge components which<br />

support lightpaths that are either dynamically signaled<br />

across the core optical network or statically provisioned

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!