* type: pu-public, pp-limited, re-restricted, co-internal ... filedeliverable (d4.1) - description...

Deliverable (D4.1) - Description of experiments scenarios

WINMAN-WP4-OTE-028i-D4-1-b1 WINMAN Consortium

Project Number: IST-1999-13305

Project Title: WDM and IP Network MANagement (WINMAN)

Deliverable Type: (PU/PP/RE/CO)* PU

Deliverable Number: D4.1

Contractual Date of Delivery to the CEC: 30 March 2001

Actual Date of Delivery to the CEC: 2 April 2001

Title of Deliverable: Description of experiments scenarios

Workpackage contributing to the Deliverable: WP4

Nature of the Deliverable: (P/R/D/O)** R

Editor Organisation: Hellenic Telecomms Organisation (OTE)

Author(s): Harris Katopodis, , ed., OTE Dimitris I. Chronis, ed., OTE All Partners Abstract:

Deliverable D4.1 deliverable defines a set of high-level experiments scenarios to exhibit and validate the non-functional and functional attributes of the WINMAN system, with respect to the objectives and the target requirements of the project. The defined experiments scenarios related to non-functional attributes are dealing with portability, openness, scalability, flexibility, modularity and robustness of the WINMAN system architecture and implementation. The defined experiments scenarios validating WINMAN functional attributes lie in the areas of Configuration, Fault and Performance management, and are further decomposed according to the Tele-Management Forum TOM processes areas: Network Provisioning and Network Inventory Configuration Management), Network Maintenance and Restoration (Fault Management) and Network Data Management (Performance Management). Certain of experiments defined in this deliverable are suitable to demonstrate the WINMAN functionality and in general its capabilities to the public. Keyword list: Inter-domain Network Management, IP over WDM, IP, WDM, MPLS, experiments, WINMAN, test-bed, QoS, IP Connectivity Service, robustness, portability, scalability

* Type: PU-public, PP-limited, RE-restricted, CO-internal ** Nature: P-Prototype, R-Report, D-Demonstrator, O-Other



Executive Summary The network management solution developed in the WINMAN project will be subjected to a series of experiments in a 'real' communications environment. By means of these experiments the project will verify and evaluate to what extend the WINMAN solution meets the requirements defined in the project and the expectations expressed in the Technical Annex. Certain experiments are suitable to demonstrate the WINMAN capabilities to the public. The above-mentioned 'real' communications environment will be realised through the set-up of testbeds at the sites of several partners in the consortium. The experiments are grouped into two main categories, showing non-functional and functional characteristics. 1. WINMAN non-functional attributes

The WINMAN solution is based on an architectural design, which exhibits the following attributes: • Openness, i.e. with published APIs to the relevant actors, giving third parties the possibility to

implement their own Service Management application. • Flexibility, i.e. being able to evolve to and accommodate new systems • Modularity, i.e. giving the capability to add or remove management blocks in a plug-and-play fashion

without requiring major changes in existing components. • Scalability, i.e. it should be able to cope with network evolution scenarios towards IP over WDM and

growth of the network in terms of number of network elements and type of network elements. • Portability, i.e. capable of being installed in different environments (operating systems, platforms etc.) • Robustness, i.e. capable of passing stress tests under increased process load, showing adequate

performance. This set of experiments will prove whether the developed solution will show these features when the system is operational. It is important to mention that the above non-functional attributes are linked to one-another, so that the corresponding scenarios are also dependent to each other.

2. WINMAN functionality These experiments, which are defined by a set of high-level scenarios, exhibit the basic configuration, fault and performance management functionality. Such scenarios are capable of demonstrating the main achievements of the project to an external audience. Detailed test cases on stand-alone components, the WINMAN subsystems and finally the integrated system without a real environment or with a simulated network will take place during the implementation. The high-level scenarios will exhibit the main objectives of the project in an in-field integrated system. In this way, the external audience can verify that the functional attributes specified in the objectives of the project are really met. The main scope is to exhibit the inter-technology functionality of WINMAN, but single domain functionality dealing with IP only or WDM only, will also be accommodated. This will be useful for the WINMAN operator, giving her/him the opportunity to realise useful or necessary functionality, but also allowing project partners having only one technology domain, to exhibit the capabilities of the systems to the public. Note, that WINMAN develops not only the Inter-technology NMS (INMS), but also an IP NMS and a WDM NMS. Moreover, the basis of the internal architecture that serves the above systems is technology-independent, resulting in the same internal components for the 3 systems. In other words, we will consider experiments dealing with the two technology domains separately (IP and WDM), and then dealing with the integration of the two technology-domains (IP over WDM). The experiment scenarios identified exhibiting and validating WINMAN functionality are distinguished in the following categories, based on the Tele-Management Forum TOM approach: • Configuration Management dealing with

o Network Provisioning and o Network Inventory Management

• Fault Management o Network Maintenance and Restoration

• Performance Management o Network Data Management

Additionally, an overview of the partners’ test-beds and the overall network-architecture context in which WINMAN operates, offering integrated management of IP over WDM networks, are presented.



Table of Contents

Executive Summary

1. Introduction ................................................................................................................................................. 4

1.1. WINMAN main objectives.................................................................................................................... 4 1.2. Deliverable’s Roadmap ......................................................................................................................... 5 1.3. Template ................................................................................................................................................ 6

2. Experiments validating WINMAN Non-Functional Attributes .............................................................. 8

2.1. The definition of the attributes .............................................................................................................. 8 2.2. Openness and Portability ....................................................................................................................... 9 2.3. Flexibility and Modularity................................................................................................................... 10 2.4. Scalability ............................................................................................................................................ 12 2.5. Robustness........................................................................................................................................... 13

3. Experiments validating the WINMAN Functional Attributes .............................................................. 15

3.1. Configuration Management ................................................................................................................. 16 3.1.1. Network Provisioning.................................................................................................................. 16

3.1.1.1 Create optical path ................................................................................................................... 16 3.1.1.2 Create IP/MPLS path............................................................................................................... 17 3.1.1.3 ICS provisioning...................................................................................................................... 19

3.1.2. Network Inventory Management ................................................................................................. 20 3.1.2.1 Network inventory consistency to network infrastructure ....................................................... 20

3.2. Fault Management ............................................................................................................................... 22 3.2.1. Network Maintenance & Restoration .......................................................................................... 22

3.2.1.1 ICS maintenance and restoration ............................................................................................. 22 3.3. Performance Management ................................................................................................................... 24

3.3.1. Network Data Management......................................................................................................... 24 3.3.1.1 ICS assurance .......................................................................................................................... 24

4. Conclusions ................................................................................................................................................ 27

Abbreviations..................................................................................................................................................... 28

Appendix A. WINMAN test-bed infrastructure........................................................................................ 29

Appendix B. Underlying Network Architecture ....................................................................................... 38

Deliverable (D4.1) - Description of experiments scenarios of 41


1. Introduction The objective of this deliverable is to specify a set of high-level experiments scenarios to exhibit the WINMAN functional and non-functional attributes, in respect to the project objectives and the target requirements identified in the initial stages (WP2) of the project. The main objective of the WINMAN solution is to provide an integrated network management system, which is capable of providing managed end-to-end IP connectivity services derived from Service Level Agreements (SLAs). In other words, WINMAN will design, implement and test in-field a Network Management System, capable of performing integrated provisioning of IP/MPLS Label Switched Paths over optical paths, as well as integrated multi-layer fault and performance management. The purpose of the document is to exhibit and validate the basic WINMAN non-functional and functional attributes. A set of high-level scenarios is identified, capable of demonstrating the main achievements of the project to an external audience, being the main functional and non-functional characteristics of the system. This document is structured in the following way. In the introduction a brief summary of WINMAN main scope and objectives is given, followed by the deliverables future roadmap and the template adopted for the experiment scenarios. Chapter 2 identifies experiment scenarios exhibiting non-functional attributes as these are defined in the beginning. The attributes under consideration are Openness, Flexibility, Modularity, Scalability, Portability and Robustness. Chapter 3 proposes experiment scenarios showing WINMAN functionality. WINMAN functional attributes lie in the areas of Configuration, Fault and Performance management, and are further decomposed according to the Tele-Management Forum TOM processes areas as follows:

• Network Provisioning and Network Inventory for Configuration Management • Network Maintenance and Restoration for Fault Management and • Network Data Management for Performance Management

Chapter 4 summarises the work of this document, while some additional information useful for an external reader are placed with the form of an appendix. Appendix A, describes the WINMAN partners test-beds, namely Lucent’s, OTE’s, PTI’s, UCL’s and UPC’s ones. Appendix B, clarifies the overall network-architecture context in which WINMAN operates, offering integrated management of IP over WDM networks.

1.1. WINMAN main objectives The WINMAN project adopts an innovative approach of integrating IP and WDM networks. Instead of extending the distributed Internet network control approach to the Optical Layer using signalling, WINMAN proposes an alternative approach by employing the telecom-style network management in both the WDM and IP layer in an integrated way. The feasibility of the approach is guaranteed by the deployment of the MPLS Internet packet switching protocol, which resembles a connection-oriented network. The overall WINMAN aim is to offer an integrated network management solution, the WINMAN solution, which is capable to provide end-to-end IP connectivity services derived from Service Level Agreements (SLAs). WINMAN will capture the requirements, define and specify an open, distributed, and scalable management architecture for IP connectivity services on hybrid transport networks (ATM, SDH and WDM). The requirements will include and the architecture will support multi-vendor, multi-technology environments and evolution scenarios for end-to-end IP transport from IP / ATM / SDH / WDM towards IP/WDM. WINMAN will consist of optimised architecture and systems for integrated network management of IP connectivity services over hybrid transport networks. From implementation point of view, the project will address the separate management of IP and WDM networks. Per technology domain the integration of the management at Network Management level will be developed. An Inter-technology domain Network Management System (INMS) as a sub-layer of the Network Management Layer will be implemented to support IP-connectivity spanning different WDM sub-networks and to integrate the management of IP and WDM transport networks. The INMS and the IP and WDM Network Management Systems will implement Configuration, Fault and Performance (CFP) Management application functions. Development will be carried out in two phases in the project resulting in release R0 and R1.



WINMAN will set up an infrastructure including several sites and experiment scenarios to demonstrate and validate the system. Results will be disseminated and exploited. The telecom operators will provide the necessary input for the requirements. The areas to be examined include physical topology resource allocation (network planning), path provisioning functionality (automatically monitoring and optimally fitting the IP/MPLS traffic needs), IP/MPLS and WDM optimum routing inter-working (involving wavelength translation and optical cross-connections), path tracing, and capacity management in both the physical and logical domains, fault management and restoration mechanisms including alarm correlation between optical and client layers, alarm localisation and multi-layer survivability, performance management including relation of optical layer performance and the client layer performance, traffic monitoring, and identification of the end-to-end QoS requirements. Along the road from requirements capture down to the demonstration of the project results, the following milestones are distinguished: Requirements and high-level overall architecture, the system specifications and designs, implemented and tested systems integrated in the experimentation sites, and the solutions validated in a real-world environment. This sequence applies to both releases. Note that the term domain in this project, does not refer to administrative domains, but to technology domains, like IP and WDM.

IP ATM SDH WDM

IPNMS ATM

NMSSDHNMS

WDMNMS

SERVICE LEVEL

Integrated Level

TechnologyDependent Level

NETWORK LEVEL

NETWORK-ELEMENTLEVEL

Network

Operator GUI

THIRD PARTIES API

INTER-TECHNOLOGY NMS

CMFM

PM

Systems willnot be

implemented

WWW

Figure 1: Overview of components to be specified and implemented by WINMAN

1.2. Deliverable’s Roadmap The experiments scenarios are defined in an early stage of the project in order to focus on the desired outcome, which is to demonstrate the basic objectives of the project, as these were captured in the form of functional and non-functional requirements in the initial stages (WP2) of the project. However, defining experiments in such an early stage may result in their obsolescence at the time of execution due to the fact that the experiment is not relevant, feasible or anymore reasonable. The descriptions of the experiments contain a priority field, which



will be filled in at the time the execution of the experiments starts. Moreover, at that time the selection of test-bed locations among partners along with corresponding experiments is foreseen to be determined. The execution of experiments has to be performed in T4.7, and before then all the above pending issues in this deliverable should have been settled. It is possible that this document is enriched with new experiments showing enhanced WINMAN functionality that might be the outcome of innovative technological evolutions. In this sense, this document should be updated before starting the experiments.

1.3. Template All experiment descriptions are based on the following template:

Priority Not all experiments may have the same priority for execution at the time when the execution of the experiments starts. The priority will be assessed at the time the experiments will be executed. The following criteria are applied to determine the priority of an experiment: • The relevance for the project

Certain requirements may not be so relevant anymore due to changes advances in protocols/technologies. The relevance also depends on the purpose of the experiment: evaluation of the system, demonstrator, or public showcase.

• The feasibility of the experiment Experiments may not be feasible due to lack of equipment, software, other network infrastructure or means.

• The costs of the experiment The costs of an experiment may be in terms of cost, effort and/or time. If costs will become too high then the experiment will get a lower priority.

The priority values are: • High

The experiment shall be executed • Medium

It is desirable that the experiment is executed • Low

The experiment will be executed if spare resources are available

Objectives Describes the aim of the experiment. The description must indicate • The aspect of the system under evaluation; references to e.g. requirements, standards • The significance of the experiment • The reasoning behind it • The scope and boundaries

Background Provides information related to the aspect of the system that will be evaluated, e.g., theoretical background, references to standards, business model, etc.

Required tools • Equipment

Hardware platform for the WINMAN management systems, test-bed equipment, test equipment (e.g. traffic generators, analysers), end-user equipment/applications

• Emulators Certain parts of the network may be emulated

• Software Auxiliary software tools, third party applications, etc.



Required infrastructure Description of the test-bed network infrastructure, the network management infrastructure, the interconnectivity between the test-beds and the management systems (DCN), connectivity to the end-users, etc.

Expected outcome Describes what will be the expected results from the experiments. The expectation may be based on certain standards, requirements, performance of a service, etc.

Experiment Set up Describes the set up of the experiment, which may include: • The network infrastructure and configuration • The end-user applications • The WINMAN system configuration • The test equipment connected to the WINMAN system and/or the network • Points of measurements • Pre-provisioning of the WINMAN system and the managed network • Loading of the WINMAN system and the managed network

Experiment Scenario Describes the steps to be executed, the pre-conditions and the post-conditions

Related Experiments Provides references to related experiments.

Additional WINMAN system requirements Some experiments may need auxiliary functionality in the WINMAN system for the execution of the experiments. These requirements should be stated here and must be taken into account during the implementation phase.

Executors The partners responsible for the execution of the experiment and the report of the results. These partners will be assigned at the time when the experiments can be executed.

Involved test-beds The test-bed that must or can be used for the experiments. The assignment of the test-bed will be done at the time when the experiments can be executed



2. Experiments validating WINMAN Non-Functional Attributes

Before describing the experiments on the WINMAN non-functional attributes, these attributes are described in detail in the next section.

2.1. The definition of the attributes A distributed system is constituted of a number of co-operating components that execute on a number of platforms of which the distribution (i.e. the number of nodes, the distance between the nodes, the operating system of the nodes) is transparent. Different components can be located on different nodes. Information between the distributed components is exchanged over well-defined interfaces that allow a clear separation of tasks and responsibilities among the components. Openness refers to the provisioning of interworking represented by meaningful interactions between components, possibly residing in different systems and portability represented by execution of components on different processing nodes without modification. In addition, the network management architecture is open mainly in the following directions: • It builds on the standard TMN and Internet MIBs • It builds network management elements that open the network resources (as standard interfaces) for use by

various network management applications. • It develops portable components capable to execute on different network management nodes and

platforms. • It develops interoperation and interworking between management applications components. • It is a non- propriety architecture Flexibility normally means being capable of both evolving and accommodating the existence and continued operation of legacy or new systems. An open distributed system should be capable of facing run-time changes; for example, it should be capable of being dynamically reconfigured to accommodate changing circumstances. In the project context, the network management architecture and system is flexible mainly in the following directions: • It supports introduction of new management applications (fault, configuration, performance) with various

requirements using and sharing the MIBs. • It is based on a modular design to enable reuse of modules and plug-in of new modules. • It supports end-user and/or network management operator accessibility and control of the underlying

network resources • It supports the normal processing capabilities of the network resources. Modular means that a system consists of modules that can be removed, replaced, and upgraded without affecting the modules that are already in place. This avoids the creation of monolithic applications that make modifications to the software cumbersome. Scalability refers to the impact on performance as more entities (management applications, processes, network nodes, etc.) are added to the system. The way a system scales is, in great part, a function of its communication, computational, data, and time complexity. It may be an assessment of either how many operations or messages need to be generated to perform some action — known as message or communication complexity — or how long (how many iterations or cycles) an operation takes — known as time complexity. A related, but different, concept of complexity is computational complexity, which relates to how well a given procedure can be analytically described or determined. Data complexity refers to the complexity of data structures and their interdependencies. A high level of complexity, unless it is there to increase robustness, increases the threat to system operation and thus, to integrity.



The attribute closest to scalability is reliability, defined as probability of a system performing its purpose adequately for the period of time intended under the operation conditions encountered. Performance equates to the system throughput. This is often traded off against functionality since the more a system tries to do the lower its throughput is. Any degradation of system performance can, if magnified, significantly affect a system’s overall integrity status. Robustness, which can be defined as the ability of the system to handle unexpected events, is proportional to integrity — the more robust the system is, the more likely it is to retain a high level of integrity within its operational environment. A system that is robust can cope with all eventualities and continue operation (does not ‘halt’ except when required to). The opposite of robust is brittle. A system is brittle if it is likely to fail in most circumstances of the operational environment. Integrity is understood to mean that the system maintains its correct and proper functional profile. It is defined as the ability of the system to retain its specified attributes in terms of performance and functionality. This applies to the system as a stand-alone component as well as integrated into the emerging compound mesh of interconnected networks. These systems take the form of a vast distributed system in which interdependence of components is growing exponentially.

2.2. Openness and Portability The following scenario will evaluate the WINMAN system openness and portability.

Priority <high, medium, low>

Objectives Provision of interworking represented by meaningful interactions between components residing in different systems. The WINMAN system in capable to open the network resources, as standard interfaces, for use by various network management applications. The interface should be compiled by commercially ad-hoc readers such as GDMO, IDL readers. The MIB of the northbound interface should be opened and traversed using MIB browsers. WINMAN system will operate in various operating systems, including at least HP-UX, Solaris and Win NT 4 or Win 2000. The functionality should remain the same regardless the operating system used.

Required tools Compatible interpreters, compilers or parsers to develop a solution for the different available platforms. Basic software of each platform where the WINMAN solution will run. Protocol analyser.

Required infrastructure Workstations exist with different operating systems to the one that is already used. General management platform.

Expected outcome • The INMS will operate on all platforms and interface with other network management platforms

(i.e. HP-OV, IBM NetView).

Experiment Set up • The complete WINMAN solution is installed and operating in the test-bed. • Workstations exist with different operating systems to the one that is already used.

Experiment Scenario Pre-conditions:

• The complete WINMAN solution is installed and integrated in the test-bed. • Workstations exist with different operating systems to the one that is already used.



• Install disks of WINMAN are available. Scenario steps: Portability

1. Compile or directly install the INMS on a different operating system. 2. The functionality should remain the same regardless the operating system used.

Openness 1. Compile the interface by commercially ad-hoc readers such as GDMO, IDL readers. 2. The MIB of the northbound interface should be opened and traversed using a MIB browser. 3. Interface to a commercial available management platform.

Executors <list of responsible partners>

Involved test-beds <list of involved test-beds>

2.3. Flexibility and Modularity The WINMAN system flexibility and modularity will be evaluated by the scenario presented below Priority <high, medium, low>

Objectives To demonstrate that the WINMAN system is flexible (in terms of accessibility, new applications integration, different levels of functionality, network elements scope, etc.) and modular (in terms of ease of reconfiguration, expansion, upgrades, etc.).

Required Tools Application development tools. Compatible interpreters, compilers or parsers to develop a solution for the available platforms. Basic software of each platform where the WINMAN solution will run. System monitoring tools System Performance measuring tools.

Required Infrastructure The WINMAN system is installed in the test-beds. Ability to upgrade some software modules The Workstation operators must be able to start and stop the different WINMAN services (applications) in the various Management areas The Workstation operators must be able to use each application of the WINMAN system with the role of Network operator, or the end-user/ customer.

Expected outcome • The INMS will operate normally when different applications are started or shut down from different

Workstations. • The software modules that comprise the WINMAN system can be stopped, removed, replaced,

recompiled and reintegrated to the system. • The Workstation users logging in as network operators or users must observe the differences in

functionality and accessibility to the network resources and the management information. • New applications that are introduced can use the existing MIB and the historical data



Experiment Set up • A minimum configuration of IP over WDM network is present • I-NMS module exists • IP-NMS module exists • WDM-NMS module exists • Configuration Manager sub-module, Performance Manager sub-module and Fault Manager sub-

module exist for both IP-NMS and WDM-NMS modules


• I-NMS is present. • Configuration Manager sub-module of IP-NMS and WDM-NMS modules are present. • The Configuration Manager sub-modules can create instances of the IP-nodes, WDM-nodes and

WDM-links and can specify their attributes. • The Configuration Manager sub-modules maintain the status and relationship of the nodes and links. • The above modules function properly together.

Scenario steps:

A. Flexible Modules Integration To demonstrate the system modularity & ability to incorporate new management applications and their impact on the system and the shared resources

1. Add modules • Performance Manager sub-module of the IP-NMS module is added to the WINMAN system. • Fault Manager sub-module of the WDM-NMS module is added to the WINMAN system.

2. Performance Manager and Fault Manager sub-modules take into account the existing information entered into the system by the Configuration Manager sub-modules.

3. The WINMAN system operates using the additional functionality of the new modules added. 4. Observe the interaction of the new modules with the existing ones (discovery of environment, request

to use components, MIB access, access and processing of historical data, etc.) B. Flexible Upgrade of WINMAN modules

To demonstrate that the system is flexible and modular so as to upgrade and use some of its modules without side effects to the system operation

1. Upgrade modules 1.1. The Configuration Manager sub-module of the IP-NMS and/or WDM-NMS modules is

upgraded and re-installed. 1.2. The Performance Manager sub-module of the IP-NMS and/or WDM-NMS modules is

upgraded and re-installed. 1.2.1. Existing configuration information is not lost. 1.2.2. Performance Manager sub-module takes into account the changes to the

Configuration Manager sub-modules. 1.3. The Fault Manager sub-module of the IP-NMS and/or WDM-NMS modules is upgraded and

re-installed. 1.3.1. Existing configuration information is not lost. 1.3.2. Fault Manager sub-module takes into account the changes to the Configuration

Manager sub-modules. 2. The WINMAN system continues to operate properly supporting the increased functionality of the

modified modules as well.



C. Different Operator Accessibility To demonstrate the flexibility of the system in terms of different user level access and control from different points

1. A Workstation user logs in the WINMAN system using different access levels (network operator, end-user, etc.). For each session the user must observe: • the scope of the network elements that can be managed • the available functionality for each application • the permitted operations on the underlying network elements

Related Experiments Experiments related to robustness



2.4. Scalability


Objectives Increase in the number of network elements will not cause major performance problems to the WINMAN system.

Required tools System performance monitoring tools Network emulator

Required infrastructure The WINNAM solution installed in test-beds. The capability to emulate additional network elements.

Expected outcome • The system will still perform uninterrupted with a great number of managed objects and without major

performance problems.

Experiment Set up • A minimum configuration of WDM and IP network is present. • An emulator will create additional network elements (e.g. 500 WDM nodes and 1000 IP nodes).

Experiment Scenario Pre-conditions: • A minimum configuration of IP over WDM network is present. Scenario steps:

1. Record the response and CPU processing time values to perform a specific task common to all network elements. (e.g. get the SysLocation from all NE’s)

2. Double the number of NE’s and perform the test of step 1. The response and CPU processing time values should be less than double.

3. An emulator will create additional network elements (e.g. 500 WDM nodes and 1000 IP nodes). 4. Major performance problems will not occur in the WINMAN system.

Related Experiments Experiments related to robustness





2.5. Robustness The WINMAN system robustness and integrity will be evaluated by the scenario presented below Priority <high, medium, low>

Objectives To demonstrate that the WINMAN system can cope with unexpected inputs and circumstances. The WINMAN system should be operational even under extreme situations.

Background Evaluating robustness is the most difficult task since it deals with unforeseen inputs and extreme situations. It becomes even more difficult for distributed applications (as the WINMAN system is) because their concurrent nature causes interleavings of events that can be difficult to be predicted. Although, the time is the best evaluator of robustness, the later can be evaluated by fitting the system with extreme data (either extremely large or small datasets, or boundary values) and bogus data (too large / small, or invalid values), and by placing it under considerable stress.

Required Tools Network simulator System Performance measuring tools Network Analyser

Required Infrastructure The WINMAN system is installed in the test-beds. Additional NEs not managed by the WINMAN system (this can be emulated).

Expected outcome • the WINMAN system still works correctly when placed under considerable stress • the WINMAN system can detects error and successfully recover from them

Experiment Set up • The proposed (for the specific HW) maximum configuration of WDM and IP network is present or

emulated. • The WINMAN system is operating


• The proposed maximum configuration of WDM and IP network is present or emulated. The whole network is managed by the WINMAN system.

• Availability of an EMS with misconfigured management interface in the sense that it sends alarm messages to WINMAN and not to its manager.

Scenario steps:

1. WINMAN is receiving alarms from a not registered EMS. 2. While a transaction between WINMAN and an EMS is in progress the EMS crashes. 3. Some of the distributed components of the WINMAN system are experiencing communication

instability. 4. The WINMAN operator (WO) is asking for a large report. 5. WO adds much more NEs. 6. While WO is waiting WINMAN for the completion of certain tasks, she/he is forcing WINMAN

application to end. 7. The communication with the SMS is very slow. 8. A great number of physical links (except those of DCN) is released, producing a storm of events.



9. The WINMAN system should cope with all the above extreme circumstances, even if they occur concurrently. The WINMAN system should prevent the WO from illegal operations and recover successfully from errors.

Related Experiments Experiments related to scalability, performance and modularity





3. Experiments validating the WINMAN Functional Attributes

Although showing WINMAN non-functional attributes is quite important for the prototype of the project, it is not its main focus. The main objective of WINMAN, and accordingly for this deliverable, is its functional characteristics. The WINMAN solution intends to provide an integrated network management system, which is capable of providing managed end-to-end IP connectivity services derived from Service Level Agreements (SLAs). In other words, WINMAN will design, implement and test in-field a Network Management System, capable of performing integrated provisioning of IP/MPLS Label Switched Paths over optical paths, as well as integrated multi-layer fault and performance management. WINMAN functionality lies in the areas of Configuration, Fault and Performance management, which will be separated according to the Tele-Management Forum TOM areas as follows:

• Network Provisioning and Network Inventory for Configuration Management • Network Maintenance and Restoration for Fault Management and • Network Data Management for Performance Management

These experiments proposed below aim to exhibit and validate the above functionality, as this was captured by the corresponding requirements in WP2. Nevertheless, the scenarios are high-level ones, capable of demonstrating the main achievements of the project to an external audience, being the main functional characteristics of the system. Detailed test cases will take place in WP3, testing the WINMAN stand-alone components, subsystems and integrated system with simulated networks. WP4 high-level scenarios continue the work from WP3 to exhibit the main objectives of the project in an in-field integrated system. In this way, the external audience can verify that the functional attributes specified in the objectives of the project are really met. The main scope is to exhibit the inter-technology functionality of WINMAN, but single domain functionality dealing with IP only or WDM only, will be accommodated. This will be useful for the WINMAN operator, giving her/him the opportunity to realise useful or necessary single-domain functionality, but also allowing to project partners having only one technology domain in their test-beds, to exhibit the capabilities of the systems to the public. Note, that WINMAN develops not only the Inter-technology NMS (INMS), but also an IP NMS and a WDM NMS. As far as single domain network provisioning functionality, the creation of IP/MPLS and optical paths scenarios will be described for the IP and WDM domains accordingly. The Network Inventory focuses on the correct depiction, through the GUI, of the managed network infrastructure. Finally the integrated Connectivity Service, dealing with both domains will be presented. Fault and Performance functionality will be demonstrated only for the Inter-domain case, for which WINMAN provides added value. The architecture of the WINMAN NMSs is compliant with the IETF policy-based management model. It identifies a Policy Manager, which is functionally equivalent for the Configuration, Performance and Fault Management views of the system. Some Policy Enforcement Points (PEPs) are identified, which are in fact the aggregation of other functional blocks. This points out that in WINMAN we understand the Policy Based Management concept not as an additional management function but as the same management functions (or part of them) of conventional systems under the control of policies. Under this assumption, every experiment performed on the system will lead to different results aligned with the current active policies, because policies change dynamically the system behaviour. For example the “ICS Provisioning” experiment can have different outputs if some policies are changed from one round of the experiment to the next. Having this remark in mind, all the following described experiments can have numerous versions based upon the applied policies. That is to say that concurrently with a given experiment, the Add, Activate, Execute and Remove Policies scenarios will be also tested.



3.1. Configuration Management

3.1.1. Network Provisioning

3.1.1.1 Create optical path Objectives <high, medium, low>

Objectives • To demonstrate the creation of an end-to-end optical path in the WDM network by the WINMAN

operator • To demonstrate the correct interaction and integration among the WINMAN subsystems and external

WDM systems or hardware: GUI (INMS), WDM-NMS, WDM EMS and WDM elements • To demonstrate the capability of the WDM-NMS for communicating with the corresponding EMS and

the Elements of the test-bed • To show the capability of the WDM-NMS for maintaining consistent and valid the databases and the

inventory of the optical network, according to the real resources of the network • To show that the WDM-NMS complies with the requirements of WDM network provisioning

Background It is essential for the WINMAN operator to be able to provide manually end-to-end optical paths, either during the initialisation/configuration of the IP over WDM network, following the network planning period, or for any other reason (fault, performance degradation, capacity exhaustion), that the WINMAN management system was unable to automatically resolve. In addition, to control WDM network resources state and their modifications is a basic management action for WINMAN configuration functionality. The WINMAN operator has to be able to initially configure or reconfigure the WDM network using the GUI. This process has to be simple and quick for the operator, who has to know the relevant parameters for the correct creation of the nodes. The GUI will interact with the WDM-NMS (possibly via the INMS), which in turn will have to talk with the corresponding EMS and with the INMS for performing the changes and for updating the databases. In this phase, the intervention of the WINMAN Operator is necessary, who is responsible for deciding if the network modifications will appear in the Network Map or not.

Required Tools This experiment requires the hardware infrastructure for running the WINMAN solution over the managed network. Within WINMAN, the GUI, the INMS, the WDM-NMS and the southbound interface must be operational. In the test-bed the operation of the corresponding EMS is necessary. This EMS has to provide the proper functionality for WINMAN requirements. Some optical testing instruments could be necessary for measuring the signals in the test-bed.

Required Infrastructure Hardware of the WDM network will be installed and connected in an appropriate network topology. This network must consist of a number of WDM nodes (preferably 3 Add-Drop Multiplexers re-configurable through the management system) and must permit ring configuration. The appropriate DCN will be available to provide connection of the management system to the network elements.

Expected outcome • The WDM connectivity is delivered in the network. The performance of the network connections

could be measured by means of optical testing equipment. • Any modifications made to the WDM network resources will be taken into account by the

configuration functionality of WDM-NMS. • The information will be stored in the databases and showed by the GUI. The databases and the

network map will be updated according to the addition of a WDM optical path.



Experiment Set up • The WINMAN system should be operational. The functionality of the GUI, the INMS and the WDM-

NMS is mandatory, as well as the functionality of the South Bound interface. • The EMSs of the managed network infrastructure are operational and they support the WINMAN

southbound interface. • The WDM network infrastructure and configuration is established. • Instruments should be available to detect a link establishment. • Direct traffic analysers along the southbound interface towards the EMSs can check the input from the

WINMAN system.

Experiment Scenario This scenario will be executed with different operator requests having different values as edge physical ports. Pre-conditions:

• The WDM network nodes are installed, the network resources are established and they are all connected in an appropriate network topology.

• The relevant EMSs are operational. • WINMAN applications are operational, the GUI is operational and the databases contain all relevant

data of the network. • The DCN is operating. • The necessary tools described above are operational.

Scenario steps:

1. The WINMAN operator initiates a request for the creation of an optical path through a GUI or a script.

2. The WINMAN system receives and processes the request and performs all the internal steps to satisfy the request.

3. The WDM NMS communicates with the WDM EMS(s) splitting the end-to-end creation request to its concatenations (if any) and sending them over the DCN.

4. The WDM EMS(s) communicate with the elements to create the path 5. The success or failure of the flow-through procedure is communicated to the INMS and GUI 6. The operator monitors the WINMAN console and GUI 7. The operator reads the testing equipment and WDM equipment leds 8. The operator reads the logs and databases 9. The experiment scenario ends

Related Experiments • This experiment scenario is related to the scenarios that show the GUI-functionality. • This experiment scenario is related to the scenario showing inter-domain connectivity functionality.



3.1.1.2 Create IP/MPLS path Priority <high, medium, low>

Objectives The experiment is to verify that IP NMS functionality is able to provide all the consecutive procedures for the provision of an ICS that comprises only the IP technology domain. This represents the simplest case of the IP management when WDM optical domain is not involved in the transmission. The ICS will be provided by means of an MPLS LSP.



Background A test-bed or Service Provider owner of IP equipment but no WDM can use this experiment in order to test the basic WINMAN functionality of creating end-to-end connections over the IP connectionless (but MPLS enabled) infrastructure. From this point of view make sense to have this pure IP/MPLS experiment separated from the general ICS Provisioning, which involves a complete IP/WDM network and management infrastructure.

Required tools The interface between IP NMS and IP EMS must be implemented. This interface will carry out the needed set of commands from NMS in order to establish the desired LSP with the required QoS constraints from source to destination. An application running on end systems attached to source and destination nodes and generating an IP stream.

Required infrastructure A test-bed comprising a set of IP routers connected via non-WDM links under a certain network topology. Some protocol analysing tools would be needed in order to monitor the creation of the LSP. A workstation shall be connected to end nodes in order to run traffic tests.

Expected outcome • IP NMS will establish an LSP over the IP infrastructure. • This change in the connectivity will be reflected in the topology map. • Any relevant acknowledgements will be monitored.

Experiment Setup • The IP network infrastructure is established. • The IP routers are configured and their routing tables are initialised. • The IP-NMS and IP-EMS are running and plugged in to the set-up. • Monitor points are established and protocol analyser is plugged-in. • End systems are initialised.


• The test-bed IP-EMS and IP-NMS are initialised. • Physical links are configured according to a given network topology. • IP routers are configured and the routing tables are updated according to a given network topology.

Scenario steps:

1. The WINMAN operator chooses source and destination nodes and signals the creation of an ICS 2. IP-NMS communicates with IP-EMS of the source and destination nodes and sends the needed set of

commands for the establishment of the LSP. 3. Endpoints start selected application. 4. IP-NMS monitors the process of the transmission. 5. WINMAN Operator reviews the correct IP/MPLS creation. 6. The experiment scenario ends

Related Experiments ICS Provisioning





3.1.1.3 ICS provisioning Different end-users services (MoIP, VoIP, VPN) will require different connectivity services from the network. This experiment will prove that the WINMAN solution is able to accept and process a VPN service.


Objectives The WINMAN serves a request from a Service Management System for the provisioning of IP Network Connectivity that supports the VPN service to the end-users. The WINMAN system will show its flow-through provisioning capability, i.e., that the request will be processed fully automatically from request reception to service operational. The operations of the service will be made visible by means of end-users applications making use the network connections. The data stored in the WINMAN databases will be checked for validity and consistency. The flow-through provisioning capability is one of the main features of the solution, which makes this experiment very significant for the project. This experiment will be promoted to a demonstration capability of the system. The request may contain different attributes and values for these attributes concerning the Network Level Agreement for the connectivity service

Background A company having several sites spread over the country wants to interconnect the LANs of each site via an IP network with high-speed connections, a high level of security and a certain level of service quality. The solution will be an IP-based VPN. The VPN must support real-time and non real-time services. The SMS system orders the network connectivity over an interface, which is a publicly specified interface.

Required tools A hardware platform for running the WINMAN management components connected to the managed network. End-user applications that generate traffic that will flow over the provisioned network connections. Traffic analysers that can measure the QoS parameters of the user flows.

Required infrastructure A network consisting of IP routers connected to a WDM network with end-user equipment connected to the IP edge routers. The WINMAN management systems must be able to communicate via a DCN with the network nodes. If the real network is not available the network can be emulated in a network simulator tool.

Expected outcome The IP connectivity is delivered in the network. The end-user applications are able to make use of the delivered network services. The performance of the network connections will be measured by means of IP traffic analysers and will be reflected by the quality perception of the end-user applications.

Experiment Set up • End-user equipment is connected to IP edge routers. On top of this equipment end-users will run their

applications like VoIP and MoIP, which generate real-time class of traffic. Also non real-time applications may run on this equipment like file transfer, database access, and Internet browsing.

• An SMS system is connected to WINMAN. This may be a commercial system, which is able to accept requests from end-users, or it may a SMS simulator, which is pre-provisioned to generate a request to the WINMAN system.

• The IP and WDM NMS systems are connected to IP and WDM EMSs in the test-beds via the southbound interface.

• Test equipment is connected to certain measurement points in the network for the monitoring of the provisioned connections.

• Auxiliary windows on the GUI for the monitoring of the contents of the databases.

Experiment Scenario This scenario will be executed with different service requests having different values for the service attributes.



Pre-conditions: • The managed network is operational and the basic network configuration is provisioned. • WINMAN applications are operational, the GUI is operational and the databases contain all relevant

data of the network. • The SMS system, the end-user equipment and applications are operational.

Scenario steps:

1. In case of a commercial SMS system: The end-user sends request for VPN connectivity to the SMS system. The SMS system sends request to the WINMAN system. In case of SMS simulator: The simulator executes a script, which generates the request to the WINMAN system.

2. WINMAN processes the requests and executes all the steps of the flowthrough provisioning process without any interference from the operator.

3. During the provisioning process WINMAN communicates over the DCN to the EMSs. 4. Monitor the start and performance of the end-user applications. 5. Read out the test equipment 6. Read the WINMAN databases 7. The experiment scenario ends

Additional WINMAN system requirements • Auxiliary windows on the GUI for the monitoring of the contents of the databases.

Related experiments Create Optical path, Create IP/MPLS path



3.1.2. Network Inventory Management

3.1.2.1 Network inventory consistency to network infrastructure The Network Inventory functionality of the WINMAN system will be evaluated by the following scenario.


Objectives Provision and maintenance of the Network Inventory in an accurate and consistent manner with respect to the underlying network infrastructure. The WINMAN system upon initialisation should not only discover correctly the underlining network infrastructure and store it to the Network Inventory, but it should also continue to check its consistency (i.e. modification/removal/addition of links or nodes). Through the GUI the WINMAN operator can evaluate the Network Inventory stored information. This experiment requires all WINMAN subsystems (GUI, INMS, IP NMS, WDM NMS) steady co-operation. Its NMS should be capable of updating/validating the network view of its domain. This experiment can be used for demonstrating the WINMAN system.

Background The presentation of an accurate and consistent view of the managed network is considered as basic functionality for a network management system. The graphical representation of the network enables the NMS operator to have an easy to understand view of the network.

Required tools The execution of this experiment requires that the WINMAN system is installed in a hardware platform, and has all four subsystems (GUI, INMS, IP-NMS, WDM-NMS) communicating with each other. The appropriate EMSs supporting the predefined southbound interface should be installed. Direct access to these EMSs is also



welcomed since it will help to examine the precise input of the WINMAN system (alarms for appropriate network infrastructure modifications, etc).

Required infrastructure For a full scenario execution a network infrastructure combining both network domains (IP, WDM) is required. However, since WINMAN perception of the underlying network is based on the predefined southbound interface with the EMSs, a testing program or a simulator that supports this interface can be used.

Expected outcome • Upon start up the network map depicts correctly the initial set up of the network. • Afterwards, the network map is continually updated, depicting the network infrastructure

modifications that were performed.

Experiment Set up • The EMSs of the network infrastructure to be managed, or the simulators/testing programs are

operational and they support the WINMAN southbound interface. • The WINMAN system should be set up and operational. The full functionality of all subsystems is not

prerequisite, but the support of the WINMAN southbound interface, the WINMAN Network Inventory functionality and the GUI network map display functionality are mandatory.

• Direct interfaces to the EMSs (or even to the nodes themselves) are welcomed to check the input to the WINMAN system.

Experiment Scenario This scenario will be executed performing some or all of the following actions to the underling network (simulated or real):

• modify a link • add a link/node • remove a link/node

Pre-conditions:

• The relevant EMSs are operational. • In case of using simulator/testing program, it is operational too. • The WINMAN system is operational.

Scenario steps:

1. The WINMAN system starts up. The network map that is presented corresponds the network to be managed.

2. The chosen action, from the ones described above, is performed. 3. Through the direct interfaces to the EMSs we certify that the action is performed. In case of using

simulator/testing program, we certify that the appropriate scripts/input files are used. 4. The corresponding changes are performed to the Network Inventory and therefore are displayed in the

network map of the WINMAN GUI. 5. Return to step 2 and perform next action, form the ones described above, to the network infrastructure. 6. Continue with steps 3 and 4. 7. If there are no actions to be performed, the experiment scenario ends.

Related Experiments The experiment scenario is also related to the scenarios that are relevant to the configuration responsibilities."





3.2. Fault Management

3.2.1. Network Maintenance & Restoration

3.2.1.1 ICS maintenance and restoration Priority <high, medium, low>

Objectives This experiment scenario will demonstrate the fault management functionality of the WINMAN system. It has to do with notification / alarm reporting to the SMS regarding faults which affect an ICS. Each NMS will detect faults in its respective sub-network. The faults will be presented to the user via the GUI NMS. Alarms reflect malfunctions of network elements and their components, which the network consists of. A fault that occurs in the network (e.g. a hardware or software failure) flows upwards through the WINMAN system, reported to the WINMAN operator and calls for the appropriate actions. The cause and the location of the problem must be detected.

Background WINMAN offers a combination of functionalities: alarm processing rules, filtering, and customisable alarm viewing. A failure, depending on its range or severity, can have degrading results for a provisioned service and thus special concern is required for the timely notification and prompt restoration. FM experiments are quite critical, since they shall validate the proper handling of events / alarms as they propagate from the element layer to upper layers. When a fault occurs in the inter-domain sector, it may result in an event storm of thousands of events per second. Every logical or physical managed object, involved in delivering IP or Optical connectivity, is expected to generate large numbers of events. In such a huge flow of alarms, filtering and correlation is mandatory for operators to focus on root causes and to shorten the reaction time. The major difficulty in inter-domain correlation and filtering is event delay. Events are produced by the WDMs and received by the network management applications that are monitoring different optical network sectors. In this step there is a delay-time associated with each event, due to DCN implications. Further more, event processing within each Element Manager and/or higher management applications results in additional delays. The same applies to the events that are produced by the IP nodes and are transferred to DCN management. In both cases, second-generation events are produced and transferred to I-NMS. Ideally, events would arrive in bursts, and it would be possible to buffer them on receipt and apply correlation processes between bursts. However, usually and in cases of critical faults or outages, event storms are continuous. Therefore alarm-event decoding and alarm processing should take place at the speed of event reception. If all events were delayed by an equal amount of time within the inter-domain network and the management applications, the correlation process would simply be the superposition of some delta time offset from real time.

Required tools • Alarm generator or an appropriate alarm log file. • Test equipment to validate the cause and location of the faults detected. • Trouble Ticketing system.

Required infrastructure A minimum configuration of IP over WDM network is present. However, since WINMAN perception of the underlying network is based on the predefined southbound interface with the EMSs, an alarm generator or a simulator that supports this interface can be used.

Expected outcome • The WINMAN operator will not be overwhelmed by a massive flow of redundant or meaningless

alarms. • The network failure is properly interpreted as an alarm notification by the WINMAN system. • The root cause and the location of the failure should be found.



Experiment Set up • The network infrastructure and configuration is established. • The WINMAN system is interfaced to the EMSs. • There are measurement points at certain component interfaces to monitor the flow-through of the

notifications.

Experiment Scenario An optical card is removed from a WDM, connecting a couple of IP routers to the backbone. The event received from the routers (or the router EMS) should be suppressed if a prior event from the WDM is received. Suppose that it is normally expected that the WDM event (A) is received prior to the IP event (B). But what if B is received first? It would be sufficient to simply remember that B was arrived and consider it when A arrives. But what if A is not received at all? The system should hold B until no A may arrive (for a time window frame). In this experiment every case will be checked. Pre-conditions:

• An end-user service, like VPN service is already established, which is implemented as an ICS inside WINMAN.

• WINMAN system and its GUI are operational • A correlation mechanism (for example, in the form of a rule-based engine) is present. • There are no alarms.

Scenario steps:

1. An optical card is removed from a WDM, connecting a couple of IP routers to the backbone. This scenario could also be executed for the case where an IP edge router that connects the LAN of a user to the WDM backbone goes down, because of either a software (e.g. routing table corruption) malfunction or a hardware (e.g. power loss) fault.

2. Monitor the events that are output by the IP-NMS and WDM-NMS. 3. I-NMS receives a. first the alarms from WDM-NMS and then from IP-NMS, as expected b. first the alarms from IP-NMS and then (inside a defined time window frame) from WDM-

NMS 4. I-NMS is correlating and filtering the alarms 5. GUI (I-NMS) is pointing out only the WDM card as non-functioning for any case of step 2. 6. Check that during failure, the Operational State of the affected equipment is set to ‘Disabled’. 7. The location and fault details are interfaced to a Trouble Ticket system for a further activation of field

units. 8. The experiment scenario ends.

Post-conditions: The recovery procedure in the WINMAN system has been started and another notification is expected to show the result (success, fail or partial success).

Related Experiments Experiments dealing with GUI functionality. ICS assurance





3.3. Performance Management

3.3.1. Network Data Management

3.3.1.1 ICS assurance The provisioned connectivity services will be monitored and the monitoring data will be collected, processed and stored by the WINMAN solution. The connectivity services will be stressed in a way that the NLA will just be met or not be met. The stressing can be in terms of traffic (consuming the capacity of physical links) or in terms of the quality of the physical links). This will lead to pro-active (e.g. provide extra capacity) and active (e.g. re-routing) maintenance actions by the WINMAN solution. The WINMAN System has to be able to notify performance problems in the IP over WDM network. These notifications are alarms that are opened to trigger Network Maintenance & Restoration mechanisms. In the cases where the failures compromise the SLA, WINMAN must send a notification to the SMS. WINMAN must also store historical data about performance measurements and events in order to be able to present to the WINMAN Operator performance measurements reports when it is asked. In this experiment scenery the form for eliminating the cause of the alarms is not treated. Moreover, the Network Map should depict the failure, highlighting the links and nodes with problems, and the problems with the traffic in the IP over WDM Network.


Objectives With this experiment we can show that the WINMAN system is able to understand performance parameters and to assure their fulfilment. To do this the WINMAN system must receive performance measurements from the EMS. WINMAN will show the capacity to receive them and to interpret them in any technology. With this experience we pretend also to show the capacity that the WINMAN has to take decisions on situations were the parameters of the services are not being met, and to show that WINMAN can solve the problem effectively and rapidly. We will demonstrate also how the WINMAN system notifies the WINMAN Operator (through the GUI and through performance reports) and the SMS (through messages sent to the northbound interface).

Background The management of alarms is a hard task considering the actual size of the Networks, the mixture of involved technologies and the services supported by them. So, is important that a Management System can perform “intelligent” treatment of the alarms, for determining the real causes of the problem, and, may be, for solving them. In this case, the alarms will be caused by the exceeding of minimal thresholds of performance within an optical network, generating problems in QoS in data transport. This problem is notified by the corresponding EMS. The WINMAN system aims to the provisioning of IP services with QoS warranties. Performance measurements have to be assessed in order to guarantee QoS parameters in the network. WINMAN has to note if some QoS parameters have been degraded. Part of this task can be performed by the EMS, which must deliver to WINMAN the data-traffic measurements and/or notify by itself some performance degradations in the Network.

Required tools All the direct interfaces for testing the Input and Output of each component are desirable. Particularly, an interface able to check the information from the South Bound interface of WINMAN is mandatory. A generator of traffic will be necessary to generate data through the Optical network. Also, a tool or a method for generating problems in the performance of the WDM equipment will be necessary. Traffic analysers that can measure the QoS parameters of the user flows.

Required infrastructure A minimum configuration of IP over WDM network is present. The operation of the corresponding EMSs is necessary, being able to send performance measurements to WINMAN.



Software emulating WDM-network connected to a set of IP routers, representing a certain network topology, can also be used.

Expected outcome The problem of performance will be detected by the WINMAN system, which generates an alarm of performance degradation. If the problem is persistent the Network Map will highlight the nodes with problems and the databases will be updated. Also, if needed the service is rerouted at the IP or WDM layer. If the service is damaged, a message of performance degradation is sent through the North Bound interface to the SMS. If the problem is transitory, none action is performed, and only the databases are updated. Triggered by a request from the WINMAN Operator, the WINMAN system should produce a performance report that shows that there was a performance deterioration of the service and that the problem was solved automatically by the WINMAN system.

Experiment Set up • The EMSs of the network infrastructure to be managed are operational and they support the WINMAN

southbound interface. This EMS is able to detect some performance degradations in the Network. • The WINMAN system should be operational. The functionality of the GUI, the INMS and the WDM-

NMS, as well as the South Bound interface is mandatory. • Direct interfaces to the EMSs and the nodes are desirable to check the input to the WINMAN system. • The IP routers are configured and their routing tables are initialised. • End-user equipment is connected to IP edge routers and services are established. On top of this

equipment end-users will run their applications like VoIP and MoIP, which generate real-time class of traffic. Also non real-time applications may run on this equipment like file transfer, database access, and Internet browsing.

• Test equipment is connected to certain measurement points in the network for the monitoring of the provisioned connections.

• Auxiliary windows on the GUI for the monitoring of the contents of the databases. • Tools for generating performance degradation in the optical networks will have to be operational.

Experiment Scenario The scenario can be repeated several times in order to test all the possible situations. Pre-conditions:

• The managed network is operational and the basic network configuration is provisioned. WINMAN is monitoring active services.

• WINMAN applications are operational, the GUI is operational and the databases contain all relevant data of the network.

• There is at least one service active with QoS constraints. Scenario steps:

1. Something causes performance degradation on some link of the network (IP or WDM) and an active service is affected

2. The WINMAN system that is continuously monitoring service performance parameters, or the corresponding EMS detects the performance degradation.

3. The WINMAN system detects the failure, and recognises it as a performance problem in the network. 4. If the problem is transitory WINMAN doesn’t do anything (but the information is stored on event logs

and can be consulted by the WINMAN Operator by requesting a Performance Management Report). 5. If the problem endangers any service WINMAN will trigger an alarm so Network Management &

Restoration can reroute the service and update the network Inventory (again all actions are stored in logs that can be viewed by the WINMAN Operator).

6. If the WINMAN system cannot solve the problem, or if a service was severely affected during the recover operation, the SMS receives a message from the WINMAN system.

7. The experiment scenario ends.

Related Experiments • Network Provisioning • Fault Management



4. Conclusions The WINMAN project adopts an innovative approach of integrating IP and WDM networks. Instead of extending the distributed Internet network control approach to the Optical Layer using signalling, WINMAN proposes an alternative approach by employing the telecom-style network management in both the WDM and IP layer in an integrated way. The feasibility of the approach is guaranteed by the deployment of the MPLS Internet packet switching protocol, which resembles a connection-oriented network. This approach has been adopted and is being carried out in WINMAN, whose aim is to offer an integrated network management solution for the provisioning of end-to-end IP connectivity services. WINMAN consists of an open, distributed, and scalable management architecture supporting multi-vendor, multi-technology environments. The project will contribute to the establishment and operation of world-wide IP over WDM networks. The trials envisaged in the project would demonstrate the functional and non-functional capabilities of the developed management systems across a world-wide network management infrastructure. This deliverable specified a set of high-level experiments scenarios to exhibit the above-mentioned-WINMAN functional and non-functional attributes, in respect to the project objectives and the target requirements identified in the initial stages (WP2) of the project. The purpose of the document is to identify scenarios exhibiting and validating the basic WINMAN non-functional and functional attributes. A set of high-level scenarios was identified, that will be used to demonstrate the main achievements of the project to an external audience. Note that, as already explained, this document will be updated in a later stage of the project, in order to update and review the content of some parts of the identified template for the experiment scenarios.



Abbreviations DCN Data Communication Network

EM Element Manager

EML Element Management Layer

EMS Element Management System

FM Fault Management

GbE Gigabit Ethernet

GUI Graphical User Interface

ICS IP Connectivity Service

I-NMS Integrated Network Management System Inter-technology Network Management System

IP Internet Protocol

LSP Label Switched Path

MIB Management Information Base

MPLS Multi-Protocol Label Switching

NE Network Element

NI Northbound Interface

NLA Network Level Agreement

NMS Network Management System

OADM Optical Add-Drop Multiplexer

PDP Policy Decision Point

PEP Policy Enforcement Point

QoS Quality of Service

SDH Synchronous Digital Hierarchy

SLA Service Level Agreement

SMS Service Management System

SNMP Simple Network Management Protocol

VPN Virtual Private Network

WDM Wavelength division multiplexing

WINMAN WDM and IP Network Management

WO WINMAN Operator

WPx Work Package x



Appendix A. WINMAN test-bed infrastructure In this appendix the different test-beds are briefly presented following the answers to an issued questionnaire and any more information given by the test-bed providers. These test-beds are going to be tuned appropriately to accommodate the execution of the experiments specified in this document. Five WINMAN partners’ test-beds, spread in Europe as depicted in figureA.1, have been presented according to the present and foreseen equipment availability. One of the available test-beds, this of UPC, is not based on WDM links but it can be useful in the sense of testing the WINMAN IP-NMS. Moreover, UPC test-bed is the only one having available a Policy based management. Test-beds of PTI and OTE should be available in the near future since they are waiting for equipment procurement. OTE is going to use wavelengths from its commercial network in order to interconnect the R&D department’s IP routers. LNT and UCL are planning to apply IP QoS (MPLS) to their WDM/IP test-beds. The test-beds are differentiated and will be interconnected in management plane. This provides value added to the project since more than one environments will be used.

Figure A.1: Geographical view of WINMAN test-beds

A.1. Test-bed of LTN The Lucent test-bed, called LAMPION, is a metro type network with ring architecture. There are four nodes in the ring 8 km apart. Each node consists of an OADM, which can add/drop two wavelengths. Connected to each OADM is an Ethernet layer2 switch with two optical (WDM) interfaces. One of the wavelengths is fixed and connected to the hub. This hub terminates the optical signal and acts as gateway to the outside world. The other wavelength can be programmed. Each node has 24 10/100Mb ports. There are 7 wavelengths available in the ring.

UCL

UPCOTE

LTN

PTIDCNDCN

UCL

UPCOTE

LTN

PTIDCNDCN



WDM RING

OpticalADM

OpticalADM

Optical Hub

OpticalADM

Gigabit EthernetSwitch/ IP Router




Internet

10/100 MbpsEthernet LAN




Figure A.2: Lucent Test-bed Physical Architecture

Contact Person Willem A. Romijn

Lucent Technologies B.V Botterstraat 45, Huizen, The Netherlands tel: +31 35 687 4672, fax: +31 35 687 5954, email: [email protected]

Technical Responsible

Same as contact person

Location Huizen. It is located at most 1 hour travelling from Amsterdam Schiphol, by public transportation, taxi, rent cars.

Lucent’s test-bed Restrictions 1. Restricted to Lucent personnel by default.

2. Lucent personnel must accompany all visitors at all times. 3. Lucent internal network may only be used by authorised personnel. 4. Lucent maintains strict rules regarding their firewall.

Workplaces/WSs 2/- Internet facilities No. See restriction No 4. Remote access Only access via WINMAN specific interfaces will be provided and are subject

to firewall rules. General Mngt Infrastructure

IP test traffic generator/analyser

Protocols Routing protocols, GbE, not yet QoS for IP. Equipments



3 Multiprotocol Routers, Cajun P330R / per Router 24 10/100Mb Ethernet interfaces Mngt: SNMP

3 WDM add/drop multiplexer, in-house development / two optical add/drop ports per OADM connected to IP Router Mngt: TAO based Corba platform, outband management via separate fibre in test-bed, Corba based server as agent, TMF Forum 2.0 (Lucent predecessor) WinNT WS

Management Platforms: Tao Corba based platform for CM/FM/NM / running on MSwin-NT, NT GUI / use of SNMP for IP routers and corba for WDM.

A.2. Test-bed of OTE The figures bellow, provide the Logical (Figure A.3) and Physical (FigureA.4) architecture of the WDM network test-bed, which is currently under deployment by OTE. The WDM ring of 32 lambda will be a commercial network. The R&D will have full access to four (4) OChs (lambdas) which can be used by the WINMAN project. Three different encapsulation techniques of IP over WDM will be provided. Namely IP/ATM/SDH/WDM, IP/GbE/WDM, IP/POS/SDH/WDM & finally in the fibre between National Technical University of Athens (NTUA) and Kapodistrian University of Athens (UofAthens) a DPT ring will also be established (to be determined end of April 2001).

Figure A.3: OTE Test-bed Logical Architecture The Management for this WDM subnetwork will be collocated between OTE R&D Lab-A and the management centre of the Greek National Network of Research and Technology (EDET). The full OTE Attiki- WDM network is a 9 node ring of 32 OCh (2.5 Gbps/OCh). At each network node there will be an OADM with the capability to add/drop 8 OCh (lambdas). Each OCh will be connected to an IP router (Currently available CISCO 7200, and 7500 series routers) or ATM switch card. There is a possibility that the Metropolitan Network CISCO 15200 and/or 15454 series WDM systems will be loaned for the period of the project duration to do testing and interoperability tests.

IP over WDM

DWDM Αttiki

ΟΤΕ- R&D Lab Α

ΟΤΕ- R&DLab B

NTUA

UofAthens

λ1

λ2

λ3

λ4

Fiber

FiberIP over WDM

DWDM Αttiki

ΟΤΕ- R&D Lab Α

ΟΤΕ- R&DLab B

NTUA

UofAthens

λ1

λ2

λ3

λ4

IP over WDM

DWDM Αttiki

ΟΤΕ- R&D Lab Α

ΟΤΕ- R&DLab B

NTUA

UofAthens

λ1

λ2

λ3

λ4

Fiber

Fiber



Figure A.4: OTE Test-bed Logical Architecture

Contact Person Dimitris I. Chronis

Hellenic Telecommunications Organization OTE HQ, 99 Kifissias Ave. Amaroussion, Athens, Greece tel: +30 1 6118432, fax: +30 1 6118214, email: [email protected]

Technical Responsible Tilemachos Doukoglou Location Five minutes from OTE headquarters by car or Shuttle Bus

OTE test-bed Restrictions No restrictions within working hours. Contact test-bed responsible Workplaces/WSs Two workplaces, 1 partner per site Internet facilities Yes (some security restrictions might apply for telnet) Remote access Telnet access to test-bed, controlled by firewall General Mngt Infrastructure

IBM NetView, HP OV, PetLab

Protocols IP over ATM over SDH now, IP/ATM/SDH/WDM 07/2001, IP/POS or GbE/WDM 09/2001 / Use of QoS in the ATM layer, Provision of QoS via MPLS in the future IP over WDM test-bed

Equipments Exact configuration to be determined. Management Platforms: FM for the existing WDM network. Full management of the DWDM test-bed,

which is in procurement stage.

ATTIKI WDM RING

OpticalADM

OpticalADM




Internet

Optical

OTE R&D LabA OTE R&D LabB

NTUAUniv. of Athens

ATTIKI WDM RING

OpticalADM

OpticalADM




Internet

Optical

OTE R&D LabA OTE R&D LabB

NTUAUniv. of Athens



A.3. Test-bed of PTI Three 7204 Cisco routers are used as label switch routers (in the MPLS network core) and 3 Linux routers with two NICs will be used in order to perform the ingress and egress on the MPLS backbone, acting as LERs.

Figure A.5: PTI IP-Test-bed Architecture

The Linux routers are connected to the Cisco routers by Ethernet. The connections between the Cisco routers are supported by WDM. The next figure shows a possible network topology.

The next figure shows how PTI network should look like.

TTx

TTx

TRx

TRx

ADM

TTx

TTx

TRx

TRx

TT

x

TT

x

TR

x

LSR Cisco 7204

MPLS Backbone



Contact Person Nuno Silva Portugal Telecom Inovação, SA Rua Eng. José Ferreira Pinto Basto, 3810 AVEIRO tel: +351 234 403 394, fax: +351 234 424 160, email: [email protected]

Technical Responsible Same as contact person Location Aveiro / Portugal

Nearest airport: Porto PTI test-bed Restrictions Magnetic card-controlled access to lab Workplaces/WSs Internet facilities Yes Remote access Telnet access to test-bed, controlled by firewall General Mngt Infrastructure

HP OpenView, Osimis / IP protocol analysers (RADCOM prismlite, and Ethereal version 0.8.14-open source). Traffic generators.

Protocols Routing protocols, MPLS, LDP, CR-LDP, RSVP, RSVP-TE, DiffServ , PPP, HDLC, ATM, Ethernet

Equipments 3 multiprotocol routers, cisco7204 / Ethernet, Quadruple Ethernet, ATM (155 Mbps), IOS 12.1(5)T

3 IP routers, Linux PC acting as an IP router with a MPLS package/ Ethernet/ CLI, telnet, secure shell, FTP, TCP/IP, MPLS, LDP, RIP, OSPF / RedHat Linux 6.2, Kernel 2.4.0-test11 MPLS-Linux-0.700, LDP-portable-0.600 3 OMUX, Optical multiplex and de-multiplex / SDH STM-16, Gigabit Ethernet / SNMP 12 Transponders / SDH STM-16, Gigabit Ethernet / SNMP 3 OADM, Optical add-drop multiplex / SDH STM-16, Gigabit Ethernet / SNMP Management Platforms: - On the test-bed the management is done by CLI or telnet.

- HP OpenView / CM,FM / HP-UX, X-windows / used for Cisco, Linux Routers, Linux PCs - OpenNMS, Open Source NMS (similar to HP OpenView)

A.4. Test-bed of UCL UCL will provide an innovate, experimental, and thus fully manageable, WDM trial environment, sited in UK. UCL Test-bed includes: Data-plane

• 32-wavelength recirculating fibre loop WDM test-bed. OTDM functionality is available to WINMAN for experimentation.

T ADM

T

LERLinux

LER Linux

LER Linux

LSR Cisco 7204

LSR Cisco 7204

LSR Cisco 7204

T

EthernetWDMOptical



• Free-space, high-resolution WDM mux/demuxs and cross connects • IP routers are considered to be added, according to WINMAN requirements. An IP router can be

connected to both Multiwavelength source and λ-add-drop (see Fig.A.6), which will allow for emulation of the full-functional IP network with three or more nodes.

Management-plane • All WDM equipments provide open interfaces, of rich functionality in CM, FM and PM to WINMAN

for integration.

AO1

EDFA

Multi-wave-lengthsource

Freespace de mux and/or crossconnect

λ1

add-drop

10-40 Gbit./sNRZ or RZ

Variable loop length/dispersion

Data processing

+EDFA

λ2 λ3...λNRe ceive r

Error de tector

Sampling oscilloscope

AO2

Delay gene rator for loop

synchronisation

3 dB coupler

λλ1

λN

N=32+

AO1

EDFA




λ1

add-drop



Data processing

+EDFA


Error de tector


AO2


synchronisation

3 dB coupler

λλ1

λN

N=32+

IProuter

AO1

EDFA



λ1

add-drop



Data processing

+EDFA


Error de tector


AO2


synchronisation

3 dB coupler

λλ1

λN

N=32+

AO1

EDFA




λ1

add-drop



Data processing

+EDFA


Error de tector


AO2


synchronisation

3 dB coupler

λλ1

λN

N=32+

IProuter

IProuter

Figure A.6: UCL Test-bed Architecture

Contact Person Nikolaos Vardalachos

University College London Department of Electronic & Electrical Engineering, Torrington Place, London WC1E 7JE tel: +44 (0)20 7679 5766, fax: +44 (0)20 7388 9325, email: [email protected]

Technical Responsible

Nikolaos Vardalachos (IP), Vitaly Michailov (WDM)

Location London. Gower Street, Floor 2 & Torrington Place Floors 6 & 8

UCL test-bed Restrictions Magnetic card-controlled access to lab Workplaces/WSs Internet facilities Yes Remote access Telnet access to test-bed, controlled by firewall General Mngt Infrastructure

AdventNet SNMP, NetBeans / Software-based IP traffic generation, capture and analysis (Tcpdump,ethereal)

Protocols Routing protocols, Frame Relay and ATM over serial lines, Fast Ethernet, RSVP, MPLS CoS, DiffServ, many queuing disciplines and traffic classification supported

Equipments



2 16-channel WDM transmitter / GPIB RS232 interfaces

1 Free Space Demultiplexer (router), UCL made, Demultiplexing (wavelength routing)

1-2 Recirculating fibre loop system, UCL designed & built / GPIB interfaces / currently carry out long haul WDM/OTDM transmission experiments – planned expansion to include optical burst switching, packet generation and transmission and optical routing 3 multiprotocol router, PC with Linux (Debian 2.2) installed / ATM cards, 100 Base Tx Mngt: SNMP 2 ATM switch , Fore (Marconi Comms) / 4 Multimode ports, 4 UTP ports / Fore proprietary signalling & ATM Forum Signalling 3.0 UNI ,4.0 Management Platforms: - IBM NetView / CM, PM, FM / used for ATM switches

- AdventNet SNMP / CM, PM, FM / used for Linux routers, ATM switches, ATM interface cards / Linux, Windows, Solaris , java GUI - For WDM: GPIB network, LabView compatible, Pascal/C software / Configured manually or using GPIB-controlled software and drivers

A.5. Test-bed of UPC The test-bed is composed by several Cisco routers and workstations. The routers are connected by means of high-speed serial interfaces (up to 2 Mbps full-duplex), Ethernet and Fast Ethernet (10 to 100 Mbps). We also have an ATM switch and an ATM interface for the Cisco routers. Right now we’re running a couple of different configurations, one devoted to RSVP applications testing, and the other implementing an MPLS/BGP IP-VPN model based on draft-rosen-rfc2547bis-02.txt (obsoletes RFC 2547) with traffic engineering add-ons. The workstations provide the user interface to the test-bed, by means of CLI access to the routers Craft Interface and also by management applications. We also run traffic generator and sniffer software on these platforms. We’re testing several Policy Based Network Management applications on the test-bed.

Network Management Group - UPCMPLS/BGP testbed lay-out

CE1750_1

PE7200_2

P7200_1

PE7200_3

CE1750_2

s1/0111.0.1.2/30

s1/2111.0.1.17/30

s0111.0.1.118

s1/0111.0.1.1/30

s1/0111.0.1.18/30

lo 222.2.1.3/32

lo 222.2.1.2/32

lo 222.2.5.1/32

lo 222.2.5.2/32

lo1111.0.5.1/32

lo2111.0.5.2/32

lo1111.0.2.1/32

lo2111.0.2.2/32

S0111.0.1.102

S1/1111.0.1.101

VPN: RedSite 1

VPN: RedSite 2

lo 222.2.1.1/32

lo 222.2.2.1/32

S1/3111.0.1.113

s1/3111.0.1.117

CE2600

lo1111.0.4.1/32

lo2111.0.4.2/32

S0111.0.1.114

VPN: GreenSite 1

lo0 222.2.4.1/32

F0/0111.0.1.109

101.0.1.106/30 VPN: GreenSite 2

fast 0/0192.100.100.10/24

fast 0/0101.0.1.105/30

MPLS TRAFFIC-ENGINNERING TUNNELS FOR VPN TRAFFIC

Figure A.7: UPC Test-bed Architecture

Contact Person Eduardo Grampín

Universitat Politècnica de Catalunya Departament de Teoria del Senyal i Comunicacions, 08034 BARCELONA (SPAIN) tel:+34 93 401 7214/+34 93 401 5623, fax:+34 93 401 7200, email: [email protected]



Technical Responsible Same as contact person Location Barcelona/SPAIN

From downtown take L3 to Palau Reial UPC test-bed Restrictions Magnetic card-controlled access to lab Workplaces/WSs -/4 Internet facilities Yes Remote access Telnet access to test-bed, controlled by firewall General Mngt Infrastructure

HP OpenView, Osimis, Software-based IP traffic generation, capture and analysis

Protocols Routing protocols, Frame Relay and ATM over serial lines, Fast Ethernet, RSVP, MPLS CoS, DiffServ, many queuing disciplines and traffic classification supported

Equipments 3 Multiprotocol Routers, Cisco7204 / Fast Ethernet, Quadruple serial, ATM (155 Mbps) / IP over PPP, HDLC, Frame Relay, ATM / IOS 12.0(7)T Mngt: CLI, inband, RMON 2 Multiprotocol Routers, Cisco750 / Fast Ethernet, Double serial / IP over PPP, HDLC, Frame Relay, ATM / IOS 12.0(3)T Mngt: CLI, inband, RMON 1 Multiprotocol Router, Cisco2612 / Fast Ethernet, Double serial, Token Ring / IP over PPP, HDLC, Frame Relay, ATM / IOS 12.0(7)T Mngt: CLI, inband, RMON WinNT WS

Management Platforms: - HP PolicyXpert, HP OpenView Policy Based Manager vía CLI-proxy / CM, PBNM / running on MSwin-NT - Cisco QPM-PRO, Cisco Policy Based Manager via CLI / CM, PBNM / running on MSwin-NT / QoS provisioning - Nortel PPS / CM, PBNM / Nortel Preside Policy Services – Set of management applications, including PBNM and VPNs / running on UNIX, web browsers / VPN provisioning RFC2547 compliant



Appendix B. Underlying Network Architecture This appendix provides an Integrated IP/WDM network architecture to be considered in the WINMAN test-beds.

B.1. General Characteristics The Network Architecture that WINMAN is focusing is an architecture providing integrated IP over WDM services. The basic principles for the integrated IP/WDM architecture are the following:

- WDM is considered as a core/backbone technology - IP is always interconnected to the WDM equipment at the edges of the core network

Such a network is mainly considered by Internet Service Providers and in particular, Competitive Operators, owning optical infrastructure and willing to provide IP services on top of it. Incumbent operators could also deploy such a network, where in that case they integrate their existing ATM and SDH infrastructure to make use of the DWDM backbone or core. WINMAN focus is managing the IP over WDM part of the network without implementing any functionality for ATM/SDH networks. ISP’s main business cases for DWDM investments relevant to WINMAN are mainly the provisioning of Internet capacity to its customers and the provisioning to customers of VPNs among different sites scattered in metropolitan or wide area distances. The DWDM network can also serve ATM and SDH traffic, being not in the scope of WINMAN. The above can be summarised in the following figures, covering both the Metropolitan Area and the Wide Area Network or Backbone network.

B.2. Metropolitan Area Figure B.1 depicts a potential ISP’s metropolitan network consisting of a WDM optical metro core and IP metro access. The IP section is composed by a number of IP points of presence (PoPs), where customers can access the IP network services and traffic is groomed and forwarded to other PoPs or networks through the backbone. Access is facilitated to customers through the interconnection of the ISP’s Provider Edge (PE) IP routers with the Customer Edge (CE) IP routers. The ATM and SDH equipment are shown for completeness purposes and are out of the scope of this project. Provider equipment can be collocated or not with the customer equipment, depending on the distance between customer and provider premises and on the amount of traffic generated by the customer and the tele-housing policies. The optical DWDM Metro core is composed by a ring of re-configurable Optical Add-Drop Multiplexers (OADMs), while additional point-to-point WDM links with Terminal Multiplexers (TMs) can be considered for big customers. OADMs are remotely managed and can be re-configured via an appropriate management system to add and drop wavelengths (optical channels) to the ring, as optical multiplexed line signal. The IP metro access is composed by a set of PE routers interconnected with optical interfaces with the OADMs. Note that in some cases a single PE router cannot handle in terms of interfaces or capacity the traffic inserted by the customers and a bundle of IP routers (usually collocated in a rack) are used to serve such a situation. These IP routers are usually interconnected via Ethernet interfaces, which are considered pure IP for WINMAN. Each metropolitan area network uses a Provider (P) Router, which is the one grooming all the traffic from PE routers of the metro area and forwards it to the backbone or another P router located elsewhere (usually another city or another operator).



In case there are two DWDM rings, then an optical cross-connect is needed to switch wavelengths from one ring to the other as shown in figure B.1. WINMAN is focusing its attention in all IP Provider Edge (PE) routers and the IP Provider (P) router of each metropolitan area. Note, that the IP collocated routers interconnected with pure IP interfaces (Ethernet) mentioned above, could be managed by the WINMAN system as well. In addition, all the WDM equipment in the picture are inside the scope of WINMAN.

Figure B.1- Metropolitan Area IP over B1DWDM Example

B.3. Wide Area Network The Wide Area network is usually composed of a mesh optical DWDM network. In case the distances do not allow the use of re-configurable OADMs (the power budget is not sufficient for big distances around 600-1000km), then point-to-point Terminal long-haul DWDM Multiplexers are being used as shown in figure B.2, in co-operation with the proper line Optical Amplifiers (not shown in the figure). These Optical Terminal Multiplexers can co-operate with the proper fixed or re-configurable OADMs to support the end-to-end optical path, which is usually called the light-path. IP routers are needed in all the geographical areas, where access IP traffic through the corresponding PE and CE routers is inserted. Note that in case optical TMs are used, then the P routers are placed between two co-located DWDM TMs, which are also interconnected back-to-back with optical fibres (patches).

ATM

IP

Customer Premises

IP Customer Edge (CE) Router

IP Provider Edge (PE) Router

PE RouterCE Router

IP Provider (P) Router

WDM OADMRING

WDM Backbone

SDH

SDH

WDMOADM RINGMetro Core

Metro Access

IP LAN WDMOADM RINGMetro Core

OXC

WDM Line System

WDM Line System

SDH

ATM IP

IP SDH

WDMMetroOADM



Figure B.2- Wide Area IP over DWDM Network Example .

B.4. WINMAN Test Configuration The underlying network architecture presented in the previous section are taken by real network architectures, but are considered too complicated for a field trial in the WINMAN project. In order to demonstrate the functionality of the proposed Inter Domain Network management solution, a simpler network configuration should be used. That is exactly the purpose of this section i.e. to propose a physical topology as well as test-bed configuration, that allow demonstrating the basic functionality (Configuration, Fault and Performance Management).Since the technology adopted for IP switching/routing is MPLS, the minimum number of routers in an MPLS domain is three, as follow:

• Ingress Label Switch Router (LSR), which puts the corresponding label and classifies the incoming to the MPLS domain packets

• Transit LSR, which forwards the packet according to its label and its Cross-Connect Table • Egress LSR, which removes the label of the packet exiting the MPLS domain and forwards

the packets. In order to demonstrate a simple path-provisioning scenario we need at least one transit LSR whereas for the demonstration of fault or performance management functionality we need a second transit LSR. An example with 4 OADMs, 3 PE routers and 3 P routers is shown in figure B.3. We consider that the basic principles explained in the previous appendix chapter apply. In addition, we simulate routers with WDM interfaces by providing multiple optical interfaces in one element, since these will come to the market gradually inside 2001. In this way, we could demonstrate the proper functionality regarding mainly performance and fault management simulating the failure, performance degradation or capacity exhaustion of one of the interfaces. The overall context according to our proposal is outlined in the following figure, showing the field trial configuration together with the corresponding IP topology.

P Router

WDM Backbone

Metro


Metro


PE Router

CE Router

CE Router

PE Router

PE RouterCE

CE

PE Routers

P Router SDH

SDHATM

ATM

SDH

CE Routers

CE

PE



POS-4 POS-16 Gigabit Ethernet

R1 R2 R3

R4

R6

R5

P PE P

P

PE

PE

Interfaces

R1 R2

R4

R5

R6

R3

PPEP

P

PE

PE

(a) (b)

Figure B.3: (a) Field Trial Configuration Example, (b) IP topology

* type: pu-public, pp-limited, re-restricted, co-internal ... filedeliverable (d4.1) - description...

Documents