<%BANNER%>

Record for a UF thesis. Title & abstract won't display until thesis is accessible after 2010-12-31.

Permanent Link: http://ufdc.ufl.edu/UFE0022767/00001

Material Information

Title: Record for a UF thesis. Title & abstract won't display until thesis is accessible after 2010-12-31.
Physical Description: Book
Language: english
Creator: Kumar, Arvindhan
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: Electrical and Computer Engineering -- Dissertations, Academic -- UF
Genre: Electrical and Computer Engineering thesis, M.S.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Statement of Responsibility: by Arvindhan Kumar.
Thesis: Thesis (M.S.)--University of Florida, 2008.
Local: Adviser: McNair, Janise Y.
Electronic Access: INACCESSIBLE UNTIL 2010-12-31

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022767:00001

Permanent Link: http://ufdc.ufl.edu/UFE0022767/00001

Material Information

Title: Record for a UF thesis. Title & abstract won't display until thesis is accessible after 2010-12-31.
Physical Description: Book
Language: english
Creator: Kumar, Arvindhan
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: Electrical and Computer Engineering -- Dissertations, Academic -- UF
Genre: Electrical and Computer Engineering thesis, M.S.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Statement of Responsibility: by Arvindhan Kumar.
Thesis: Thesis (M.S.)--University of Florida, 2008.
Local: Adviser: McNair, Janise Y.
Electronic Access: INACCESSIBLE UNTIL 2010-12-31

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022767:00001


This item has the following downloads:


Full Text

PAGE 1

1 WDM LAN ARCHITECTURE ANALYSIS, MODELING, AND OPTIMIZATION FOR AVIONIC PLATFORMS By ARVINDHAN KUMAR A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2008

PAGE 2

2 2008 Arvindhan Kumar

PAGE 3

3 To my Parents

PAGE 4

4 ACKNOWLEDGMENTS I offer my sincere gratitude to my Committee Chair, Dr. Janise McNair, who supported me with her patience and knowledge while allowing me the room to work in my own way. Without her encouragement, guidance and persistent help I believe this thesis would not be possible. One simply could not wish for a be tter or friendlier supervisor. I thank the members of my supervisory co mmittee, Dr. John Harris and Dr. Ramakant Srivastava for their due support and time. I would like to add a note of thanks to Dr. Alan D. George and his HCS lab research students who work ed on Phase I of the project, for their input. I thank the sponsors for the cu rrent work, US NAVY and RSoft Design group, Inc. This section would become void if I did not th ank my lab researchers for their contribution to this work. Madhan Sivakumar and Dexiang Wa ng (as a part of our research group on WDM LANs here at the WAMS lab) were instrumental in achieving this enormous work on time. I thank my parents, family members, and few special friends who were always there when I needed motivation and help. I thank them a ll for the unconditional love and support during my course of study as a Masters student.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS ............................................................................................................... 4LIST OF TABLES ...........................................................................................................................8LIST OF FIGURES .........................................................................................................................9ABSTRACT ...................................................................................................................... .............12 CHAPTER 1 INTRODUCTION .................................................................................................................. 14Avionics Network Requirements ............................................................................................15Functional Requirements ................................................................................................. 16Environmental Requirements .......................................................................................... 17Cost and Life Cycle Requirements .................................................................................. 17SAE Standards Activity ..........................................................................................................18STTR Phase 1 Objective and Findings ............................................................................ 19STTR Phase 2 Objective and Findings ............................................................................ 192 OPTICAL COMPONENTS MODELING ............................................................................. 22Artifex Simulation Environment ............................................................................................ 22Modeling Delay Factors in DRAGON ............................................................................ 24Modeling Signal Degradation and Noise Effects in DRAGON ...................................... 24Modeling Continuous Events in a Discrete Event Environment .....................................25DRAGON Library ................................................................................................................ ..26Optical Fiber ................................................................................................................. ...26Optical Tran smitters ........................................................................................................ 27Optical Detectors .............................................................................................................29Optical Amplifier .............................................................................................................29Coupler and Splitter ......................................................................................................... 30Optical Filter ................................................................................................................ ....31Optical Switch .................................................................................................................32Optical Add/Drop Multiplexer ........................................................................................33Summary ....................................................................................................................... ..........343 AVIONIC WDM LAN ARCHITECTURES ......................................................................... 35Primary Network Topologies ................................................................................................. 35Point to-Point .................................................................................................................35Ring/ Hub-Based Rings ...................................................................................................36Bus ........................................................................................................................... ........36Star .......................................................................................................................... .........37

PAGE 6

6 Optical Tree .....................................................................................................................38Phase II WDM LAN Architecture Modeling ..................................................................39Ring-Hybrid Architecture .......................................................................................................40Mesh-Torus Architecture ........................................................................................................42Controller Node Denotation ............................................................................................ 43WDM LAN Backbone Topology .................................................................................... 43WDM LAN Sub-System Topology ................................................................................. 44Summary ....................................................................................................................... ..........474 RESOURCE MANAGEMENT AND ACCE SS CONTROL PROT OCOLS FOR WDM LANS .......................................................................................................................... ............48Traffic Prioritization ...............................................................................................................50High Priority Traffic (HP) ...............................................................................................52Medium and Low Priority Traffic (MLP) .......................................................................52High Priority Wavelength Assignment and Routing .............................................................. 53Wavelength Assignment .................................................................................................. 53Lightpath Establishment and Routing ............................................................................. 54Case I lightpath establishment ..................................................................................54Case II lightpath establishment ................................................................................ 55Controller Node Physical Structure .................................................................................56The XYTARP Medium and Low Priority Wa velength Assignme nt and Routing ................. 57The MLP Protocol Design I : X-Y Routing .................................................................... 57The MLP Protocol Design II : OTDM ............................................................................60The XYTARP Second Tier Wavelength Assi gnme nt and Routing Protocol .........................63Summary ....................................................................................................................... ..........655 FAULT TOLERANCE FOR AVIONIC WDM LANS ......................................................... 66Network Reliability a nd Fault Tolerance ............................................................................... 66Fault Detection and Isolation ...........................................................................................68Fault Recovery/Tolerance ...............................................................................................70Fault Tolerance Requirements in Avionic Networks ...................................................... 71The XYTARP Architecture Fault Tolerance Analysis ........................................................... 73Fault Detection: Hello Packets and Link Status Notifications ........................................73Link Status Table and Routing Table .............................................................................. 75Fault Tolerance for High Priority Traffic ........................................................................78Fault tolerance for Medium and Low priority packets .................................................... 79Fault Tolerance for Second Tier Access Networks .........................................................82Summary ....................................................................................................................... ..........84

PAGE 7

7 6 WDM LAN MODELING, SIMULATI ON ANALYSIS AND RESULTS ........................... 85Traffic Generator Models in Artifex .......................................................................................87Simulation Metrics ..................................................................................................................91Packet Latency .................................................................................................................91LSN Latency ....................................................................................................................93Data Throughput ..............................................................................................................93Dropped Packet Ratio ......................................................................................................93The XYTARP Backbone Network Access Protocol Simulation Results and Analysis ......... 93Design I: Broadcast and Select Protocol Simulation Results .......................................... 94Design II: OTDM/WDM Protocol Simulation Results ...................................................97Comparative Analysis of Desi gn I and OTDM/WDM Protocol .....................................98Backbone Network Performance with Base Traffic ......................................................100The XYTARP Access Network Simulati on Results and Analysis ....................................... 101The XYTARP Architecture Backbone Torus Fau lt Toleranc e Simulation Analysis and Results ..................................................................................................................................104Average Packet Latency ................................................................................................106LSN Latency ..................................................................................................................107Dropped Packet Ratio ....................................................................................................108Network Throughput .....................................................................................................109The XYTARP Architecture Access Network Fau lt Toleranc e Simulation Analysis and Results ..................................................................................................................................110Summary ....................................................................................................................... ........1137 SUMMARY AND CONCLUSION .....................................................................................114LIST OF REFERENCES .............................................................................................................116BIOGRAPHICAL SKETCH .......................................................................................................118

PAGE 8

8 LIST OF TABLES Table page 1-1. Comparison between copper/TSP cable and fiber optics in avionic platforms ................. 155-1. Link Status Table maintained at each sub-system controller nodes ..................................755-2. Routing Table maintained at each sub-system controller nodes ........................................ 776-1. The MLP backbone torus base traffic configuration ....................................................... 1006-2. Base traffic configuration results for the backbone network ........................................... 1016-3. The HP base traffic configuration ....................................................................................1056-4. Average packet latency for high, medium and low priority packets in presence of faults ........................................................................................................................ .........106

PAGE 9

9 LIST OF FIGURES Figure page 2-1. A simple Petri-net ..............................................................................................................232-2. Optical fiber model in DRAGON library .......................................................................... 272-3. Fixed laser model in DRAGON library ............................................................................. 282-4. Tunable laser model in DRAGON library ......................................................................... 282-5. Fixed photo detector model in DRAGON library .............................................................. 292-6. Optical amplifier m odel in DRAGON library ................................................................... 302-7. Symmetric 2x1 Coupler model in DRAGON library ........................................................312-8. Optical filter model in DRAGON library .......................................................................... 312-9. Dynamic optical switch model in DRAGON library ......................................................... 322-10. Optical Add-Drop Multiplexer function ............................................................................332-11. Dynamic OADM model in DRAGON library ................................................................... 333-1. Hub-based ring topology....................................................................................................363-2. Folded Bus topology ..........................................................................................................373-3. Star topology ......................................................................................................................383-4. Optical Tree configuration .................................................................................................393-5. Ring-ring architecture .................................................................................................. ......403-6. Ring-hybrid architecture ....................................................................................................413-7. Torus controller node denotation .......................................................................................433-8. A 4x4 Hybrid Torus architecture (1st Tier backbone network) .........................................443-9. Second tier Star-Ring topology .......................................................................................... 453-10. Semi-torus interconnection of the second tier nodes through outlet nodes .......................464-1. The HP Lightpath setup with sub-systems in different row/column of backbone torus .... 544-2. The HP Lightpath setup with sub-systems in the same row/column of backbone torus ... 55

PAGE 10

10 4-3. Controller node physical struct ure to support HP lightpath setup ..................................... 564-4. Circular wavelength assignm ent strategy for MLP traffic ................................................. 584-5. The X-Y base routing for backbone MLP traffic ............................................................... 594-6. Time slot allocation strate gies for OTDM/WDM protocol ............................................... 614-7. Intra-Ring communication fo r second-tier MLP packets .................................................. 644-8. The OTDM time slot allocation fo r second tier intraring communication ....................... 655-1. Path and Link routing explained ........................................................................................ 705-2. High priority backbone torus network fault tolerance ....................................................... 785-3. The MLP fault tolerance r econfiguration and re-routing. ..................................................805-4. Second tier access network fault tolerance ........................................................................ 836-1. Bursty traffic generator model .......................................................................................... .886-2. Periodic and Poisson traffic generator model .................................................................... 896-3. Bursty traffic generator model .......................................................................................... .916-4. Average Latency for Design I broadcast and select protocol for different traffic patterns ...................................................................................................................... .........956-5. Throughput performance for Design I broa dcast and select prot ocol under different traffic patterns ....................................................................................................................966-6. Performance analysis of OTDM/WDM protocol ..............................................................976-7. Comparative performance analysis of Design I and OTDM/WDM protocol .................... 986-8. Comparative performance analysis of Design I and OTDM/WDM protocol .................... 996-9. Average Latency for second tier access ne twork with different traffic patterns ............. 1026-10. Throughput performance for second tier access network with different traffic patterns ...................................................................................................................... .......1036-11. The LSN latency for a link fa ilure between controller 11 and 12 ................................... 1086-12. Fault tolerance in terms of droppe d packet ratio vs number of faults ............................. 1096-13. Fault tolerance in terms of ne twork throughput vs number of faults ............................... 110

PAGE 11

11 6-14. Second tier HP fault tole rance test using average pack et latency me tric (cockpit wing 1 subsystem)............................................................................................................1116-15. Second tier HP fault tolerance test us ing network throughput metric (cockpit wing 1 subsystem).....................................................................................................................112

PAGE 12

12 Abstract of Thesis Presen ted to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science WDM LAN ARCHITECTURE ANALYSIS, MODELING, AND OPTIMIZATION FOR AVIONIC PLATFORMS By Arvindhan Kumar December 2008 Chair: Janise McNair Major: Electrical and Computer Engineering Optical Networking with Wavelength Divi sion Multiplexing (WDM) has the immense potential to satisfy the future needs of avioni cs systems (both military and commercial), due to huge bandwidth, low interference, re liability, light weight and the potential for a unified network with protocol independence. Moreover, the pr edominantly passive nature of the optical components provides for greater si mplicity and robustness and has th e potential to deliver lower life-cycle costs, in spite of th e significantly higher bandwidth and greater levels of integration optical networks will be expected to support. Despite these many major advantages, there ar e many challenges when considering optical network technology to realize a high-perform ance, local-area network (LAN) onboard an aircraft. It requires continually feeding data to and receiving data from many different subsystems, from life-sustaining to weather sens ors. Additionally, the ae rospace environment is very hostile and imposes many constraints on th e system design. So to design a network that strictly meets the requirements of the avi onics community poses an increasingly difficult challenge. In an attempt to leverage the strengths of current and emerging optical networking technologies as a potent for future avionic applications, an X-Y routing based two-tiered Torus

PAGE 13

13 Architecture with redundant ports (XYTARP) is pr oposed. It is imperative that the system be fault tolerant to ensure its availability even during harsh environments to serve the mission critical avionic applications. A fault tolerant routing algorithm is proposed that provides optimal performance in the absence of fa ults, shows minimal degradation in the presence of faults, and can tolerate reasonable number of faults based on their physical occurrence. In the presence of fault, the routing algorithm dynamically reroute the packets along non-faulty links. A library of optical components is modeled in Artifex, a discrete-event simulator, and the proposed XYTARP architecture and routing protocols are built and evaluated above this library. The computer aided modeling approach to netw ork design proves its advantage in terms of flexibility in design, cost and time delay associated with building and testin g of physical test bed. Various experimental scenarios are considered to test the fault tolerance of the network and the design proves to sustain the minimum requireme nt of three network faults in a worst case scenario. The three main contributions in this wo rk include architecture analysis, resource management and routing, and fault tolerance analysis. Various possible architectures are evaluated for the current applica tion and the advantages of the proposed mesh torus architecture are analyzed. An efficient circular wavelength assignment strategy is proposed along with the XY routing protocol for the XYTARP and is analyzed using virtual prototyping and simulations. The importance of fault isolation, detection and r ecovery mechanism is analyzed and accordingly the routing protocols are modified to provide reliability and to meet the requirements.

PAGE 14

14 CHAPTER 1 INTRODUCTION The avionics community has been predicting the entry of fiber optic technology into both military and commercial airc rafts because of its projected benefits. However this widespread deployment or application has been impeded by technical, economic and perceived risk factors. The copper cable technology has been a favor ite among the community, even though it poses some penalty in terms of reliability, maintenance and weight on an aircraft. The fear that a fiber or optical component failure may bring down the entire network, and the absence of standards for commercial components creates a risk factor that prevents an emerging new platform of advancing fiber optic technology. A networked architecture, with a command response control approach that was designed for real time applications, that is, MILSTD-1553 has dominated the military aircraft environment and uses twisted shielded pair (TSP) copper wire as the transmission medium. Commercial aviation has similarly adopted an el ectrical bus standard through the Airlines Electronics Engineering Committee (AEEC). The benefits of such networked architectures are well recognized throughout the av ionics industry. A fiber optic implementation of the command response protocol was visualized as MIL-STD-1773 for military aircrafts, but it was short lived as it provided the same performance as the TSP (with added EMI/EMP immunity) at a higher cost. The initiation of integrated avionics during the development of new military aircrafts like F-22, A-12 and RAH-66 provided a platform for ne w avionics architectures incorporating high speed fiber optic networks. Here, a high speed fi ber optic data bus repl ace was proposed to the existing MIL-STD-1553 as the main avionics bus us ed to interconnect the integrated racks and functional sub-systems. A token passing protoc ol based on Society of Automotive Engineering

PAGE 15

15 (SAE) standard AS4074.1 and a linea r star-coupled topology was adopted. As this is only the first generation of fiber optic aircraft network that is currentl y being developed and qualified, a novel adaption of next generation avionic systems with WDM is re quired to operate in hostile aerospace environment without any addi tional environmental conditioning. Table 1-1, clarifies the comparison betw een a copper/TSP cable and fiber optic implementations in avionic platforms [1]. In or der to compare the latency performance of copper and fiber optics, lets assume a common transmission length of 100 meters for both, packet size of 100 bytes and assuming that copper operates at a rate of 10 Mbps compared to 1Gbps transmission speed of an optical laser. The p acket latency includes both transmission delay and propagation delay. Since bot h copper and fiber allows propagation at 2/3 the speed of light the propagation delay for both would be the same. In the above example the packet latency is 0.085ms for copper cables and 1.3us for fiber optics. Table 1-1. Comparison between copper/TSP cable and fiber optics in avionic platforms Parameters Copper/TSP cable Fiber optics Bandwidth 250 KHz 2 GHz Up to 25 THz Data rate 10 -100 Mbps 40 Gbps 1 Tbps Propagation speed 2*108 m/s 2*108 m/s Weight High Light weight Emi immunity Poor Better Immunity Average latency In milli seconds In micro or nano seconds Cost Low Higher but expected to come down Avionics Network Requirements Traditionally, WD M based fiber optics are reserved for long-haul links and highbandwidth trunks. But in avionics environment, th e links are numerous and relatively short, with a maximum length of 100m, and signals are rout ed among several nodes thus forming a local

PAGE 16

16 area network (LAN). In this secti on, the needs or requirements of a network user that are critical and specific to a system operating in the avionics domain is analyzed. Functional Requirements The configuration flexibility a nd scalability are key issues that determine the enduringness and therefore longevity of a network. Flexibilit y ensures easy installa tion, rearrangem ent and removal of avionics devices without the costly business of modifying the physical network topology. Such plugnplay type network suites reconfiguration in the event of an in-flight failure. The network must support high speed transmission between any two nodes in the network with the number of nodes in the ne twork spanning to a maximum of 256. While operation at full scale is importa nt, it is desirable for a unifi ed architecture that can be implemented for contemporary platforms, which may contain fewer than 256 nodes. A failure in the avionics network can have potentially disastrous consequences and it clearly requires more stress on the networks ro bustness and sustainability. A successful fault recovery mechanism requires the existence of a survivable physical network topology, which implies that a failed nodal element does not obstr uct the normal operation of the network i.e. no single point failure. Clearly the network should be ideally multiple-failu re tolerant and the existence of alternative, indepe ndent paths between sub-systems a llows for graceful performance degradation after three faults as opposed to a catastrophic failure. The required performance of an avionics LAN is not different from that of a traditional LAN that are generally high bit-ra te, low bit-error systems. These are real time systems requiring the transit of mission critical in formation with very low latency, in the order of microseconds. The network performance should not be affected by the precise location of components or fiber length and this is termed as installation transparency.

PAGE 17

17 Environmental Requirements The hostile aerospace op erating environm ent imposes many a constraints on the engineering and design of avionics systems. A pertinent problem is the temperature sensitivity of the components which may require h eaters or thermo-electric coolers that in turn translates into heavier generators and greater fuel consumption. Various optical components like optical lasers, filters and some sensors are subjected to spectr al drift due to temperature fluctuations. WDM systems are highly sensitive to temperature where wavelength channel drif ting due to refractive index and wavelength variations may result in crosstalk between adja cent channels. A full military temperature specification includes f unctioning even at -55C to +125C [1]. The military aircraft operates generally at altitudes between 1000 feet and 70, 000 feet and are subjected to linear accelerati on. In such cases the network desi gned must tolerate mechanical and acoustical vibration/shocks up to 30g peak. Cost and Life Cycle Requirements The cost of optical technology is at present relatively h igher than the traditional copperbased networks, but as the op tical components and technology matures and the momentum of telecommunications continues to cut down the prices, the reverse can soon be visualized. The most important cost associated with such a netw ork is its weight and power consumption, both of which directly affect the airc raft fuel consumption. The fibe r optics has a huge bandwidth to weight advantage over copper and power consump tion is comparable in both the systems. A significant part of the costs lies in the mainte nance over the operational life span and therefore there is an apparent drive to wards lowering such costs. Desi gn of reliable components and system in total, increases the life cycle of the en tire network and is highly desirable in terms of meeting the cost requirements.

PAGE 18

18 Its obvious that a reliable sy stem with built-in fault diagnosis procedures costs less and is also favored due to quick and easy replacement of fa ulty parts. The network is also expected to offer a reduced functionality operational mode to allow an aircraft to return to base for any acute servicing. SAE Standards Activity The SAE Avionic Syst ems Division (ASD) Technical Committee on Aerospace Avionic Systems sub-committee on Fiber Optics and Appl ied Photonics (AS-3) formed a standards working group, AS-5659 Aerospace Wave Division Multiplexed Local Area Network Standard, in April 2005 with the goal of developing a standard for WDM LANs (wavelength division multiplexed local area networks) for aerospace applications. The main objective is to architect a new standard WDM fiber optic network architecture for aerospace platforms that will not just supplement current networks, but completely replace all legacy networks to maximize the benefits of fiber optic network tec hnology and revolutionize networking in aerospace platforms. The novel WDM technology supports numerous independent data to be transmitted simultaneously at different optical wavelengths on a single strand of optical fiber. This provides protocol transparency on different wavelengths and the electronic bottleneck associated with time division multiplexed (TDM) systems is avoided. One of the goals of the availability of a WDM LAN standard is to help put in place metrics to evaluate and compare candidate architectures, providing an objective perspective on the various merits and complexity associated with each. Modeling and simulatio n tools are critical for addre ssing and realizing this goal. Designing, modeling, and simulating a high-spee d WDM network to be deployed in an aerospace environment with its unique requirements is a challenging task th at requires the use of sophisticated modeling and simulation tools.

PAGE 19

19 STTR Phase 1 Objective and Findings The work for this thesis was supported by a Sma ll business Technology TRansfer (STTR) grant from the United States Navy, u nder Award No. N68335-06-C-0386-P00001, which provided an industry/university partnership between RSoft Desi gn Group, Inc. and the Wireless And Mobile Systems Laboratory at the University of Florida. Phase 1 of the STTR project tasks were shared by team members at the High Pe rformance Computing Systems (HCS) Laboratory at the University of Florida and OptoNet, In c., the former focusing on networking and systems issues, and the later focusing on sub-system and de sign issues [2]. The main goals of this group towards the development of aerospace WDM LAN standard and deployment of systems include: Identify types of architecture that are capab le of being evaluated within the scope of modeling and simulation capabilities Describe the criteria for evaluation of architectures within the scope Develop a requirements specification for WDM LANs for aerospace application Map, analyze and model commercial products (legacy and emerging) Throughout Phase 1 of the STTR project, the te am made major strides in moving towards creating and efficiently evaluati ng a wide range of network arch itectures and models to support analysis of them. A new optical component mo deling library, LION (Library for Integrated Optical Networks) was developed as a primar y tool for evaluating and comparing various architecture and protocol designs [2]. The work established the feasibility to develop a candidate architecture solution in the Phase 2 that addre sses the challenging and uni que requirements of the military and commercial avionic networks. STTR Phase 2 Objective and Findings Phase 2 of the STTR project was undertak en by the Wi reless And Mobile Systems Laboratory at the University of Florida and RS oft Design Group, Inc. It builds upon the results of

PAGE 20

20 Phase 1 and has worked towards a unified architec ture with promising control and data protocols for WDM LANs [3]. The research group at University of California at Santa Barbara (UCSB), whose work include analysis of legacy, new, and emerging device technologies, supports the architecture and protocol desi gn by leading the down-select of the most promising suite of optical node devices. The key objective of the current work includes: Define network node requirements to implement an optimized open systems aerospace WDM network standard Perform a network control a nd data protocol analysis Experiment and evaluate of system architecture taxonomy Perform fault tolerance analysis usin g in-depth modeling and simulations Validation of the developed simulation models through a small scale test bed that models the necessary network controll ers and the proposed protocols Accomplishments in the Phase 2 include Creation of a two-tiered XYTAR P architecture that satisf ies the needs and requirements of the avionics environment. Extension of the LION library designed in phase 1encoded in Artifex environment as DRAGON (Design of Reliable Avionic Generic Optical Networks), with extended list of optical components modeled and refined according to the trends in curr ent optical research. The Quality of Service (QoS) needs of the various communication types aboard the aircraft were identified and data traffic between sub-systems was prioritized accordingly during simulations. Numerous test scenarios were developed and simulated to demonstrate the reliability and fault tolerance of the networ k under various harsh conditions. The test bed experiments were us ed to prove the feasibility of the designed architecture and protocol details and also exhi bited the scalability and flex ibility of the down-selected WDM LAN architecture. Study Overview The rema inder of thesis is organized as fo llows. Chapter 2 elucidates the efforts in constructing our optical component model library in Artifex, including e nhancements made from

PAGE 21

21 previous optical component models. In Chapter 3, the candidate architecture selected for avionic WDM LANs is explained. The need for prioritizing the data tr affic, wavelength assignment strategies and the proposed routi ng protocols are descri bed in Chapter 4. The architectures fault detection and isolation performance is analyzed in Chapter 5. The experimental configurations to test the candidate architecture, proposed protocols and fault tolera nce are presented in Chapter 6. Finally in Chapter 7 conclusion and achieveme nts of Phase 2 of the project are provided.

PAGE 22

22 CHAPTER 2 OPTICAL COMPONENTS MODELING For accurate modeling of optical network beha vior and obtaining m ore realistic simulation results, the physical layer feat ures of optical components need to be captured for innovative network architecture simulation. In the current phase of Avionics WDM LAN project, LION is redesigned in Artifex simulation environment as DRAGON and several new optical components are appended into the extensive library and the underlying structure has been improved to perform more accurate and flexible simulations [4]. Here the detailed physical modeling needed for the physical design and characterization of individual devices (commonly referred to as TCAD in electronic design automation, or device-level tools in photonic design automation) is not considered, but rather the needs for networ k simulation is given priority. Simulations for network design typically cover the physical layer, data link layer, and network layer of the OSI reference model. Artifex Simulation Environment Discrete-event network simulation can be used to model the lo gical and dynamic behavior of networks and systems running various protoc ols. Network simulation typically focuses on layers above the physical layer su ch as the data link and network layers of the OSI reference model. For example, data traffic, protocol s, and protection switchi ng may be modeled using discrete event network simulation, as well as ap plications such as HTTP. Discrete-event network simulation can be used to validate a network architecture design including its management, control, and protocols. Artifex is a Petri Net based discrete event simulator that supports the design and validation of networ k architectures, protocols and policies. Petri Nets are an efficient, visual approach to model the dynamic behavior of queues and protocols, and are translated into a language suitable for simulation. This approach allows

PAGE 23

23 validation at each design step, ensuring that fu rther modeling is always made on sound grounds. The Extended Petri Nets formalism is object-based and allows hierarchical design. It naturally addresses the issue of scaling the complexity of switches and routers as well as end-to-end network protocols. The basic Petri Nets formalis m consists of a very small set of symbols and concepts such as parallelism a nd synchronization are expressed with a few icons. Petri Nets are defined in terms of three symbols: Place (may be represented by a circle) to model states, conditions, events and queues Transition (may be represented by a rectangle) to model state transitions and activities Arc (may be represented by oriented lines) to define cause/eff ect relationships by connecting places and transitions. Arcs going from Places to a Transition define the Transition's input Places; whereas Arcs going from a Transition to Places define the Transition's output Places. A Place is often an input to a Transition and an output from other Transitions at the same time. Figure 2-1. A simple Petri-net Current states (i.e. true condi tions or occurring events) are represented by drawing a dot within a suitable Place. Such a dot is called a token. Petri Nets evolve by moving tokens from an initial state defined by a set of initial toke ns until no more tokens can be moved according to the following simple rule: When all the input Pl aces of a Transition contain at least one token the Transition can fire. The effect of a Transition firing is to remove tokens from some Places

PAGE 24

24 and to create tokens in some other Places. When a Transition fires, it fetches one token from each of its input Places and rel eases a new token in each of its output Places. Figure 2-1 exemplifies Artifexs Petri Net based simulation environment. Artifex can literally track each and every ev ent in a complex event-driven system and includes a simple but powerful graphical layout of equipment and networks dynamic behavior. A debugger and a report generato r facilitate the m odel deployment and project tracking respectively, and an integrated module for pre-ca lculated or user defined metrics measurements allows system performance assessment. Extensi ons of the language-based on place and transition constructsinclude the capabil ity to embed C/C++ code into the model and to represent the concept of object classes and instances [5]. Modeling Delay Factors in DRAGON While mode ling the optical components as a pa rt of DRAGON in Ar tifex, considering the varied delays introduced by the components holds bearing on the effect on network throughput and ultimate performance. Unlike in traditional electrically-based computer networks where the physical layer effects can be easily modeled, the delay effects requir e attention in order to obtain an accurate system model. The modeled delays in clude propagation delay in optical fiber, tuning delay induced by tunable lasers, detectors a nd wavelength converters, and switching delay incorporated by dynamic optical switches. Howe ver, the true processing delays are not considered during simulation setups as the curren t goal is simply to develop a virtual prototype that mimics the avionic WDM LAN network performance. Modeling Signal Degradation and Noise Effects in DRAGON To accurately represent a system and reduce the design margin, the modeling environment has to consider the optical sign al degradation and noise effects introduced as the modulated data bearing optical signals pass through various component s. This may be of particular interest in

PAGE 25

25 systems with significant amplified spontaneous emission (ASE) noise, nonlinearities, and multimode effects such as differential modal de lay, differential modal attenuation, modal noise, etc. By using detailed physical device models and simulating actual time-domain waveforms, a simulation tool can be used to perform a comprehensive analysis of an optical link starting from the transmitted electrical waveform and ending with the received optical eye diagram and BER curves vs. received optical power or other simulation parameters Simulation results such as the output signal waveform signal to noise ratio, ey e diagrams, and signal spectra can be analyzed between the transmitter a nd receiver to evaluate signal degr adations throughout the link. The results of system-level simulations can also be used as input into netw ork-level simulations and network-level metrics. System-level model parameters contribute to the network-level performance metrics. Modeling Continuous Events in a Discrete Event Environment Discrete event simulators have proven wort hy in network dom ain, but when it comes to modeling optical signals that ar e continuous by nature, it calls for some challenging modeling solution. This is mainly because discrete events cannot capture accurately th e behavior of various components and systems. The prime interest in designing DRAGON library is to simulate optimized network architecture a nd routing protocol, and also to test the performance under a few distinct and vital scenarios. Artifex visua lizes the operations as tokens being passed in response to state transitions, in a discrete sense and this basic idea is used to model the optical signal propagation between and through the vari ous optical components in DRAGON library. For the above mentioned reason, DRAGON is designe d to operate at pack et level and so the models function based on the key even ts in the lifetime of a packet. To bridge the gap between continuous domain optical signals and discrete simulation environment, a head and tail token is utilized to characterize a data packet in DRAGON. For

PAGE 26

26 example, if a traffic generator generates a data p acket it first creates a head token for the packet and then creates a tail token for the same after some delay depending on the size and data rate of the packet. The optical components are equipped with a table that tracks th e current token of the packet being operated upon. This way of m odeling packets and optical signals in DRAGON provides flexibility in processing data and also helps in detecting packet collision within the fiber if any. Whenever a packet enters an optical fibe r, the tokens entry time will be recorded in a table and its head will be compared with all tail tokens of previous packets recorded in that table in terms of event time. If the head time is la ter than any tail time of previous packets, both packets will be marked as corrupted packets and receiver will eventually know which packet is corrupted due to collision and fu rther protocol action might be tr iggered as well. Upon exit from the component the tokens are removed from the table. DRAGON Library Optical Fiber Optical fibers are glass or plastic fibers that as part of a network serve to guide light along its length with little attenuation when compared to electric cables. W hen a modulated light wave enters the fiber, the corresponding h ead token is recorded in the fi bers table and after appropriate propagation delay of the fiber the head token exits the fiber. Depending on the length of the data packet, the tail token arrives afte r appropriate time inte rval and updates the fi ber table with an entry. After undergoing necessary physical paramete r changes and collision detection within the fiber model shown in Figure 2-2, the tail token is pumped out of the fiber. Various parameters and characteristics that include input optical power, loss, attenuation, noise figure, power consumption, transmission speed, etc. are used to define the physical beha vior and operation of the components modeled in DRAGON.

PAGE 27

27 Figure 2-2. Optical fiber model in DRAGON library Optical Transmitters Modern fi ber-optic communication systems generally include an optical transmitter to convert an electrical signal into an optical signal and to se nd into the optical fiber. The functioning of the optical transmitter is charact erized by parameters like transmission rate, wavelength, optical power, relative-intensity noise (RIN) and extinc tion ratio. The most commonly used optical transmitter is a fixed opti cal laser. The fixed laser model as shown in Figure 2-3 takes the raw data pack et generated as an input and ge nerates their respective head and tail tokens. The first transition takes the model parameter inputs and creates the necessary signal level information of the tokens. The t okens are then passed to their corresponding transitions with required time delay to represent the start and end point of the generated optical signal.

PAGE 28

28 Figure 2-3. Fixed laser m odel in DRAGON library A significant addition to WDM based networks is the tunable laser where the wavelength of operation can be altered in a c ontrolled manner. An extra input to the model as in Figure 2-4 is the wavelength indicator that determines the cu rrent wavelength of operation. The tunable laser has an extra parameter for tuning delay that in corporates the delay in curred in tuning to a particular wavelength. Figure 2-4. Tunable laser model in DRAGON library

PAGE 29

29 Optical Detectors The optical receiver or the photodetector convert s the incident optical power back to th e original electric current. The parameters that determine the functioning of photodetector includes detector responsivity, spectral resp onse range, response time, and noi se characteristics. The fixed detector model is depicted in Figure 2-5 and as one could observe the detector waits for the head token of the packet in the appr opriate wavelength. Both the head and tail token carry the same signal level information as they represent the same packet and so the head token is discarded and the detector waits for its corres ponding tail token. Later the tail tokens information is used to evaluate the optical signal received in terms of signal to noise ratio and bit error rate (BER). A raw data packet is constructed with the availabl e information and is sent to the upper layers. The tunable detector model is very similar in functioni ng as stated above with the addition of an extra wavelength indicator and tuning time transition. Figure 2-5. Fixed photo detect or model in DRAGON library Optical Amplifier An optical amplifier is a devi ce that amplifies the optical si gnal directly without even changing it to the electric domain, meaning th e light itself is amplified. This is the basic

PAGE 30

30 difference of operation with a repeater, which work s in electrical domain and thus subjective to failure. Based on the above description the amplifie r is modeled as in Figure 2-6, where the input power level of the token is boos ted according to the amplifier gain parameter. Spontaneous emission factor (nsp) models the addi tional noise induced by the amplifier. Figure 2-6. Optical amplifier model in DRAGON library Coupler and Splitter In an optical network there exists ma ny a situ ation where it is necessary to combine signals and/or to split them multiple ways. The coupler and splitter that perf orm such actions are common in use either in symmetr ic or asymmetric forms. 1x2, 2x2, and 2x1 coupler/splitters are commercially available as they are believed to ha ve very low loss associated with it. There are three important characteristics wh en discussing most optical devi ces but couplers in particular. These include: Return Loss: Most optical devices reflect part of signal back down the input fiber and this might amount to either some part or most of the signal. The amount of power that is reflected and thus eventually lo st is termed the return loss. Insertion Loss: Its just the amount of si gnal lost in total tr ansit through the device including any couplings to fibers etc. Excess Loss: This is just the measure of practical manufacture versus theory. It accounts for any additional loss of a device and above th e one required by theory. This exists as all the realistic devices are less than perfect.

PAGE 31

31 Figure 2-7. Symmetric 2x1 Coupler model in DRAGON library Figure 2-7 shows the model of a symmetric coupler where packets from two input ports are coupled with the same insertion loss. The design of an asymmetric coupler is the same except that an extra parameter decides the difference of insertion loss between the two inputs. The splitter model is the same but it splits the input signal among the output ports instead. Optical Filter Figure 2-8. Optical filter model in DRAGON library Earlier optical networks seldom used the filters and if used was primarily in front of an LED to narrow the line width before transmissio n. But current WDM based networks uses filters in front of incoherent receiv ers to select a particular signal wavelength from many arriving

PAGE 32

32 signals. Filters are also employed to control the path of optical signals through a network. There are many filtering principles proposed and tunable filters available for WD M networks. The filter modeled for the current need is shown in Figure 2-8 and can perform as both band pass and band stop filter according the parame ter setup. If the input signal to kens wavelength is out of the filters pass band, its filtered out by simply discarding the corresponding tokens. Optical Switch Figure 2-9. Dynamic optical swit ch model in DRAGON library In almost any optical network where communication channels are routed or switched within nodes along the path, one would require a way of switching a single channel from one path to another. Fortunately to control the light intensity along a particular path, quite efficient optical switches are available these days. The optical switch modeled in DRAGON library is a semiconductor optical amplifier (SOA) switch an d shown in Figure 2-9. The switchs cross or bar state of operation is determined by the turn ing on and off the SOAs used. Each SOA used adds additional noise to the si gnal along with a minimal switching delay. The modeled switch is dynamic in nature and allows the switching logic to be controlled easily through control signals.

PAGE 33

33 Optical Add/Drop Multiplexer Figure 2-10. Optical Add-Dr op Multiplexer function An add-drop multiplexer adds and/or rem oves a single channel from a combined WDM signal without interfering with other channels with in the fiber and this functionality is shown in Figure 2-10. There are several devices wh ich may perform this function such as: Array waveguide gratings Circulators with In-F iber Bragg Gratings Cascaded Mach-Zehnder Interferometric filters Figure 2-11. Dynamic OADM model in DRAGON library Optical add/drop multiplexer modeled is functional combination of one wavelength multiplexer, an array of dynamic 2X2 optical switches and one wavelength demultiplexer and

PAGE 34

34 shown in Figure 2-11. The 16 input control ports can change the 16 2X2 optical switch logics dynamically. According to particular configurat ion, OADM can add local traffic in specific wavelengths and simultaneously drop global traffic in the same wavelengths. Summary Once the DRAGON library models were design ed, we have the building block for WDM LAN architecture s imulations. Various architecture and routing protocols designed as a part of the phase II of the project where built on these optical compon ent models. The next chapter elaborates on the different architectures suitable for the current WDM LAN application and details the down selected Mesh-Torus architecture.

PAGE 35

35 CHAPTER 3 AVIONIC WDM LAN ARCHITECTURES The approach for building a lightwave network is critically dependent on the requirements of the network and the environment in which it must operate. There ar e a number of different environments for which lightwave networks l ook promising but the technical design for one environment can be very different from that for another. Simulation and modeling can be used to aid in the definition of the architecture for a ta rget optical network by quantitatively evaluating candidate architectures acco rding to key metrics. One of the primary aspect of a network ar chitecture that needs to be evaluated and determined to be the optimal choice to depl oy as a standard is how the network nodes are interconnected. The cable plant inst alled in the aircraft during initial construction may never be replaced during the life of the ai rcraft due to prohibitive costs. Without a detailed analysis through virtual prototyping, the optimal choice for WDM LAN ar chitecture cannot be made. Initially the possible network architecture pa radigms include point-to-point, ring, bus, star, and optical tree. Each is disc ussed in the following section. Based on these observations, the topologies that were down select ed for the Phase II of STTR project here at UF are elaborated and their selection is also justified. Primary Network Topologies Point to-Point The point-topoint architecture is characterized by each node connecting directly with all the nodes that it wishes to communicate with. Typically, one node in each link connects with only one other node. An example would be a sensor or actuator connecting with a processor. The processor may also have point-to-point connections with other sensors, actuators, processors, or I/O devices. Hist orically, this has been the primar y architecture deployed for fiber

PAGE 36

36 optic communications in aircraft, and is the only architecture for fiber optic communications to date that has been proven in actual deployed systems on aircraft. Ring/ Hub-Based Rings The ring topo logies are attractive because they are self healing in nature, that is, a break in the ring can be automatically bypassed by ro uting a backup path in the opposite direction around the ring. The predominant method of us ing an optical ring is through Add/Drop Multiplexers. Such a topology can be visuali zed as connected through a hub or ring wiring concentrator as illustrated in Figure 3-1. Th e advantages of such network topologies are: Breaks in ring can be quickly bypa ssed by jumpering at the hub. Ease of network re-configurati on again by jumpering at the hub. The passive hub can be used to monitor and control access security, etc. Figure 3-1. Hub-based ring topology Bus A folded bus system is illustrated in Figure 3-2. Transm itting stations are connected to the same optical fiber bus and appropriate protoc ol allows the nodes to transmit on different wavelengths and share the bus wit hout interference. These will work, but even the smallest LAN

PAGE 37

37 will require amplifiers to boost the signal at freq uent intervals down the bus. The problem is that as the fiber is tapped for power at each stati on a fixed proportion of si gnal power is removed by the station. The same can be thought of in the us e of Y-coupler or resonant coupler to combine the signals. The bus architectur e has been utilized in electr onics-based comm unications (e.g., copper-based interconnections in computer systems and networ ks, Ethernet, ARINC 429, MILSTD-1553, etc.) for many years. An equivalent fiber-optic bus standard is AS1773. Figure 3-2. Folded Bus topology Star The star topology has been used in several experim ental systems because they can support many more stations without amplification than bu s networks. As shown in Figure 3-3, separate fibers are connected from each station to the star coupler. A feature of the technology is that the star is a passive device, a charac teristic considered very importa nt for reliability. The star is really a combiner followed by a splitter that ta kes the incoming signal and broadcasts it to all nodes connected to the star. The Fiber Channel sta ndard is an example of a star architecture. Another example is the central office of a telephone or CATV system as the star coupler and each homes telephone or cable box as the terminal node.

PAGE 38

38 Figure 3-3. Star topology Optical Tree In general a numb er of couplers or stars can be interconnected such that anything sent by one station will be received by a ll stations. This can be very effective in a distributed topology where a number of hubs interconnect a few stati ons each and are connected together to form a larger LAN structure as illustrated in Figure 3-4. As expected there are a few problems: Relative signal strength of different transmitti ng stations will be very different at the receiver. Some access protocols rely on transmitting statio ns to receive its own signal in order to detect collisions. But collision detection beco mes difficult if the colliding place is a long way away in the network. There cant be any loops in the structure. If multiple paths exist between stations the signal will go in all paths and has a high probability of collision with itself and pose as garbage.

PAGE 39

39 Figure 3-4. Optical Tree configuration Phase II WDM LAN Architecture Modeling The me rits and demerits of the preliminary network topologies discussed in the previous section were done analytically and also via m odeling. The inputs from Phase I of the project regarding the various architect ures available for evaluation proved vital in choosing the appropriate candidate architectur e for the avionic requirements. While deciding the apt backbone topology for the current application, resource ma nagement, routing and fault tolerance were considered as primary inputs. Tw o architectures were evaluated a nd designed as a part of Phase II of the project and includes: Ring-Hybrid architecture Mesh-Torus architecture The design issues of both these architectures are handled in the fl owing section. Modeling and simulation can be used to confirm that, netw ork architecture meets accep tance criteria before physical prototypes are built. Acceptance crite ria are typically based upon whether or not

PAGE 40

40 architecture meets the requirements. The potential of DRAGON library is established here as the network topologies are built above the optical component models and compared. The remainder of this section is spent in detailing each of the network architectures, in cluding both physical and network level descriptions. Ring-Hybrid Architecture The ring-ring architecture proposed in [6] and illustrated in Figure 3-5 is based on the ROBUS network discussed in [1]. It consists of a global ring, where each controller is assigned a WDM wavelength at which it can receive incomi ng packets, and a collection of local rings, where the nodes are assigned WDM wavelengths which can be reused within other local rings. Thus, the end nodes are each equipped with a tuna ble laser transmitter and an optical detector and it is a large variation from the ROBUS desi gn, where only one node on each ring contained a laser. Figure 3-5. Ring-ring architecture The proposed Ring-Hybrid architecture is an im proved version of the previously explained ring-ring architecture with more emphasis on functional grouping of access networks and prioritization of traffic from sub-systems. Its a two-tiered architecture with the controller nodes connected in the first tier via a ring like backbone network as illustrated in Figure 3-6. The black

PAGE 41

41 colored ovals represent the fiber optic links that connect the nodes. The fiber optic links shown represent a bi-directional ring by using two redun dant fibers running in the opposite directions [7]. Figure 3-6. Ring-hybrid architecture The actual data traffic generating nodes are pr esent in the second tie r of the architecure connected usually in a ring like a ccess network. The presence of va ried sub-system is leveraged in the second tier by functionally grouped access ne tworks. The advantages offered by a electric network in terms of buffering and packet switching along with the proven abilities of optical networks, a hybrid architecture is created. Such a hybrid network, lets the electric nework do what it does best, and at the same time utilizes the optical technologies ad vantages. As seen in Figure 3-6 a data delivery subsystem is modeled to support electric lines to the main controller. It must be evident by now that the controller nodes are just used to route and forward packets rather than actually gene rating any actual data traffic. The internal structure of such nodes are pretty much straight forward, as they are equipped with a coupl er/splitter combination and an optical filter. Each controller node taps some amount of power from the optical signal to read its intended data and route it to the corres ponding second tier nodes. The function of a filter is to remove the data packets from the ring af ter it had travelled a ll the way round the ring.

PAGE 42

42 The wavelength allocation stratgey and rou ting protocols of the ring-hybrid topology is handled in detail in the following chapter on re source allocation. The ring-hybrid architecture is designed to be fault tolerant and the redundancy is directly dependent on the number of redundant rings deployed. The three poi nt fault tolerance is one of the main requirements for an avionic WDM LAN architecture and this particular ar chitecture fails to meet this when the faults are localized in nature. This architecture was the motivation for a more reliable and scalable torus architecture which is proposed as th e WDM LAN architecture to suit the avionic applications. Mesh-Torus Architecture A contribution of the thesis is to propose a novel optoelectroni c architecture that resembles a torus and is an extended and ameliorated ve rsion of the previously proposed Ring-hybrid architecture. This is the architecture that was chos en for the avionics environment. It is an alloptical architecture that provi des excellent connectivity, and low latency. The proposed meshtorus is capable of achieving thes e features by exploiting several optical technology features that enable: Ample communication bandwidth by aggressively utilizing WDM and possibly TDM. High connectivity thereby reducing the netw ork diameter resulting in lower queuingrouting delays for packet transmission. Scalable bandwidth and cost that grows linearly with the number of nodes while providing low latency. Protocol independence of the architecture and it s inherent ability to tolerate multiple faults The proposed architecture not only encapsula tes the key features of the Ring-hybrid architecture, but also incorporate fault toleran ce and dynamic re-configurabi lity features that are indispensible for the current application. The follow ing section elaborates the required details of

PAGE 43

43 the architecture by first c onsidering the structure of first tier controller nodes and then the twotiered architecture is delt in detial. Controller Node Denotation The me sh-torus architecture has a torus topology in the first tier to support the controller nodes and these nodes are responsible for making r outing and fault tolerance decisions. The torus topology in the first tier and also the reliability requirement n ecessitates a controller structure with four transmission/reception ports [8]. Such a controller node structure is illustrated in Figure 3-7. The controller is connected to two bi-directio nal optical fibers running in the East-West and North-South direction and thus forming the four ports. The importance of this structure can be better explained when the fault to lerance protocol is discussed. Figure 3-7. Torus controller node denotation WDM LAN Backbone Topology As stated earlier, two-tiered me sh-torus architecture is proposed for the WDM avionic network and contains the controller nodes in the fi rst tier. The first tier is the backbone network that is designated to carry cross-aircraft tra ffic between the functionally different sub-systems. Figure 3-8 shows an example of the backbone torus architecture where, 16 controllers are arrayed in a 4x4 two dimensional topology and connected via optical fibers to form an interconnected ring like network. Th at is, each controller is c onnected to two bi-directional optical rings through its four port node structure. One fiber ring c onnects all the controllers in the North South West East

PAGE 44

44 horizontal direction and the other optical ring conn ects the controllers in the vertical direction. The torus architecture with 4 nearest neighbor co nnections is chosen because a high degree of fault tolerance and redundancy is required. The numbers within the controllers in Figure 3-8 denote the controller nu mber for convenience. Figure 3-8. A 4x4 Mesh-Torus architectur e (1st Tier backbone network) The SAE requirement for the number of nodes is 256 nodes maximum and this number of nodes is assumed to be supported through 16 contro ller nodes. The benefits of proposed torus network can be realized if the backbone network is assumed to be a square network, with equal number of controller nodes in each optical ring. Based on this assumption each controller node represents a particular sub-syst em in an aircraft and can contain upto 16 individual nodes that generate data. The second tier topology is explained in the following section. WDM LAN Sub-System Topology The second tier contains the actual data genera ting nodes of the sub-systems of the aircraft and is able to m aintain a topology that is inde pendent of the backbone to rus architecture. Each subsystem contains at least one node that is a controller and thus is a part of the first tier/backbone network. The second tier architecture can be connected to the first tier torus using either electrical or optical cables depending on the specific applicati on. From the detailed

PAGE 45

45 observation and analysis of the primary topologies available fo r the avionic networks, and its requirements, a star-ring topology with a semi-torus interconnection to the first tier controllers is proposed. Figure 3-9. Second tier Star-Ring topology The nodes in the sub-system level are also assu med to be equipped with four ports to form a star-ring topology. All the nodes are connect ed to two of its neighbors through two unidirectional optical fiber rings as shown in Figure 3-9 and each node is connected to its corresponding sub-system controll er in a star like topology with two fiber links running in opposite direction. The optical rings are used fo r intra-subsystem communi cation and one ring is redundant and reserved to serve du ring fiber link failures. The star topology can be used for both intraand inter-subsystem communications depending on the priority of packet being transmitted. All the data generate d by the nodes are routed through the controller in the backbone network.

PAGE 46

46 Four nodes from each sub-system is designated a special fault tolerant routing property and are termed as the outlet nodes. The second ti er nodes are grouped based on their physical position or functionality to four groups with one outlet node in each group. This particular outlet node becomes responsible for fault recovery mechanism within its sub-group. The outlet nodes apart from being connected to its own sub-sy stem, connects to four other neighboring subsystems outlet nodes as depicted in Figure 3-10. Here, the controller nodes are represented as circles with their controller numbers embedded within them and the four outlet nodes for each controller is shown to be in terconnected with neighboring outlet nodes in a semi-torus interconnection. This interconnec tion between the sub-system ou tlet nodes forms a semi-torus like topology and its merits can be leveraged in a faulty scenario. Figure 3-10. Semi-torus interconnection of the second tier node s through outlet nodes

PAGE 47

47 Summary In deciding an optimal candidate WDM LAN ar chitecture for avionic applications, the research began with a few prim ary topologies as explained above and the research done during Phase I of the project threw some light on the ad vantages of hybrid architecture. This paved way for a more detailed analysis of two hybrid architectures, the ring-hybrid and mesh-torus architectures. The inherent benefits of the mesh-t orus architecture though a lluded in this chapter, are demonstrated concretely in the modeling simu lation analysis and results chapter. The next chapter explains the necessary resource management access control and reliability issues of this architecture.

PAGE 48

48 CHAPTER 4 RESOURCE MANAGEMENT AND ACCESS CONTROL PROTOC OLS FOR WDM LANS Consider a scenario in which a number of st ations are connected to a common medium and two of them request to communicate with each other, and all that is to be done is to select a mutually agreed wavelength channel/s for th em to use and communication is made possible immediately (provided no other sta tions is using the selected channe l/s). In simple case, we could allocate a channel to a group of devices with a pencil and paper-by system definition, but this also implies that devices can use the nominated ch annel/s all the time and they will be unable to communicate with other stations on the network. But the main objective here in terms of resource management and access control is crea ting a WDM LAN lightwave network to provide practically any-to-any connectivity for all the at tached stations. Such networks can operate on two bases: Traditional LAN like networks with individual data units being handled in a block-byblock basis. Virtual circuit approach with stations contending for channel for a period of time, perhaps for a few seconds or milliseconds. Both the approach stated above has its own merits and limitations. A connectionless traditional LAN approach eventually has the same delay for all the packets being pumped out of the transmitter. Most WDM access protocols require either transmitters or receivers (or both) to tune to a particular channel before data transfer can take place. This can take a significant length of time compared with the transmit time for a single block. A virtual circuit approach can tolerate a relatively long delay in circuit establishment but offers instant access for data blocks after the first. When station A wants to send data to station B then they have to find a vacant channel and both tune to it before station A can comme nce sending. The central problem for the access

PAGE 49

49 protocol is: How do we arrange for stations wanting to communi cate to use the same channel (wavelength)? First, the stati ons must have some ability to vary their operating wavelength (switch from channel to channel) The various possibilities include: Each station allocated to a fixed transmitting cha nnel and all stations are able to tune their receivers to any channel at will. Each station could be allocated a fixed receiving frequency and a tunable transmitter. Both transmitter and receiver could be tunable. Stations could have multiple (say two or three) receivers and/or transmitters. This invokes the case of an array of transmitter/receivers. The case of using a tunable receiver and fixed transmitter is often termed as broadcast and select principle and faces two basic issues The tuning time of receiver and its tuning wavelength is unknown and also faces a receiver co llision problem. But the inherent advantage of using a tunable receiver-fixed transmitter combinat ion is that it permits for a broadcast ability if all the receivers are tuned to the same wave length channel. A somewhat same problem exists with the fixed receiver-tunable transmitter case, wh en two or more stations transmit to the same destination at the same time resulting in packet collision. The possibility of both transmitter and receiver being tunable is by far the best from a usage efficiency point of view. This is because we can potentially have many more stations than channels and all stations conte nd for the same pool of capacity. But in this configuration, now both stations must have a mechanism for deciding which channel they access or use and there is also a possibility of blocking and this adds comp lexity in the system protocols to handle such situations. An access protocol is the mechanism used to determine just which wavelength channel should be used by each new connection. Access prot ocols mainly depend on either a centralized controller, or a separate cont rol channel for contention, or a dynamic wavelength allocation

PAGE 50

50 strategy. In the following sections the need for priori tization of traffic is explained, followed by a detailed explanation on the wavelength assi gnment strategy and routing protocols for the prioritized traffic. Traffic Prioritization In any network with heterogeneous traffic generat ors, traffic prioriti zation is of primary importance in order to meet the required Quality of Service (QoS). For ex ample, the Internet has such varied traffic flowing thr ough it that a lot of research is being done in identifying and classifying the needs for different tr affic types. A nave way is to cla ssify all data as real time or non-real time. Real time traffic consists of streaming voice and video while non-real time traffic may consist of many other different data types (like web browsing, e-mail etc). But this way of classifying data into just two types might not be sufficient in or der to maintain the various QoS parameters within the desired range. A lot of resear ch has been carried out in order to identify the maximum tolerable delay and other parameters for different applications using the Internet and various priority levels are then assigned to the packets depending on its type, source or destination. The different subsystems on-board an aircraft al so generate heterogeneous traffic similar to the Internet. The requirements of one subsystem might be totally different from another. The traffic generated by one subsystem might be totally different from another. In order to provide the best possible service to the different subsys tems it is necessary to carefully analyze the requirements of the subsystem (QoS) and also the traffic pattern of the different subsystems. To justify this, lets consider two different military platforms and analyze the functionality of the sub-systems present in them. The first chosen pl atform is a Lockheed Martin P-3C Orion and it includes:

PAGE 51

51 High traffic sub-systems: These include sub-sy stems such as the cockpit that receive high volume of data from multiple sources, possibly at simultaneous time instants. These require to be modeled using an array of recei vers with dedicated wavelengths for multiple simultaneous receptions. General sub-systems: The fuel tank sensors and weapon control nodes at the wing stations that communicate with the cockpit as well as with the operator stations in their local area fall under this category. These sub-systems experi ence a variability of traffic patterns. For example, a burst of traffic may be generate d by an operator station that must download missile destination data onto a missile in a pa rticular wing station a nd subsequently fire. Specially inter-connected subsystems: Specially connected subsystems, such as the wingto-wing link, must share or maintain equivalent data at two different locations. For example, the angle sensors on the port side n eed to be in the exact same position as the starboard side, despite the fact that they are being exposed to different and varying environments. The wings maintain equivalent positioning by constantly transmitting their positions back and forth from one wing to the other. This means that very little delay is acceptable. Data delivery subsystems: The data de livery subsystems transmit data packets continuously to the controllers and require only one-way data communication. Examples include the Sonobouy Reference System (SRS), wh ich wirelessly receives the locations of all deployed sonobuoys from the buoys. The optical network needs to tr ansfer this high bandwidth data quickly and continuously with little delay to the operators onboard for data processing. On the other hand the F-22 raptor platform is a centralized architecture, where the data acquired from sensors and other ac tuators are aggregated and processed at the cockpit or the core processing units. The military configuration includes two core processing units, and other 6 subsystems that include electronic warfare, stores management, radar, controls and displays, communications/navigation/iden tification, and engine contro ls. These seven subsystems inclusive of the cockpit, cont ributes to a total of 97 nodes and is capable of generating 200 megabits of traffic per second. From the observation made on the two military configurations, one could easily understand the importance and necessity for traffic prioriti zation between different sub-systems and then evaluating a suitable wavelength allocation strategy and routing protocol for the different

PAGE 52

52 priorities of traffic. After an analysis of the different possible subsystems and the type of data they generate, a three level prioritizat ion scheme is finalized and includes: High Priority Medium Priority Low Priority High Priority Traffic (HP) An estimate of 7 high priority data generating sou rce-destination sub-system pairs has been made and these are supposed to carry mission and time critical in formation between the systems. The high priority traffic requires minimum waiting and transmission de lay, i.e. as the data packet traverses along the fiber lightpath minimum or practically no O-EO (optical to electrical to optical) conversion delay and queuing delay is targeted. These requirement calls for dedicated wavelength and pre-configured lightpath to be setup for each connect ion. The importance of information being carried also requires better fa ult tolerant routing protocols with less jitter. From careful analysis and observation the 7 high priority source-destinatio n sub-system pairs are identified as: Cockpit Wing1 Cockpit Wing2 Cockpit Weapon subsystem1 Cockpit Weapon subsystem2 Cockpit Engine Cockpit Tail Wing1 Wing2 Medium and Low Priority Traffic (MLP) Every sub-system generates its data for transm ission and the priority level of each is raised according to the application. Medium and low prior ity traffic shares the same set of available wavelengths and the medium priority packets are provisioned at the cost low priority packets. The medium and low priority wavelength a ssignment and routing protocols for XYTARP

PAGE 53

53 architecture is handled in the flow ing sections. It is assumed that the traffic entering the first tier controllers from the various subsystems is already classified as high, medium and low priority traffic. In fact, several sourcedestination pairs can be designated a priori as high priority connections. Yet, controllers in high priority connections can also generate both medium and low priority traffic according to their needs. The difference between the priorities of traffic is observed only in the way their data packets are serviced. Since the network should be able to suppor t 256 nodes, we assume that there are 16 controllers with 16 nodes under each controller. Hence, we can s ee that there is around 45% of high priority traffic and 55% of low and medium priority traffics. The following sections will throw light on the wavelength assignment strategy and access protocols for the HP and MLP traffic separately. The path setup procedure for HP traffic in the backbone network and the two access protocols designed for the MLP traffic are also described. Later the second tier or the access networks wavelength assignment and routing are explained separately. High Priority Wavelength Assignment and Routing Wavelength Assignment Since high-priority traffic is always carrying critical data, there mu st be a mechanism to protect them from being lost in case of system faults. Multiple duplicated traffic paths may be setup in the initial stage to tolerate one or several path failures. So a decision choice has been made, that allows four dedicated lightpaths to be setup for each source-destination pair. This requires individual wavelengths to be assigned for each pair prior at the start up phase of network. So out of the 32 wavelengths assumed to be available all over the WDM optical network, 7 wavelengths are dedicat ed for the high priority traffic alone and cannot be reused anywhere by the MLP traffic. More details are added on the lightpath establishment and routing for HP is discussed in the following section.

PAGE 54

54 Lightpath Establishment and Routing As stated earlier, each HP source-destina tion pair is assigned a unique wavelength for communication and so the next step is to esta blish lightpaths between them. The proposed m eshtorus architecture controllers have four ports and torus b ackbone network, which favors transmitting the HP packets along four distinct pa ths and be reached at the receiving end through its four ports. Careful planning of these distinct lightpaths ensures zero collision and also better fault tolerance properties. To be more precise, if the four lightpaths between a pair of HP subsystem are chosen in such a way that they never ov erlap with each other, then in case of a fault in one particular lightpath, the other paths provi de necessary redundancy. Such lightpath setup phase has to consider two cases based on the location and the way in which the sub-system controllers are connected in the backbone torus. Case I: Source/Destination sub-system is pa rt of different row/column of the backbone torus network. Case II: Source/Destination sub-system is in the same row/column of the backbone torus network. Case I lightpath establishment Figure 4-1. The HP Lightpath set up with sub-systems in different row/column of backbone torus

PAGE 55

55 The design issue of finding four distinct lightpaths follows the X-Y and Y-X routing mechanism of the MLP traffic, which will be elaborated when discussing the MLP routing issues, but the idea of this is us ed here. The process of setting up the lightpaths in the case of source and destination controllers being in different rows and columns of the backbone torus is illustrated in Figure 4-1. First, two shortest path s between the pair of communicating controllers is established using X-Y and Y-X routing resp ectively. Secondly, two nei ghboring controllers of source S namely S1 and S2 that are not in th e path of the established first two paths are determined. Similar neighbors of destination D namely D1 and D2 are identified. Distinct lightpaths between S1-D1 combination and S2-D 2 combination is found using X-Y or Y-X routing. These contribute to the four distinct lightpaths between the communicating sub-systems and they do not overlap with each other. Such li ghtpaths are setup in the network start up phase and does not require any furthe r contention for wavelength. Case II lightpath establishment Figure 4-2. The HP Lightpath setup with sub-systems in the same row/column of backbone torus The lightpath setup for the second case where the communicating sub-systems is in the same row/column of the backbone torus is almost th e same as the previous case as here also the four port structure of the cont roller and WDM switche d network technology is utilized. First

PAGE 56

56 using two ports in the X ring or Y ring direction, depending on the case of using the same row or column, two shortest paths are established. Second ly similar to Case I, two neighbors of source and destination is identified by one hop via the remaining two ports and lightpaths are established between them. Thus th e four distinct lightpaths are established without any overlap and shown in Figure 4-2 as colored paths. Controller Node Physical Structure Figure 4-3. Controller node physical st ructure to support HP lightpath setup The physical structure of the controller node ha s been detailed earlier to have four ports and apart from this the structure must also s upport the setup of lightpaths for HP traffic during the network startup phase. For this purpose, each node is equipped with an array of 1x3 optical switches that gives the controller the capability to function as a switched network for the HP traffic. The optical switch receives the HP pack et from the demultiplexer of one of the ports and

PAGE 57

57 based on the switching logic forwards the optical p acket in one of the remaining three ports. All the switching logic in th e 16 controllers of the torus is fixe d at startup and remains so throughout the lifetime of the network. So the setup of dis tinct lightpaths requires th e switching logic to be pre-configured and at the receiv ing sub-system a special 1x2 optical switch is used to drop the respective optical packet. The controller node physical structure is shown in Figure 4-3. The XYTARP Medium and Low Priority Wavelength Assignment and Routing Unlike the preset source-to-destination pair de signations for the high prio rity traffic, all controllers in the first tier/bac kbone that are capable of generating both medium and low priority (MLP) traffic have to contend for resources. MLP traffic are more dense than the HP traffic and an effective wavelength assignment and routing protocol becomes th e need for the hour and as a part of Phase II of the project we have come up with two protocol designs. The first protocol depends on a fixed transmitter and an array of receivers for each controller and resembles sort of a broadcast and select mechanism. The second protocol involves tec hnologically advanced tunable transmitter and fixed receiver combination and optical time division multiplexing (OTDM) protocol. The following section deta ils the two protocols for MLP traffic. The MLP Protocol Design I: X-Y Routing The wavelength assignme nt for the MLP traffic is done in a circular fashion to enable the transmission wavelengths to be reused in different rings. Each cont roller node is equipped with a fixed laser and an array of recei versone for each controller in the ring (X direction ring or Y direction ring). Since we allocate 7 wavelengths for high priority traffic, we have 25 remaining wavelengths for medium and low priority traffic to contend for. Figure 4-4 illustrates the circular wavelength reuse strategy, and also proves that for a 16 controller square torus backbone topology, just 4 wavelengths are sufficient. So if a ny controller has data to transmit, it simply pumps out the data in its allotte d wavelength and in the appropriate optical fi ber according to the

PAGE 58

58 routing mechanism. This could be thought of as a broadcast and select ty pe of transmission as the destined node alone takes the packet that is being transmitted and the other controllers simply discards it. This sort of rou ting also permits for special routing scenarios like broadcast or multicast the data, only with special address fields like all ones or some recognized format. Figure 4-4. Circular wavelength as signment strategy for MLP traffic An X-Y routing protocol is pr oposed as the base routing mechanism for the MLP traffic, i.e. in the absence of faults [9]. The X-Y routing is a three step process. In step 1 the sub-system controller checks if th e incoming packet is destined a node within the same sub-system and if so forwards through the second tier routing mechanism to be explained in the following sections. If step 1 is not satisfied, the controller checks if the packets destination is pa rt of its own X ring or Y ring and is so uses the corresponding port optical laser and its own wavelength to send the data packet out, as a part of step 2. If previous steps fail, then in st ep 3 the packet is forwarded using the X-Y routing scheme.

PAGE 59

59 Figure 4-5. The X-Y base rout ing for backbone MLP traffic Figure 4-5 clearly illustrates the step 3 proce ss, where a packet is routed according to the X-Y routing mechanism. Here the destination is no t part of the same ring as the source in both the X and Y dimension. So the packet is forwarde d along the X direction first to an intermediate node between the source and destination. Here the optical packet is converted from its optical domain down to the electrical domain for reading the packet and buffered. When the intermediate nodes transmission wavelength in Y ring is free, the corres ponding optical packet is created and transmitted to the respective destin ation. Figure 4-5 clearly shows the wavelength assigned for each controller and al so the source (S), the intermediate controller where O-E-O conversion occurs (I), and also the final destination of packet (D). The previously stated X-Y routing protocol drives the name of our proposed reliable architecture as, X-Y routing over a Torus Arch itecture with Redundant Ports (XYTARP). In order to prevent the optical packet from circ ulating the same ring on and on, each controller structure is equipped with an optical filter that filters out its own wavelength signal after one round trip. The routing for intra-ring communi cations is simple and requires no O-E-O conversion delay, as the packets can be directly sent to th e destination when the rings transmitting wavelength is available. For inter-r ing communications the controller follows the

PAGE 60

60 special X-Y routing, which requires an O-E-O dela y, and after which the node sends the packet to the destination via the Y-direction ring, as de scribed earlier. MLP prio rity designation allows for two different queues for medium and low prior ity packets, where medium priority packets are serviced ahead of any low priori ty packets in the transmission queue. The performance of MLP protocol design I is established in Chapter 6 which tests the prot ocol in various scenarios and appropriate metrics are used to characterize the results. The MLP Protocol Design II: OTDM Communication syst ems for use in commerci al aircrafts are becoming increasingly complex and bandwidth intensive to meet the ne eds of multimedia users, as well as perform system management functions. The various avioni cs sub-systems have varied requirements for services that generate a wide range of tr affic patterns. Wavelength Division Multiplexing (WDM) provides a robust way to offer such services but measures have to be taken to make sure that the bandwidth is effectively utilized. Using Optical Time Division Multiplexing (OTDM) with WDM increases the bandwidth usage per wavelength in the WDM system, thereby increasing the effective utiliz ation of the system capacity. Time Division Multiplexing (TDM) is a time-honored technique in electronic communications. There is much interest in TDM fo r optical communications but this interest is for completely different reasons than the reas ons we use in the elec tric domain. SDH and SONET are standards for electronic TDM over an optical carrier. This provides the necessary motivation for using the idea of TD M in optical domain along with the proven advantages of the WDM technology. Precisely speaking, the time slot allocation strategy is used along with the WDM wavelength assignment and routing strate gy to come up with the proposed OTDM/WDM protocol design [10].

PAGE 61

61 Figure 4-6 shows the basic principles of tim e slot and wavelength organization for the OTDM/WDM strategy. Here instead of assigning wavelengths for the transmitter side, we assign fixed receiving wavelength for each sub-system controller. Four wavelengths are allocated to receivers of 4 nodes within a local ring and hen ce 4 simultaneous transmissions can take place. One tunable laser is used at each node to transmit data to different destinations in a round-robin fashion. For instance, when controller node 1 transm its, the laser needs to be first tuned to node 2s wavelength and then to the wavelengths of node 3 and 4, which forms a frame duration for node 1. Similarly nodes 2, 3 and 4 can arrange thei r transmission slots in the same circulated fashion under the constraint that no simultane ous transmissions on the same wavelength are permitted from different nodes. This forms the ba se for first time slot allocation strategy in Figure 4-6 and is termed as OTDM_1 design. The guard time periods between neighboring time slots are used to avoid data co llision induced by propagation delay. Figure 4-6. Time slot allocation st rategies for OTDM/WDM protocol Improvements in time slot organization can be made and have also led to two more time slot allocation strategies. It is observed that there is no need for node 4 and node 3 to wait for a guard period to transmit data to node 2. Node s 4 and 3 are one hop farther away from node 2 than node 1 and node 4 respectively, and hence they can immediately send data without colliding with the transmission in previous time slot on the same wavelengt h. However, node 1 has to wait

PAGE 62

62 for 2-hop propagation delay to allow for the last bit from node 3 to pass by and then start transmitting. So, two of the three guard periods in one frame period can be removed without risk of collision. This forms the improved design OTDM_2 and is shown as the second time slot allocation strategy in Figure 4-6 with guard interval between c onsecutive frame periods instead of being between consecutive time slots. The next improvement shown as the third time sl ot organization in Figure 4-6 is termed as the OTDM_3 design and this is a greedy design. This design is very similar to the OTDM_2 design, and additionally leverages th e length of the used fiber links and speed of operation of the optical components. This advantage permits a sli ght overlap between the time slots in each frame and also using a laser array rather than a tunable laser. The performance for this design is pretty obvious as we tend to use an array of transmitters and it comes very close to the MLP protocol Is performance. So each node according to the current time slot uses the corresponding laser with the destinations re ceiving wavelength, to transmit the data One should understand here that not all the laser can be used at all the times, because we are deali ng with a fixed detector at each controller and so to avoi d collision between transmissions of different nodes, the time slot and frame structure has to be followed. The OTDM/WDM strategy proposed above has the advantage in terms of wavelength utilization as each receiving wavelength is almost filled or tightly scheduled between transmissions from different controllers. The gua rd period between the time slots is the potential trouble in terms of complete wave length utilization, but this is pivotal to avoid any potential collisions. Modified designs for the time slot organization are derived from the assumptions on the fiber link length between the operating cont rollers and also the transmitter laser operation speed. Any variation in the above parameters cal ls for due modifications to be made in both

PAGE 63

63 OTDM_2 and OTDM_3 time slot allocation st rategies. The major advantage in the OTDM/WDM protocol design for ML P traffic is the better scalability that it provides to the backbone torus network architecture. To make the network more scalable, the number of transmitters/receivers used should be independent of the number of contro ller nodes connected in the same ring. The use of tunable transmitter and a fixed receiver per controller node simplifies the node structure and at the same time provi des better scalability as the number of transmitter/receiver per node is always constant here. XYTARP Second Tier Wavelength Assi gnment and Routing Protocol The wavelength assignment issues and the ro uting protocols explained so far are for the backbone torus of the XYTARP WDM LAN archite cture proposed for avionic networks. The actual data generating nodes are pa rt of the second tier architectur e which is previously explained to be ring-start architecture. Th e wavelength assignment and routi ng is different for the HP and MLP traffic, similar to the case that exists in the backbone network. The routing in the second tier is different in case of any faults in the netw ork which will be dealt with detail as a part of Chapter 5. Here in the following s ection details of the routing pr otocol in the second tier is elucidated. The HP packets generated from the sub-system nodes, use the star network or the dedicated fiber links from each node to the contro ller to convey the HP packets to the backbone torus network and also used if any intra-subsyste m HP packets are generated. From there, the HP packets use the dedicated lightpaths established for each source-destination sub-system pair. The MLP packets generated here are classified as intra-subsystem and inter-subsystem communication entities and are treated separately. Each node is equipped with one tunable laser and a fixed detector very simila r to OTDM protocol for the bac kbone MLP traffic. As shown in Figure 4-7, there are two unidirect ional optical fibers and the nodes by default stick with ring 1

PAGE 64

64 and follow the OTDM strategy for intra-subsyste m communication. The time slot allocation for the MLP traffic communication within the sub-system is shown in Figure 4-8, and it could be observed that the frame structure follows the same round robin fashion with sufficient guard intervals between each time slots. At the end of each frame a special Hello packet is transmitted for fault tolerance applications and will be elaborated in Chapter 5. Figure 4-7. Intra-Ring communicatio n for second-tier MLP packets The MLP inter-subsystem communication is permitted to use the star topology along with the HP packets but HP packets in the queue are se rviced ahead of MLP pack ets to provide better QoS support. Each node also maintains differe nt queues for high, medium and low priority packets and is serviced accordingly. All inter-subsystem communication packets use the star topology and only in case of any fault they are routed accordingly through the ring topology and the outlet nodes. The use of OTDM based sche duling for any intra-subsystem communication is reasonable taking into consideration the percen tage of such packets being generated when compared packets generated to different sub-system s. The sub-system controller is equipped with

PAGE 65

65 an array of detectors to receive the optical signal s from the star links from all the nodes in the sub-system and also has an array of transmitti ng lasers one for each node in the star topology. Figure 4-8. The OTDM time slot allocation for second tier intr a-ring communication Summary The need and importance of prioritizing the da ta being generated be tween the sub-systems is justified with corresponding examples. Resource allocation and access control protocols for the proposed XYTARP architecture is discussed with stress on the pr ioritized traffic flow within the network. The broadcast and select routing has more advantages to be explored when considering a fault tolerant rout ing protocol and is to be expl ained in the following chapter.

PAGE 66

66 CHAPTER 5 FAULT TOLERANCE FOR AVIONIC WDM LANS Netw ork Reliability and Fault Tolerance The ma jority of communications applications, from cellular telephone conversations to credit card transactions, assume the availability of a reliable network. At this level, data are expected to traverse the network and to arrive intact at their destination. The physical systems that compose a network, on the other hand, are su bjected to a wide range of problems, ranging from signal distortion to component failures. Sim ilarly, the software that supports the high-level semantic interface often contains unknown bugs and other latent reliability problems. Redundancy underlies all approach es to fault tolerance. Redundancy takes two forms, spatial and temporal. Spatial redundancy replicates the components or data in a particular system. Transmission over multiple paths through a network and the use of error-correction codes are exam ples of spatial redundancy. Temporal redundancy underlies specially designed algor ithms that are used to suppor t reliable transmission in the network. A reliable network typical ly provides both spat ial and temporal redundancy to tolerate faults with differing temporal persistence. Spatial redundancy is necessary to overcome permanent failures in physical components, wh ile temporal redundancy requires fewer resources and is thus preferable when dealing with transient errors. In the design of a fault-tolerant system, the ne twork must be capable of detecting each fault in the model, and must be able to isolate each fault from the functioning portion of the system in a manner that prevents faulty behavior from spreading. As a fault de tection mechanism may detect more than one possible fault, a system must also address the proces s of fault diagnosis (or localization), which narrows the se t of possible faults and allows more efficient fault isolation techniques to be employed. An error identified by a system n eed not necessarily be narrowed

PAGE 67

67 down to a single possible fault, but a smaller set of possibilities usually allows a more efficient strategy for recovery. A packet-switched network can generally tolera te more serious service disruptions than can those based on circuit-switched networks. The latter class of applica tions may assume that data rate, delay, and jitter guarantees provided by the network will be honored even when failures occur, whereas minor disruptions may occur even in normal circumstances on packetswitched networks due to fluctuations in traffic pa tterns and loads. Fault tolerance issues are thus addressed in markedly different ways in the two types of networ ks. In packet-switched networks like the Internet, users currently tolerate restora tion times of minutes, whereas fault tolerance for circuit-switched networks can be considered a co mponent of quality of service (QoS), and is typically achieved in milliseconds, or, at worst, seconds. The backbone network fault tolerance is of high priority when compared with the functional access network as they support heavy traffic loads. As even a short down time may cause substantial data loss, rapid recovery from failure is important, and these networks require high levels of reliability. In these networks, a failure may arise because a communications link is disconnected or a network node becomes incapacita ted. Among the different types of faults that can occur in a system, link failures are of great importance. This is because such faults can isolate a part of the system that might otherw ise contain healthy nodes and components. Not only should the link provide high bandwidth and low la tency, but it should also be fault tolerant. Failures may occur in military networks under att ack, as well as in public networks, in which failures, albeit rare, can be extremely disruptive. The next section provides an overview of fault detection and isolation mechanisms and the basic strategies available for recovery from network component failures.

PAGE 68

68 Fault Detection and Isolation Failure dete ction and isolation includes the ability to determine when a system fails to meet operating requirements and to correctly identify what part need s to be replaced to restore operation. An avionics fault de tection method must be capable of detecting not only total failures of a link or network, but also degraded BER performance of a link due to degraded transceiver and/or cable plant performance. Isolation of erro rs when they occur is critical in terms of the network performance and the designed protocols should make it possible to isolate the fault as soon as possible and trigger the r ecovery mechanism. However, most modern application protocols simply report that a fault occurred and not th e actual cause of the fault. Failure analysis during fiber optic network design and development must identify the root causes, and strive to design them out. A wide variety of approaches have been em ployed for detection of network failures. In electronic networks with binary voltage encodings ( e.g., RS-232), two non-zero voltages are chosen for signaling. A voltage of zero thus imp lies a dead line or termin al. Similarly, electronic networks based on carrier modulation infer failu res from the absence of a carrier. Shared segments such as Ethernet have been more problematic, as in dividual nodes cannot be expected to drive the segment continuously. In such netw orks, many failures must be detected by higher levels in the protocol stack. The capacity of optical links makes physical mo nitoring a particularly important problem, and many techniques have been explored and used in practice. Optical encoding schemes generally rely on on-off keying, i.e. the presence of light provid es one signal, and its absence provides a second. With single-wave length optics, information must be incorporated into the channel itself. One approach is to monitor time-averaged signal power, using an encoding scheme that results in a predictable distribution of on and off frequencies. A second approach

PAGE 69

69 utilizes overhead bits in the channel, allowing bit error rate (BER) sampling at the expense of restricting the data format used by higher levels of the protocol stack. A third approach employs a sideband to carry a pilot tone. These approa ches are complementary, and can be used in tandem. A WDM system typically applie s the single-wavelength technique s just mentioned to each wavelength, but the possibility of exploiting th e multiplexing to reduce the cost of failure detection has given rise to new t echniques. A single wavelength, fo r example, can be allocated to provide accurate estimates of BE R along a link. In deployed fiber op tic links and networks in an aircraft, built in test (BIT) tech niques can be used to both predic t link failure before link failure actually occurs and isolate faults when they do oc cur. By predicting link failure before it occurs, failure rate and mean time to repair can be re duced. Unfortunately, this approach may fail to detect frequency dependent signal degradation. Pairing of monitoring wavelengths with data wavelengths reduces the likelihood of mi ssing a frequency-dependent failure. The choice of failure detection methods used in a backbone network is intertwined with the choice of strategies for restoring circuits that pass through a fa iled element of the network. Path monitoring, for example, does not readily provide information for failure localization. Correlated failures between paths may help to localize failure s, but typically a more careful investigation must be initiated to find the problem. Path mon itoring also requires that failure information propagate to the endpoints of the path, delaying detection. Link monitoring allows more rapid and local response to failures, but does not require such an appr oach. Instead, failure information can be propagated to the ends of each path crossing a link, while the localized failure information is retained for initiati ng repairs and for dynamic construction of future paths. At the algorithmic

PAGE 70

70 level, circuit rerouting schemes can be broadly split into path-based and linkor node-based approaches. Fault Recovery/Tolerance Prompted by the increasing reliance on highspeed communications and the requirement that these communications be robus t to failures, backbone networks have generally adopted selfhealing strategies to automatica lly restore functionality. The st udy of self-healing networks is often classified according to the following three cr iteria, the use of link (line) rerouting versus path (or end-to-end) rerouti ng, the use of centralized com putation versus distributed computation, and the use of pre-computed ve rsus dynamically computed routes. For path recovery, when a failure leaves a node disconnected from the primary route, a back-up route, which may or may not share nodes and links with the primary route, is used. Figure 5-1. Path and Li nk routing explained Link rerouting usually refers to the replacem ent of a link by links connecting the two end nodes of the failed link. When the rerouting is pre-computed, the method is generally termed protection. Thus, path protection refers to pre-computed reco very applied to connections following a particular path acros s a network. Link or node protect ion refers to pre-computed recovery of all the traffic across a failed link or node, respectively. Figure 51 illustrates path and link rerouting. Protection routes are pre-computed at a single lo cation, and are thus centralized,

PAGE 71

71 although some distributed reconfiguration of optical switches may be necessary before traffic is restored. Restoration technique s, on the other hand, can rely on distributed signaling between nodes, or upon allocation of a ne w path by a central manager. Some of the common methods used for toleratin g faults in an avionic environment include component redundancy, reconfiguration, and faulttolerant routing algor ithms. While component redundancy is an effective means to tolerate fau lts in components such as power supplies and cooling fans, it may not be a very efficient mean s in terms of faults in components such as processors, interconnection links, transmitters, and receivers. This is because of the high cost of the spare components and the possi bility that the circuits requ ired to switch to the spare components might fail. The second method involv es reconfiguring the routing tables and adapting them to the new topology after the failure This method can be e ffective in switch-based networks such as Infiniband or Quadrics, wh ere the user defines the topology. Although, when using reconfiguration in such a manner, any number of faults can be tolerated as long as the network remains connected, it ha s been shown that such generic algorithms achieve poor performance when applied to re gular networks. The third common way to tolerate faults is by designing a fault-tolerant routi ng algorithm. The design of th e router and on-board switching methodology plays a very important role in ensuring an efficient fault-tolerant routing algorithm. Fault Tolerance Requirements in Avionic Networks So far a general networks reliability a nd fault detection, isolation and tolerance mechanis ms were explained in detail and with this basic background the analysis of the fault tolerance of an avionic WD M LAN becomes simpler. A balance between performance, reliability, maintainability, supportability, and short-term a nd long-term costs should be incorporated when designing and building an avionics network. The chosen network architecture should provide suffi cient network fault tolerance, redundancy, reconfigurability, and

PAGE 72

72 reliability consistent with system fault detection and isolation and false alarm rate expectations. The network architecture shoul d facilitate both preventive and corrective maintenance. The term reliability defines the probability that a system will be operational within stated parameters for a given period of time under given c onditions. Reliability is often stated in terms of a relationship between the operational time peri od and the failure rate. Military aircraft fiber optic network designs must not only cons ider the harsh operational and maintenance environment, but also need to be deployed in a maintainable and supportable manner. The term maintainability defines how quickly, easily, and cost effectively an avionics fiber optic network design can return to operational status (whether by preventive or corrective maintenance). Supportability on the other hand, is the degree to which the avionics fiber optic network design characteristics minimize the logistics resources (p eople, skill levels, parts, publications, tools, test equipment, space, etc.) required to sustai n the systems Operational Availability at an affordable cost throughout the lif e of the system. The designed avi onic network is also expected to survive or operate in the following conditions: Temperature (operating, short time and ground survival) Temperature shock Steady state pressure and pressure variation Acceleration Mechanical and acoustic vibrations Humidity Thus in the proposed XYTARP architecture, we tend to encapsulate the key features of fault tolerance and dynamic reconfigurability in to the basic torus backbone network and the various sub-system access networks. In this proc ess we use a modified version base routing protocol to suit the instantaneous needs of th e network and thus achieve a fault tolerant

PAGE 73

73 architecture. The developed fault tolerant routing algorithm enables dynamic reconfigurability by rerouting packets when they come across any faulty links. The algorithm is designed in such a way that it maintains optimal performance in th e absence of faults, shows minimal performance loss in the presence of faults, and can tolerate a reasonable number of fau lts based on the priority of packet being served. The XYTARP Architecture Fault Tolerance Analysis This section elaborates the designed fa ult tolerant routing algorithm for the XYTARP architecture. First an efficient way of fault dete ction is discussed along with the routing tables used for keeping track of the fiber links in the network. Though the fault tolerance in XYTARP can be achieved from many perspectives such as fiber link, transmitters, detectors, and router, here the fault tolerance is viewed from a fiber links point of view That is, even a node fault is modeled as faults in all the fiber links surrounding that particular node. Later, the fault tolerance routing algorithm is analyzed for different prio rities of traffic both in the backbone network and also from the sub-system access network level. Fault Detection: Hello Packets a nd Link Status Notifications Various fault detection strategi es were discussed in the previous sections and the XYTARP architectures fault tolerance de sign incorporates a special me thod for detecting and spreading an instance of fault in the network. A fault in an optical backbone network implies a faulty optical link or a broken controller. Fa ult detection in the network is proposed to be achieved using special hello packet transmissions to notify the neighboring nodes that the link or the controller is still active [9]. One wavelength is dedicate d for hello packet tran smission in the whole network. Using this particular wavelength each controller transmits a low power continuous optical signal or a fixed patte rn pulse at a known frequency to its neighboring controller nodes. The hello packets that are sent from each controll er in both X and Y rings, are very short packets

PAGE 74

74 that are 2 bytes long and are gene rated at a periodic rate of 100 ns. This periodic transmission property of the hello packets is utilized to determ ine any link or controller faults. If a node fails to receive a hello packet in an 110ns interval from one of its ports, it decides that the particular link or the source controller is in fault a nd triggers a fault recovery mechanism. The fault recovery mechanism if needed is tri ggered by the controller node that detects the fault as it failed to receive the hello packet within the periodic time interval. The main purpose of the fault recovery mechanism is to propagate the occurrence of the fault throughout the network and this is important as a particular instance of fault may affect the routing mechanism of a distant controller node. So as soon as the fault is identified, the r eceiving controller generates a special link status notification message (LSN ) and broadcasts this packet throughout the network. The case of a faulty component or link coming back active also requires to be notified to the entire network. For exampl e, a link would have been down for some time and the entire network is aware of this using the LSN packets. Af ter some time if that particular link comes up the hello packets through that link reaches its corresponding receiving controller, and it later identifies that a faulty link is currently activ e and propagates this information through another LSN packet throughout the network. The LSN packets that convey either a fault or a fault-recovered scenario, has a payload size of 20 bytes to convey the required information. The LSN packets are broadcast from the fault detected controller in its X and Y direction ring and all nodes that receives the corresponding information updates its routing tables and agai n broadcasts the LSN packets. The broadcast nature of LSN packet allows multiple copies of the same packet to be received by each controller and such copies can be discarded. The broadcast nature ensures that the status of the network is conveyed to all the sub-systems even in the pres ence of some distributed faults in the network.

PAGE 75

75 The information contained in the LSN packets is used by a controller to update its link status table and also the routing tables which w ill be explained in the following section. Link Status Table and Routing Table In order to keep track of the current s tatus of the network at all times, each sub-system controller maintains locally two ta bles each: a link status table and a routing table. Considering a 4x4 XYTARP architecture proposed in Chapter 3 with bi-directional optical rings, the local link status table maintains the current status of all the 64 optical fiber links in the network. Table 5-1 shows an illustration of the link status table a nd its corresponding entries. Each and every entry has its own significance and plays its role. Table 5-1. Link Status Table maintained at each sub-system controller nodes Link id Status Used Update time 1112 DOWN NO 12215.21 1121 UP YES 0.0 1114 UP YES 12215.21 1141 UP NO 0.0 .. .. .. .. 4434 UP NO 0.0 As seen, the table has 64 entries (one for each fiber link in the toru s network) and three fields per entry in the table. The entries are l ogically grouped in the table based on their location around a controller for ease of reference. Starting from the top leftmost c ontroller and proceeding along each row till the bottom rightmost controller is reached, the fiber links are entered in the following order: east port li nk, south port link, west port li nk, and the north port link. The naming convention for the fiber link is chosen as a combination of the links starting controller ID and the ending controller ID. For example a fiber link running be tween the contro llers 11 and 12 is given a LINK ID 1112. The actua l link status table does not have a separate LINK ID field,

PAGE 76

76 but this is just used for logi cally grouping the entries and thereby making link reference easier for each controller. The STATUS field in the link status table i ndicates whether the corresponding fiber link is currently active or down due to any link fault. So the entries for this field would be either UP or DOWN. The USED field is primarily used for MLP traffi c routing and determines whether the reference fiber link is part of the optical ring th at is currently active for routing MLP traffic and the entries for this field would be YES if the lin k is currently part of the active ring or else NO would be entered. The UPDATE TIME field indicat es the time that the last LSN packet was generated to notify any changes in the status of that particular fi ber link. For example, if the fiber link between contro ller 11 and 12 is down, the end node of the link being controller 12 generates the corresponding LSN packet at say 12215.21 ns, as soon as this LSN packet is received by other controllers in the network, it s entry is updated with the respective values as illustrated in Table 5-1. The second table that is maintained at each c ontroller is a routing table as shown in Table 5-2. The routing table makes use of the informati on stored in the link stat us table and updates its contents. It has 16 entries (one fo r each controller in the network) and one field per entry to show the path or route the packet must follow to reach that particular destin ation. The PATH field may take X, Y, FWD or NO route as its entry based on the current network status. An X entry in the PATH field implies that the optical packet must be sent using the Xdimension optical ring to reach the particular destination. If the de stination controller re quires an inter-ring communication, then an X entry implies that th e packet must routed using the X-Y routing mechanism explained in Chapter 4. Similarly a Y entry in the PATH field implies using the Y ring or Y-X routing to reach th e corresponding destinati on controller. The Y-X routing is similar

PAGE 77

77 to the X-Y routing protocol, but the packet is first forwarded to an intermediate node in the Y dimension ring, which forwards the packet to th e real destination using the X dimension ring. Table 5-2. Routing Table maintained at each sub-system controller nodes Dest ID ROUTE 11 X 12 FWD 13 Y 14 NO .. .. 44 X FWD entry is used in the PATH field only if the faults in the network prohibit the intraring communication to route the packets normally and by effect the packets are to be forwarded to a neighboring controller and from there the packets reach the destin ation as inter-ring communication packets. The functio ning of FWD route will be e xplained in more detail when the fault tolerance routing for MLP traffic is handled. The NO route entry implies that there is no way the packet can be delivered to the sp ecific destination and has to be dropped. If a controller receives a LSN packet conveying that a link in the netw ork is down or switched back active, the controller first update s the corresponding entry in the link status table. Based on the changes made to its link status table, each and every controller re-calculates the route for each and every other sub-system controller and updates th e routing table. This is because a fiber link in the network may be part of a lightpath or rout e of a packet from a distant source node to any node the network.

PAGE 78

78 Fault Tolerance for High Priority Traffic The fault tolerance realization for the high pr iority traffic in the backbone network has been taken care of by the architecture design, in that each pa cket is sent via four redundant, dedicated light paths setup between the source-destination sub-system pairs. The receiving controller buffers the packets as it receives from all four ports The shortest hop length light paths buffer is the default buffer to read. In the event of a fault, a cont roller is notified through the LSN packet and this initiates a fault recovery mechanism at the controller and this process is illustrated in Figure 5-2. The response is a switchi ng action to read from the buffer that receives the HP traffic through the next s hortest lightpath port. Any change in the link status table of a particular controller triggers th e HP controller section of a nod e to check if the LSN packets LINK ID is part of the default shortest lightpath for that receiving controller. If so, the controller makes a decision to switch the buffer its reads from for the HP packet. The message ID field of a packet namely MSG ID is also used in the proces s of choosing the right buffer to read the packet from by removing the redundant data packets in the buffers and reading the packets in order. The HP traffic data thus read successfully from th e buffer is now passed to the second tier access networks real destin ation node via the star topology fiber links. Figure 5-2. High priority backbone torus network fault tolerance

PAGE 79

79 Fault tolerance for Medium and Low priority packets The base routing for the MLP traffic is very m uch different from that of a HP traffic routing which is more deterministic in the proc ess of setting up the lightpaths. Whereas the MLP packets have to depend on the X-Y routing prot ocol and the time slot allocation if OTDM protocol is used. Each sub-system controller has the option of routing its MLP packets along two directions, i.e., along the X and Y dimension rings. By default a controller utilizes the west to east direction X ring and the north to south dir ection Y ring to perform intra-ring communication with controllers in the same ri ng. The remaining east to west dire ction X ring and south to north direction Y ring are treated as sta ndby redundant paths to be used in case of a fault in the default optical rings. In case a controller receives an LSN update that reports a link failure in its default working ring, it checks if the standby redundant ring is up and active fro m its locally maintained link status table. If the standby ring is in an active working state, the controller switches its operations to the standby ring. As the LSN update is received by all the controllers in that particular ring, the complete operation is shifted to the othe r redundant and active optical ring. Though the controllers in the faulty ring have switched to another ring, they still can follow the base X-Y routing protocol for the inter-ri ng communications. So the first fau lt in terms of link failure does not evoke any serious re-routing in the network other than the switching operation, but there is always a possibility of packets in transit to be dropped when switching. Now, another fault in the switched and worki ng ring means that there is no backup optical ring to switch and so the controlle rs stick with the current ring itself. In this way, normal intraring communication can still be pos sible between some of the contro llers but not all. So in order to continue delivering the intra-ring communication packets, a fo rward or FWD route has to be established. That is, the sour ce controller forwards the intr a-ring packets to a neighboring

PAGE 80

80 controller that is in a di rection directly perpendicular to the fa ulty link, and delivered as if it were an inter-ring communication packet from the neighbor node. To provide a better QoS performance in such cases, the low priority FWD packets are dropped allowing the intra-ring medium priority packets to be de livered quicker. At the same time all these controllers, lose their ability to route the inter-ring communication packets through the base X-Y routing scheme as part of both the X direction optical ring is down. This is where a need for Y-X routing to accomplish the inter-ring communication arises and th e routing scheme for all the destinations in the network is recalculated and the routing tabl e entries are updated ac cordingly. Further local faults may result in certain controllers isolated in the network and they may not be reached in any case. So when a NO route case is reached, the packets for that particular sub-system must be dropped. Figure 5-3. The MLP fault tolerance reconfigur ation and re-routing. A) No fault with base routing, B) re-routing after fi rst link failure, C) re-routing after second link failure and D) re-routing after third link failure To better understand the MLP fault tolerance rou ting protocol a sample scenario is created in Figure 5-3. The normal base rou ting scenario with no faults in the network is illustrated in Figure 5-3(A). For simplicity just one optical ring is chosen for this particular scenario and the red color arrowed lines indicates the currently active optical ring and any fiber link fault is indicated by a cross mark on that particular fibe r link. Figure 5-3(B) show s the first link failure

PAGE 81

81 between the first two controllers and so the second controller is responsible for generating the LSN packet. Failing to receive the hello packet from the first controller in time due to the link failure, the second controller propa gates the link failure via the LS N packet and switches to the redundant optical ring indicated now by red color. So as the LSN packet gets broadcasted and reaches all the controllers in the same ring, they all switch to the active redundant optical ring and update their link status table. Further link failure between the third and second controller in the ring causes a new LSN packet to be propagated through the network and is illustrated in Figure 5-3 (C). This fault as it is received by distant cont rollers causes both the link status ta ble and routing table to be updated. Since the other optical ring also has a link failure, the controllers in the ring do not switch but stays with the current ring. Th is optical ring permits for part ial intra-ring communication, for example between the fourth a nd third controller and so on. But any intra-ring communication that requires the functionality of the link between third and second controller requires to be rerouted via the FWD route. An example FWD rout e path is shown in Figure 5-3(C) in the Y direction. For example, the intraring communication packets from c ontroller three to controller two are forwarded as inter-ring communication packets from the ne ighbor of controller three as shown in the Figure 5-3 (C). Further a third fault in the FWD route path is shown in part D of Figure 5-3 and this just causes sw itching in the Y-direc tion ring. Any additional localized fault to the third controller may result in NO route case fo r certain destination controllers and eventually end up with an increase in the number of packets dropped due to network faults. The fault tolerance of the network is so fa r seen essentially from the backbone torus network point of view for the prioritized traffic. The data received from the backbone network is conveyed to the second tier or the sub-system access networks, which generally generate and

PAGE 82

82 receive the data information. So fault tolerance is very important for the second tier nodes also and their respective fault tolerance protocol is discussed in the following section. Fault Tolerance for Second Tier Access Networks The second tier architecture and routing prot ocol have been explai ned with care in the previous chapters and now the response of the sa me to any network fault is considered. The ring topology is mainly employed to aid any intra-subsystem packets that are generated and an OTDM based base routing protocol is followe d for the same. The star topology is mainly designed for the HP traffic and also inter-subs ystem traffic generated. In the event of a link failure in the ring topology, the functioning swit ches to the redundant optical ring if it is available and active. Similar to the backbone torus network, the ring topology also uses the hello packet as a means for fault detection and isola tion. But here instead of a dedicated wavelength for monitoring the links, the nodes use a particul ar time slot and its own fixed receiving wavelength to transmit the hello packet. The star topology responsible for the HP tra ffic and also inter-subsystem MLP traffic also utilizes hello packets to keep track of the link status. Here ad ditionally, a Hello-ACK packet is expected via the link from the controller to the no de in response to the star links hello packet. Upon timeout, the node decides that the controller link is down and triggers the corresponding fault tolerant routing scheme. The functionality of grouping of nodes and the outlet nodes were discussed when explaining the second tier archite cture and its importance will be exploited here. Upon a star link failure, the HP traffic and the inter-subsystem MLP traffi c are forwarded via the nearest outlet node to the adjacent controller. Th e semi-torus interconnection of the second tier nodes, allows such a forwarding scheme as a solution for second tier fault tolerance. The presence of the outlet nodes in the second tier archite cture and the groupi ng of nodes is best illustrated in Figure 5-4.

PAGE 83

83 Figure 5-4. Second tier access network fault tolerance The most important thing to be noted here is that the HP packets that are being forwarded via the outlet nodes are down converted as medium priority packets and then routed in the backbone torus network. This is be cause, if the controller is down and the HP traffic is routed through a different controller all together, we tend to lose the dedicated lightpaths between the required sub-systems. Once such HP packets reach as medium priority pack ets at the destination controller they are back converted to their origin al high priority and routed to the nodes via the star fiber links. There is not much difference for the inter-subsystem MLP packets that are rerouted through the outlet nodes. In case of a fault in the receiving controller, the source controller uses the fault tolerance scheme designed for the backbone network and ro ute the traffic through one of the neighboring controller of the faulty controller. Then the outlet node interconnection is used to forward the

PAGE 84

84 data traffic to the required destination node. Thus by using the functionality of the outlet nodes, the fault tolerance capability of the network is increased and is now capable of tolerating multiple distributed and localized faults. Summary The necessi ty for a reliable and a fault tolerant network is analyzed for avionic WDM LAN network and various fault detec tion and isolation techniques ha ve been discussed. The fault tolerance for the high priority packets is observed to be pretty deterministic at least from the backbone torus networks perspective. The info rmation provided by the two locally maintained tables at the sub-system contro llers is used by the MLP traffic to route packets correctly even under the presence of certain number of faults. The proposed XYTARP arch itecture satisfies the basic requirement of tolerating the first three fa ults with little effect on the performance.

PAGE 85

85 CHAPTER 6 WDM LAN MODELING, SIMULATION ANALYSIS AND RESULTS The aspects of the proposed XYTARP architecture and the access protocols could well be comb ined to meet the unique requirements of an optical WDM LAN deployment in aerospace applications. Modeling and simulation capabilities n eed to have the ability to mix and match the protocols proposed for a thorough evaluation of architecture candidates for WDM optical networking in aerospace applications. The ultimate goal is to evaluate the network performance from top to bottom, determine the factors that ar e most influential in network performance, and optimize the network design to meet the requirements at the lowest possible cost. In this context, cost may include total life cycle cost/tot al cost of ownership as well as physical factors such as weight and volume that consume limited physical resources in an ai rcraft environment. Performance requirements may also include reliability and fault tolerance. Discrete-event network simulation can be used to model the logical and dynamic behavior of networks and systems running various protoc ols. Network simulation typically focuses on layers above the physical layer su ch as the data link and network layers of the OSI reference model. Discrete-event network simulation can be used to validate a network architecture design including its management, control, and protocols. In such simu lation environments the actual physical medium is typically modeled as simply da ta widths, link speeds, a nd generic error rates. Such network centric tools are typically used to perform protocol, topology, and end-to-end QoS tradeoffs. The simulation tool used for modeling th e optical components here is also a discrete event network simulator, Artifex, which is basically an extended Petri-net based simulator. The need to bridge the gap between the physical laye r and network layer of optical networks, led to the proposal and development of the DRAGON library which contains models of optical components in Artifex.

PAGE 86

86 The network layer modeling and simulation of the XYTARP architecture and its routing protocols should include the following: Traffic management o The performance of the network is to be analyzed with respect to the type of traffic that flows in the network. Networ k protocol performance in conjunction with the management of various traffic types should be evaluated and compared. o Network performance in conjunction with mana gement of buffering of data traffic at a node, which may be delayed relative to other packets in a related stream of packets. o Network performance in conjunction with th e different types of traffic patterns and a faulty network scenario. Resource management o Analysis of performance of a link and th e network overall with respect to the wavelength allocation strategy in terms of wavelength utilization. o Network performance in the presence of various medium access control (MAC) protocols proposed. o Comparative analysis of th e proposed MAC protocols. o Performance analysis of the access protoc ols in the presence of potential network faults. Fault management o Sustain the first two network faults with no effect in terms of performance and the third fault must be tolerated with minimal performance degradation. o An analysis of fault isolation should be included to analyze, how well the network architecture can isolate and work around fa ults by procedures such as packet rerouting and network control. o Analyze the maximum flexibility of the network, i.e., the maximum number of faults the network could bear. o An analysis of different fault scenarios (link failure in a ring or mesh connection, failure in a termination node, failure in a controller node, failure in a routing node, etc.). o Network performance degradation in terms of the location of occurrence of the fault.

PAGE 87

87 Quality of Service (QoS) management o The network must support transfer of multip le types of data, each with its own requirements for latency and error rate. The proposed XYTARP architecture and its medium access protocols are simulated in Artifex and the above mentioned simulation requ irements are tested. Th e DRAGON library of optical components are used as a base and the architecture and protocol s are built above it and tested. The remaining part of this chapter is orga nized as follows: the different traffic generator models that used for simulation purposes are built as traffic generator models in Artifex and is discussed first. Next, the metric s that are best used to char acterize the performance of the network in the required conditions are evaluated and explained in detail. Following this, is an extensive simulative analysis of the various proposed MAC prot ocols for the architecture and their comparative performance analysis. The fault tolerance analysis is pe rformed with the help of a few experimental scenarios that best captures an actual aerospace environment. Traffic Generator Models in Artifex The nodes that generate the actual data tra ffic from the access network topology generate basica lly three types of traffic patterns in thes e systems: periodic, Poisson and random or bursty traffic patterns. The LION library built using the MLD discrete event simulator had an inbuilt traffic generator source that suppor ted these traffic patterns. Sinc e Artifex simulation tool, didnt have a composite traffic generator that meets the current simulation needs the three traffic generator sources are modeled in it with required parameters to meet the requirements. The periodic traffic generator is capable of generating packets at periodic intervals, with a variable amount of jitter to introduce randomness. The only parameter used in modeling the periodic traffic generator is the required averag e rate in Mbps. The Poisson traffic generator brings a small percentage of randomness in the tr affic generation process with the inter-arrival

PAGE 88

88 time between the packets being exponentially distri buted. Here also the average rate in Mbps is the only parameter used to characterize the Poiss on traffic generator. The bursty traffic generator is more random in terms of generation time and also closely approximates the actual traffic in the backbone networks. In a broadband communication environment, an application can be best modeled as a source of bursty traffic, which c onsists of bursts of data, possibl y at maximum application data rate, followed by long idle periods. Here, th e bursty source is mode led as a Markov chain consisting of two states, active a nd idle, as shown in Figure 6-1. When the source is in active state, it generates packets at a peak packet gene ration rate P. In the idle state the source is dormant and no packets are generated. The holding time in both the active and idle states are exponentially distributed with means 1/ and 1/ respectively. The bursty tr affic generator relies on three parameters: peak rate ( p), average rate ( a) and burst factor (B). Burst factor defines the average number of packets that are genera ted above the average packet arrival rate. Figure 6-1. Bursty traffic generator model Let L be the packet size in bytes and it can be shown that and can be expressed in terms of the peak rate (p), average rate (a), and the burst factor (B) as follows: = average rate / (8 pa cket size burst factor) = (peak rate average rate) / (8 packet size burst factor)

PAGE 89

89 Figure 6-2. Periodic and Poisson tr affic generator model. A) Instantaneous rate for periodic traffic pattern, B) Cumulative rate for periodic traffic pa ttern, C) Instantaneous rate for Poisson traffic pattern, and D) Cumu lative rate for Poisson traffic pattern In order to test the modeled traffic generato rs two metrics where used: Instantaneous rate, and cumulative rate. The instantaneous rate of a traffic pattern is used to probe the traffic generation rate of the source at continuous time in stants. The cumulative rate is an accumulative traffic generation rate of a sour ce and is evaluated with respect to the elapsed time. The three different traffic patterns are compared and its be havior could be better understood by these three parameters. Figure 6-2 shows the periodic and Poi sson traffic patterns performance in terms of instantaneous and cumulative rate. Th e periodic traffic generator is tested with an average packet

PAGE 90

90 rate of 10Mbps and the laser operation speed is fi xed as 1Gbps. The instantaneous rate gives the same value at all time instants as the periodic ra te generates traffic at a constant rate at all time instants. The cumulative traffic generation rate of the periodic source is also pretty much deterministic and has a constant value of 10Mbps These performances are observed in Figure 62(A) and (B). The Poisson traffic source is tested with an average packet generation rate of 5 Mbps and the same 1Gbps laser transmission rate. The results are illustrated in Figur e 6-2 (C) and (D). The Poisson source has an exponential inter-arrival distribu tion between the packet s, and this could be observed in instantaneous rate graph with packet generation rates reaching even the peak 1Gbps. But still the average rate of arrival of packets is 5Mbp s and this is proved from the cumulative arrival rate graph which initially ha s a peak value and later stabilizes around the average rate of 5Mbps. The bursty traffic model is tested with an av erage packet generation rate of 10Mbps, peak rate of 100Mbps, and burst factor of 500 packets. The instantaneous rate and cumulative rate of the bursty source is shown in Figure 6-3 (A) and (B) respectively. The instantaneous rate graph of a bursty source shows the existence of a de nse burst duration where numerous packets are generated at peak rate followed by long and varying idle durations. The idle duration length is critical in maintaining the averag e packet arrival rate as a lot of packets are pumped during the burst duration at a very high rate. The cumulativ e rate graph shows that the bursty source takes some time to stabilize its aver age packet arrival rate around 10Mbps. This is because the source has to wait for a idle duration to neutralize the effect of a high arrival rate of a burst duration. The bursty generator model has the most oscillati ng cumulative rate because of the existence of dense burst periods.

PAGE 91

91 Figure 6-3. Bursty traffic generator model, A) Instantaneous rate, B) Cumulative rate Simulation Metrics There are a variety of cr iteria that can be used to evaluate optical ne twork architectures and their corresponding access protocols. These crite ria may be based upon metrics of component or network performance at some level, or upon whether certain metrics meet specifications. In this section of this document, we list a number of metrics that are used to evaluate network architectures, their resource management and access protocols, and fa ult tolerance of the network. Packet Latency The comp lete latency of a packet is usually taken as the end-to-end delay, meaning, once a packet is generated, and how much time passe s before it is successfully received at the destination. It is a sum of the Set up Time, Queueing time, Transmission Time, Propagation Time, and Processing Time.

PAGE 92

92 Set up time: o Circuit-switched networks: The set up time establishes the route from source to destination before any packet can be se nt. (e.g., after diali ng a telephone number, the ring signifies that a dedicate d route has been determined.) o Packet-switched networks: Not a factor, si nce a packet route is determined on the fly, hop-by-hop. (e.g., emails do not wait for a ring before being sent to the destination). o Virtual-circuit switched networks: They are packet-switched ne tworks that use a dedicated path from source to destin ation, so set up time is a factor. Queuing /Storage time: A node may be able to generate packets at a higher rate that the transmitter is able to send packets. Thus, this is the time that a generated data packet must wait (presumably in a queue) before it is transmitted. Transmission time: This accounts for the latency to put all of the bits of the packet on the link. It depends on the number of bits to be transmitted and the transmitter data rate (R) [11]. o Circuit-switched networks: Here, the enti rety of the message bits (M) can be placed on the link to follow the de dicated, pre-determined route. o Packet-switched networks: Here, the message is divided into packets. The latency depends on the number of packets need ed (N) and the transmission time per packet (T). The number of packets needed depends on the size of the message (M) versus the size of the packet payload (S ). The transmission time depends on the total size of the packet (P), which in cludes overhead, and the transmission rate (R). Then, the transmission latency is: Tx_pkt = N*T (6-1) o Virtual-circuit switched networks: Sa me as the packet-switched network. Propagation time: This is the time for the signal to travel from the source to the destination. It depends on the speed of th e signal (V), which is usually 2 to 3 *108 m/s for optical fiber, the number of hops (H), and the distance between hops (D): Prop = (D/V) H (6-2) Processing time: This refers to various latencies incurred fr om devices in the communication path, including repeaters, amplifiers, optical-electronic-optical (O-E-O) conversion, routing table look-up, et c. It can be added as one combined factor (Proc), or included as a hop-by-hop delay f actor: Processing delay may al so include the destination checking the packet for errors once it is received (E). Proc = (Proc_per_Hop)*H + E. (6-3)

PAGE 93

93 LSN Latency This particular me tric captures the end to end delay or time taken for the link status notification packets to conve y an instance of fault to the entire network. This metric is of interest in testing the networks performance under the presence of distri buted and localized faults, as the LSN latency plays a vital role in routing under faulty scenarios. Data Throughput The data throughput is a m easure of how much data can be transmitted over a network in a given period of time. A more appropriate de finition would be the aggregate number of bytes received by the detector per unit time for all nodes in the network. This differs from the bit rate, because the bit rate is a measure of the number of physical bits transmitted over a single channel in a point to point link. Data throughput includes reductions due to encoding such as 8B/10B encoding, Manchester encoding, FEC encoding; increases due to wavelength division multiplexing (WDM); and impacts of network routing and associated bottlenecks and resource conflicts. Dropped Packet Ratio There is alwa ys a very high probability of packets being dropped or lost in transit in a network. The dropped packet ratio metric tries to capture the number of such packets being dropped or lost in contrast to the total number of packets that are being transmitted from all the nodes in the network. This measure is useful in analyzing the network in the presence of multiple faults. The XYTARP Backbone Network Access Protoc ol Simulation Results and Analysis Simu lations are first performed to test th e backbone torus netw orks access control protocols. The two designs are simulated individually first and their performance is tested using average packet latency and throughput as the me trics. Later a comparative analysis is done

PAGE 94

94 between the two proposed routing protocols. In both the simulations, the offered load to the backbone network from each sub-system controller is increased and the performance is measured for each increase. The next simulation to test th e backbone network is usi ng a base configuration topology; with each sub-system defined to generate a particular amount of traffic that is comparable to an actual data traffic onboard a commercial and military aircraft. For all the simulations for the backbone network the simulati on parameters assumed are: the fiber link of 100m length; laser transmission speed of 1Gbps ; fixed payload size of 1000 bytes for MLP traffic and HP packets have a payloa d size between 100 bytes and 1000 bytes. Design I: Broadcast and Select Protocol Simulation Results The broadcast and select type routing protoc ol is the Design I rou ting protocol for MLP traffic in the backbone torus archit ecture. The first performa nce metr ic used is the average packet latency. The offered load from each sub-system controller is increased from 250Mbps upto 2000Mbps in reasonable incremental steps and the average packet latenc y is calculated. The average latency computed for the MLP packets is sub-divided as intra-ring communication and inter-ring communicatio n latency and analyzed individually to get a better unde rstanding of the networks performance. The latenc y performance is analyzed for di fferent types of traffic patterns and is illustrated in Figure 6-4. Figure 6-4 (A) illustrates the case if all the nodes generate periodic background traffic. As the medium prior ity packets are serviced ahead of low priority packets they have lower average packet latenc y values when compared to the low priority packets. The medium inter-ring communication p ackets have higher latency when compared to the intra-ring communication as such packets ha ve an additional O-E-O delay in transmission. The low priority packet latency is high when compared to medium priority packets and its follows a trend very close to medium priority packets till the offered load is 1000Mbps, after which the average latency shoots up. This is be cause, 1000Mbps is the laser transmission speed

PAGE 95

95 and beyond which the MLP packets fills their corr esponding queues. So, low priority packets are not given preference when compared to the medi um priority packets in terms of transmission. Figure 6-4. Average Latency for Design I broadcas t and select protocol for different traffic patterns, A) Periodic traffic t ype, B) Poisson traffic type, and C) Bursty traffic type Figure 6-4 (B) shows the case where Poisson tr affic pattern is used for background traffic and the average latency performan ce is pretty much similar to periodic traffic pattern as they maintain almost the same trend and pattern. Figur e 6-4 (C) illustrates the case with bursty traffic is filled in the backbone torus network. Here the average latency values shoots up for both the A B C

PAGE 96

96 medium and low priority packets. This is because of a very dense burst period that results in a lot of packets being generated in a very fast rate and their corresponding transmission queues gets filled up very soon. As a result the latency of all the packets increases exponentially as the offered load in the network increases. Compari ng all the three graphs in Figure 6-4, one could come to conclusion that the network performs bette r to periodic traffic as the average latency is lower even when the offered load/contr oller to the networ k is increased. The packet latency metric shows an importa nt merit of the proposed XYTARP protocol when used for audio and video streaming applica tions. The Voice over Inte rnet Protocol (VoIP) provides a QoS support to callers with round trip voice delays of 100ms or more, taking into account the jitter effects also [12]. The average latency metric observed for all the different traffic patterns are well within the VoIP one way round trip delay valu es and thus the XYTARP protocol is perfect for str eaming applications as well. Figure 6-5. Throughput performance for Design I broadcast and sele ct protocol under different traffic patterns The throughput performance of the broadcast and select prot ocol for different traffic patterns and varying offered load is illustrated in Figure 6-5. The thr oughput of the backbone

PAGE 97

97 network is observed to saturate near 20Gbps when all the sub-syst em controllers are operating in their full transmission capacity. As the offered load is increased the thro ughput increases linearly till it reaches its saturation value. The performa nce of periodic and Poisson traffic pattern in terms of throughput is almost the same and follow the similar trend. The bursty traffic reaches its saturated network throughput pretty slowly when compared to the other traffic patterns because of the dense traffic generated in the burst duration and also takes time to be delivered. Design II: OTDM/WDM Prot ocol Simulation Results Figure 6-6. Performance analysis of OTDM/WDM pr otocol, A) Average late ncy for varying load and different traffic patterns (OTD M_2), and B) Throughput comparison among different OTDM protocols As discussed in the earlier chapters three variants of OTDM/WDM protocol have been proposed with different time slot allocation strategies. Three tra ffic patterns (periodic, Poisson and Bursty) are used to test network performa nce in terms of network throughput and average latency of each packet. Figure 6-6(A) compares average latency of each packet versus the offered traffic load for different traffic patterns. There is not much diffe rence between periodic and Poisson traffic because the randomness in pa cket generation interval decreases due to the A B

PAGE 98

98 time spent in waiting for the time slot. The averag e latency for the bursty source is much higher and starts to greatly increase when the offered load is ar ound 500 Mbps. The reason is that a large number of packets are being generated in a short burst peri od and are queued for transmission. For simplicity the OTDM_2 average latency performance alone is shown in Figure 6-6(A), as the other OTDM protocols also tend to maintain the same trend. Figure 6-6 (B) shows the variation of throughput with increasing traffic load from each controller node for the three ti me-slot allocation strategies. The throughput of the network saturates when the offered load per controller node reaches 1250 Mbps as all the transmitters operate at full capacity. However the saturated valu e is better for OTDM_3. This is due to the saving of two guard periods between consecuti ve time slots and also using an array of transmitters compared to tunable lase rs employed in OTDM_1 and OTDM_2. Comparative Analysis of Design I and OTDM/WDM Protocol Figure 6-7. Comparative performance analysis of Design I and OTDM/WDM protocol, A) Medium priority inter-ring average late ncy, and B) Medium priority inter-ring average latency for varying load and di fferent traffic patterns (Design I and OTDM_2) A B

PAGE 99

99 The two access protocols proposed for the XYT ARP backbone torus architecture fare well in performance and have their own advantages. In order to draw a fair comparison between the two protocols the average packet latency and throughput are again used as a measure. The Design I (broadcast and select pr otocol) performs better than th e OTDM protocol because, the time slot allocations in OTDM pr otocols along with the use of tuna ble laser makes the packets to wait for their chance to transmit. This overhead affects the performance mainly in case of the bursty traffic load. Figure 6-7(A) and (B), illustrates the comparison between Design I and OTDM_2 in terms of average packet latency for medium inter-ring communication and intraring communication for varying tra ffic load and different traffic patterns (periodic and Poisson). As explained the Design I outperforms the OTDM protocol. The same trend continues for the low priority average packet latency as well. Figure 6-8. Comparative performance analysis of Design I and OTDM/WDM protocol, A) Throughput comparison for periodic traffi c, and B) Throughput comparison for bursty traffic Figure 6-8 (A) and (B) illust rates the comparison between the two protocols throughput performance for varying traffic loads and traffic patterns (Periodic and Bursty). As expected the broadcast and select type protoc ol has better throughput saturation when compared to the OTDM A B

PAGE 100

100 protocol because of the same reason as stat ed for average packet latency case. Another interesting thing to be noted is that both protocols reac h saturation values faster in periodic an Poisson traffic types when compared to the bursty traffic due to the heavy packet generation in the burst duration. For comparison OTDM_2 de sign was chosen, but the OTDM_3 design is expected to have the same perfor mance as that of broadcast and se lect design, due to use of array of transmitters and ideal time slot allocation. Backbone Network Performance with Base Traffic Table 6-1. Th e MLP backbone toru s base traffic configuration Controller Medium Priority Low Priority 11 Bursty, 400 Mbps Poisson, 300 Mbps 12 Poisson, 800 Mbps Periodic, 700Mbps 13 Periodic, 450Mbps Bursty, 450Mbps 14 Periodic, 850 Mbps Bursty, 100 Mbps 21 Periodic, 750 Mbps Poisson, 200Mbps 22 Bursty, 500 Mbps Periodic, 850 Mbps 23 Bursty, 800 Mbps Periodic, 350 Mbps 24 Poisson,750 Mbps Bursty, 200 Mbps 31 Periodic, 200 Mbps Bursty,500Mbps 32 Periodic, 400 Mbps Bursty, 250 Mbps 33 Bursty, 100Mbps Poisson, 300 Mbps 34 Poisson, 650 Mbps Periodic, 450Mbps 41 Bursty, 550 Mbps Periodic, 700 Mbps 42 Poisson, 800 Mbps Bursty, 250 Mbps 43 Periodic, 600 Mbps Poisson, 650 Mbps 44 Periodic, 750 Mbps Bursty, 100 Mbps So far the network performance for MLP tra ffic in accordance to the two proposed access control protocol was analyzed in depth with varying traffic loads from each sub-system controller. In order to mimic an exact scenario inside a military aircraft a backbone base traffic

PAGE 101

101 configuration was assumed and the network simula tion is carried out to test the performance. The assumed base traffic configuration is shown in Table 6-1. The packet size was assumed as 1000 bytes and the broadcast and select access protocol is used for the simulation. The performance is ev aluated in terms of network throughout, MLP average packet latency that includes both the intra-ring and inter-ring communication in the backbone network. The results ar e tabulated in Table 6-2. Table 6-2. Base traffic configuratio n results for the backbone network Throughput 15.486 Gbps Medium Intra 15.67 s Medium Inter 30.98 s Low Intra 3121.97 s Low Inter 4842.52 s The XYTARP Access Network Simula tion Results and Analysis So far the backbone networks performance alone has been tested using simulative analysis and results. That too the MLP tra ffics performance has been rigorous ly tested with respect to the designed protocols in the torus ne twork. The HP traffic has not been introduced and tested for obvious reasons, as it is more deterministic in nature and that too there are only seven HP sourcedestination sub-system controllers that generate HP traffic. Now in order to get more insight into the networks functioning, lets test the second tier architecture or the access network with the actual data generating nodes. In these simulati ons the nodes with capabili ty of generating HP traffic are permitted to generate them and the corresponding average latency and their contribution to the overall networks throughput is analyzed.

PAGE 102

102 Figure 6-9. Average Latency for second tier access ne twork with different traffic patterns, A) Periodic traffic type, B) Poisson traffi c type, and C) Bursty traffic type In these simulations, a 4x4 backbone torus ne twork is assumed with 16 data generating nodes in the second tier and by varying the traffic load offered by each of these nodes from 10Mbps to 120 Mbps in incremental steps 10M bps simulations are performed. The average packet latency from the packets generated in s econd tier with varying offered traffic load and traffic patterns is illustrated in Figure 6-9. The MLP traffics intra-ring latency and the inter-ring latency maintain the same trend in terms of performance compared to the backbone network. The A B C

PAGE 103

103 high priority packet latency is ve ry close to the medium priority packet latency performance at higher traffic loads. It initially maintains a constant latency and starts increasing linearly after 60Mbps in case of periodic and Poisson traffic patterns. For bursty traffi c pattern, all priority packets latency shoots up at very early values of offered load due to dense burst durations. Out of the three traffic patterns, the bursty pattern perf orms poorly and this is on expected lines. Even the HP traffic has high latency values at very traffic load values from each node in the second tier access network. Figure 6-10. Throughput performance for second tier access network with different traffic patterns The throughput of the network with varyi ng traffic loads from each node and varying traffic pattern is illustrated in Figure 6-10. As the traffic lo ad from all the 256 nodes in the network is increased, the throughpu t of the network also tends to increase linearly and then saturate after some time. But the throughput saturation here is very slow and can only be observed as a decrease in the fast linear increa se in the throughput valu e with increasing offered traffic load. The bursty traffic s eems to provide higher throughput in itially because of the initial rush in packets when the traffic load is low a nd less contention, but then reaches almost the same

PAGE 104

104 value as the other traffic patterns later. As the lo ad offered increases all the traffic patterns have almost the same saturation throughput. The bursty traffic pattern is simulated with a burst factor of 50. Varying this parameter and the peak rate of transmission, different saturation values and trends can be observed. The XYTARP Architecture Backbone Torus Fa ult Tolerance Simulation Analysis and Results Designing any system to tolerate faults first requ ires the selection of a fault m odel, a set of possible failure scenarios along w ith an understanding of the fre quency, duration, and impact of each scenario. A simple fault model merely lists th e set of faults to be considered; inclusion in the set is decided based on a combination of expected frequency, impact on the system, and feasibility or cost of providi ng protection. Most reliable network designs address the failure of any single component, and some designs tolerate mu ltiple failures. In contrast, few attempts to handle the adversarial cond itions that might occur in a terrorist attack, and cataclysmic events are almost never addressed at any scale larger than a city. The temporal characteristics of faults vary widely, but can be roughly categorized as permanent, intermittent, or transient. Failures that prevent a component from functioning until repaired or replaced, such as th e destruction of a network fiber by a backhoe, are considered permanent. Failures that allow a component to f unction properly some of the time are called intermittent. Damaged connectors and electri cal components sometimes produce intermittent faults, operating correctly until mechanical vibrations or thermal variations cause a failure, and recovering when conditions change again. The last category, tran sient faults, is usually the easiest to handle. Transient faults range from cha nges in the contents of computer memory due to cosmic rays, to bit errors due to thermal noise in a demodulator, and are typically infrequent and unpredictable.

PAGE 105

105 Table 6-3. The HP base traffic configuration Source Destination Traffic type Parameter(s) Cockpit Wing1 Poisson Average rate: 500Mbps Packet size: 100bytes Cockpit Wing2 Poisson Average rate: 350Mbps Packet size: 100bytes Cockpit Weapon subsystem1 Bursty Average rate: 500Mbps Peak rate: 750Mbps Burst factor: 1000packets Packet size: 200bytes Cockpit Weapon subsystem2 Bursty Average rate: 500Mbps Peak rate: 750Mbps Burst factor: 1000packets Packet size: 200bytes Cockpit Engine Bursty Average rate: 150Mbps Peak rate: 500Mbps Burst factor: 100 packets Packet size: 100 bytes Cockpit Tail Poisson Average rate: 100Mbps Packet size: 500 bytes Wing1 Cockpit Periodic Average rate: 100Mbps Packet size: 1000bytes Wing2 Cockpit Periodic Average rate: 100Mbps Packet size: 1000bytes Weapon subsystem1 Cockpit Bursty Average rate: 100Mbps Peak rate: 200Mbps Burst factor: 1000packets Packet size: 500bytes Weapon subsystem2 Cockpit Bursty Average rate: 100Mbps Peak rate: 200Mbps Burst factor: 1000packets Packet size: 500bytes Engine Cockpit Periodic Average rate: 500Mbps Packet size: 200bytes Tail Cockpit Periodic Average rate: 250Mbps Packet size: 100bytes Wing1 Wing2 Bursty Average rate: 250Mbps Peak rate: 750Mbps Burst factor: 500packets Packet size: 100bytes Wing2 Wing1 Bursty Average rate: 250Mbps Peak rate: 750Mbps Burst factor: 500packets Packet size: 100bytes Based on the above observation of faults in a network and in order to mimic an exact aerospace environment problem two experimental scenarios have been designed for simulation. In these simulations the main aim is to test th e backbone networks fault tolerance as standalone

PAGE 106

106 architecture. For fault tolerance simulations, a base traffic configuration with a combination of traffic types and average rates are assumed for MLP and HP traffic. The HP base traffic configuration is given in Table 6-3. The two experimental sc enarios modeled can simulate upto 16 network faults. Scenario 1 is a distributed occurrence of faults executed in a best case scenario. In other words, distributed faults ar e introduced in such a way that all the X and Y direction rings are able to be sw itched for the MLP traffic. Scenar io 2 depicts almost a worst case of fault distribution in the netw ork, where four leading diagonal c ontrollers are modeled to be in fault by executing breaks at all four inputs of eac h of the faulted controllers. These two extreme scenarios test the flexibility of the backbone torus network in terms of fault tolerance. Average Packet Latency Table 6-4. Average packet latency for high, m edium and low priority packets in presence of faults Table 6-4 shows the average packet latency for high, medium and low priority packets exchanged between different sub-systems in the presence of a varying number of faults. The medium and low priority traffic is simulated with the base traffic configuration, while, because of the deterministic nature of the routing paths, only one source-destinati on pair (e.g., cockpit to Number of Faults Average Packet Latency (ns) High Priority Medium Priority Low Priority Periodic Poisson Bursty 0 8500 12545 79926 30886 2498849 1 9500 13545 80926 30886 2498849 2 9500 13545 80926 56654 6920707 3 9500 13545 80926 56654 6920707 4 57822 7780294

PAGE 107

107 tail) of the high priority genera ting nodes is presented. The averag e rate for high priority traffic with periodic, Poisson and bursty traffic types are set as 500Mbps and the bursty traffic has a peak rate of 1000Mbps and burst factor 100. When there are no faults in the network, the high priority receiver reads the data from the shortest hop length lightpath buffer. In the even t of a fault it switches to the next shortest lightpath buffer. For the chosen pair of sub-sy stems the path hop lengths are 1, 3, 3 and 3. Since the hop lengths are same except for the first shor test path, the average latency for 1, 2 and 3 faults for high priority are the same. The averag e latency for Poisson and bursty traffic are high because the average packet genera tion rate is high when compared to the lasers transmission rate, and thus causes packets to be buffered. But the tr end with the number of faults is maintained. The high priority cannot handle 3 fa ults in a worst case s cenario as shown, where the faults occur in the distinct lightpaths. The average latency for medium priority packets is observed to be very low when compared to the low priority packets as they are given first preference to be served. No change in latency is seen for MLP in case of 1 and 3 faults, because the faults that were introduced are not part of the current working rings. LSN Latency The Link Status Notific ation (LSN) latency metric reflects the time taken for the link status notification packets to convey an instance of fault to the entire network. This measure is purely dependent on the location of the fault and also the current status of the network, because if there are many faults in the network it takes a long ti me for the entire networ k to propagate messages about a fault. Even so, the LSN latency should not be too high, as this wi ll cause packets to be routed based on the previous entries in the routing table and eventu ally being dropped. The special broadcast nature of the LS N packets ensure that the inform ation is conveyed to the entire network with low latency, even in th e presence of dist ributed faults.

PAGE 108

108 Figure 6-11 shows the resulting latency for an instant in which the fiber link between node 11 and 12 is down. Each bar shows the time taken by the different controllers in the network to find out about the event. We note that Controller 12 has zero latency, since it is the node that identifies the fault and is the source of the br oadcast LSN packet. From observation, controller 41 is the last to receive the LSN update in this ca se and this is because of its relative position in the network. From a series of different experime ntal scenarios with different number of faults, the maximum LSN latency is observed to be 4480ns, which is a reasonable value, given the parameters for the network. Figure 6-11. The LSN latency for a li nk failure between controller 11 and 12 Dropped Packet Ratio Dropped packet ratio gives a precise estimate of the num ber of packets dropped when compared to the transmitted packets. There is always a possibility of packets that are in transit to be dropped when a fault occurs in a working ring for MLP traffic. For the best case Scenario 1, i.e., distributed faults, the dropped packets are sh own in Figure 6-12. The first 8 faults only cause packets to be switched from the 8 faulty rings to the redundant opposite direction working rings,

PAGE 109

109 so the number of packets dropped is very low. This could be observed as a flat line in Figure 612. After these 8 faults, any fault in the networ k causes the MLP packets to either use the FWD route or be dropped due to isolated destinations This affects the dropped packet ratio, as Figure 6-12 shows that it increases drama tically after the first 8 faults. The worst case Scenario 2 models localized faul ts or controller faults Here the controllers output ports are subjected to fau lt in an orderly way, starting with the east port and continuous in the clockwise direction. Some flat portions appear in the graph because of the way that the faults are introduced. If no ring switching is required, no extra packets ar e dropped. Eventually after 16 faults the situation becomes the same for both sc enarios with a high packet drop ratio of nearly 0.58. Another important result here is that, the netw ork sustains 3 faults for the MLP traffic with a negligible dropped packet ratio. Figure 6-12. Fault tolerance in terms of dropped packet ratio vs number of faults Network Throughput The networks throughput is analyzed for both scenarios in the presence of faults and presented in Figure 6-13. The di stributed best case Scenario 1 ma intains the network throughput

PAGE 110

110 until the eighth fault, and then degrades drama tically. In Scenario 2, the faults are localized around each of four controllers. Thus, the through put falls right after the first controllers isolation of four faults. After 16 faults, both scenarios have almost similar network throughput. Figure 6-13. Fault tolerance in terms of network throughput vs number of faults The XYTARP Architecture Access Network Fa ult Tolerance Simulation Analysis and Results Efficient fault models were created to test the backbone networks reliability and fault tolerance properties. Now with the addition of se cond tier architecture and its own fault tolerance properties the network is expected to perform well in faulty scenarios. So far only link failures were modeled in the backbone network, and now with the addition of the access network the potential controller failure and also a fiber link failure can be modeled. From an access networks point of view, a controller fault is modeled in Artifex by breaking all the fiber links around the controller both in the star topo logy and also the backbone torus. To overcome a faulty controller

PAGE 111

111 scenario, the nodes start forwarding the pack ets via the second tie r outlet nodes to the neighboring controller an d then routed through the backbone network. An experimental scenario is created to test the second tier fault tolerance properties. In order to test the HP traffic re -routing due to faults, lets just monitor a particular sourcedestination pair of sub-system and analyze the effects of fault tolerance using metrics like average packet latency and network throughput. E qual traffic load of high, medium and low priority is assigned to each node but lets just focus on the high pr iority traffic from cockpit to wing 1. Simulation is performed with varying traffic loads from 1Mbps to 35Mbps at each node. Two separate simulations are performed; one to test the normal performance in the absence of faults and compare with anothe r case with faults introduced. Figure 6-14. Second tier HP fault tolerance test using average p acket latency metric (cockpit wing 1 subsystem) The second tier HP traffic fault tolerance is fi rst evaluated using the average packet latency metric in the proposed experimental setup and is illustrated in Figure 6-14. When there are no

PAGE 112

112 network faults and that too at the simulated offere d load rates, the HP traffic with the help of their dedicated lightpaths reach the destination in no time. And so the latency graph for the no fault case is flat in profile. Si nce high-priority packets have to go through first-tier medium/low structure and extra seco nd-tier outlet-outlet/TDM based ring structure, the latency after Wing1 controller fails is always much larger than that without Wing1 c ontroller failure. However, after offered load from each node reaches 10 Mbps, the average latency for controller failure case starts rising linearly. As the offered load from each node increases, due to a faulty controller the nearby neighboring controllers are re ceiving extra traffic and as thes e controllers capacity limits are reached, packets queueing time increases. This is the reason for the shoot up in the average packet latency value. Figure 6-15. Second tier HP fault tolerance test using network throughput metric (cockpit wing 1 subsystem) The comparison of the two scenarios is tested with respect to throughput metric and is illustrated in Figure 6-15. It is observed that as the offered load from the node increases the

PAGE 113

113 throughput for both the scenarios keep on increasing linearly until a certain poi nt. After this point also the no-fault scenarios throughput is still seen to be increasi ng whereas the faulty scenario reaches a saturation throughput value. This is main ly attributed to the fact that the neighboring controllers also reach their transmission capacity and the packets would take a long time to be delivered in such a case. The s econd-tier capacity for to lerance of controller failure under current design is around 0.35 Gbps for a specific highpriority source-destination pair, while the throughput for corresponding source -destination in case of no cont roller failure keeps increasing after saturation point in case of failure. Summary Thus the proposed arch itecture and the access co ntrol protocols are tested for the required performance levels using multiple simulation scenarios. A comparative analysis of the two proposed backbone access control protocols is do ne and the broadcast and select protocol outplayed the OTDM protocol due to proven reasons. The XYTAR P architecture is proved to sustain the first two faults with no change in the performance and the third fault is handled gracefully. Depending on the type and location of fault, the network has proved its ability to handle multiple faults and provide the required QoS.

PAGE 114

114 CHAPTER 7 SUMMARY AND CONCLUSION Optical networking is expected to play a significant role in improving performa nce and reliability in future civil and military avionics sy stems. As a part of the STTR project we began with analysis of the generic requirements for a future avionics WDM LAN based systems and have done an extensive research in terms of c hoosing an optimal candidate architecture for the current application. The proposed XYTARP archite cture for WDM LANs is a scalable, and a more reliable optoelectronic ar chitecture that is designed fo r use in the hostile aerospace environment. Various avionics sub-systems with varied traffic requirements motivate the idea of prioritization of traffic in the network and effi cient wavelength allocation schemes and routing protocols have been proposed. A number of opera tion modes intended for different classes of traffic have been considered a nd the network is expected to s upport a variety of standardized protocols. The fault tolerant algorithm is proposed w ith the idea that it should not affect the performance in the absence of fau lts and show very little degrad ation in the presence of faults. The proposed architecture allows the network to meet a three-fau lt tolerance. The high priority packets can sustain three distribut ed faults in its dedicated ligh tpaths without any packets being dropped and with the least possible latency. The fault tolerance for medium and low priority packets is observed to be dependent on the lo cation and the time of occurrence of fault, but performance does not significantly degrade until a ha ndful of faults have occurred. However, to achieve such levels of reliability and fault tolerance, the network architecture involves some redundant optical fibers a nd optical components. The design of a novel and an appropriate archit ecture for the avionic applications was one of the major contributions from this thesis work. The mesh torus archit ecture has bridged the

PAGE 115

115 needs of the current application with its scalab ility, redundancy and its ability to support fault tolerance. The mesh like nature of the torus proposed provides each controller with four neighbors and thereby paving way for easy and r obust fault tolerant routing protocols. The second tier semi-torus architecture also supports the backbone architecture to tolerate faults effectively. Resource allocation and routing pr otocol design was another contribution as a part of this thesis. The circular wavelength assignment strategy suits the b ackbone architecture and improves the wavelength utilization in the network. The XYTARP accompanied with two robust routing protocols serves well for fault tolerance applicat ions. The latency and th roughput results stand as a proof of merit for the proposed architecture and the routing prot ocols. The packet latency is very low when compared to normal copper cables, and thus eases the use of the routing protocol for applications with audio and video streaming. The final but most pivotal contribution of this thesis work was the fault tolerance analysis of the XYTARP protocol. The faul t tolerant routing permits the network to handle the first two faults without changes in terms of performance. The third fault was observed to be handled by the network with little performance degradation but without affecting the functionality of other neighboring communications. The proposed routi ng protocols and the ar chitecture is highly reliable and was proved to tolerate more than three faults depending on the place of occurrence of the fault in the network.

PAGE 116

116 LIST OF REFERENCES 1. R. D. Gardner, I. Andonovic, D. K. Hunter, A. J. McLaughlin, J. S. Aitchison, J. H. Marsh, "High performa nce photonic avionics networking using WDM," Military Communications Conference Pr oceedings, 1999. MILCOM 1999. IEEE vol.2, no., pp.958-962 vol.2, 1999 2. C. Reardon, J. Profumo, A. D. George, Wavelength Division Multiplexed (WDM) Fiber-Optic Network Architecture Analysis, Modeling, Optimization and Demonstration for Aerospace Platforms, NAVY STTR Phase 1 Report Period September 13, 2005 through February 28, 2006. 3. A. Kumar, M. Sivakumar, D. Wang, J. Y. McNair, Wavelength Division Multiplexed (WDM) Fiber-Optic Network Architectur e Analysis, Modeling, Optimization and Demonstration for Aerospace Platforms, NAVY STTR Phase 2 Report Period May, 2007 through June, 2008. 4. D. Wang, Optical components modeling in Artifex and DRAGON library development, Technical Report #7007-5, Wireless and Mobile Systems Laboratory, University of Florida, October 2006. 5. Marco Baldassari, Riccardo Benso, Roberto Pane, Modeling WDM Protocols and Networks Using the Artifex Environment, Photonics East '99 proceeding Technical session: All-Optical Networki ng: Architecture, Control, and Management Issues 1999 (VV04). 6. C. Reardon, J. Profumo, A. D. George, "Compa rative Simulative Analysis of WDM Lans for Avionics Platforms," Military Communications Conference, 2006. MILCOM 2006 vol., no., pp.1-7, 23-25 Oct. 2006. 7. A. Kumar, M. Sivakumar, M., M. T. Stringe r-Blaschke, J. Y. McNair, "Priority-Based Ring-Hybrid WDM LANS for Avionics," Avionics, Fiber-Optics and Photonics Technology Conference, 2007 IEEE vol., no., pp.58-59, 2-5 Oct. 2007. 8. H. N. Poulsen, D. H. Richards, A. Ramapanicker, D. J. Blumenthal, "Network Layer Modeling of WDM Fiber Optic Network Architectures for Aerospace Platforms," Avionics, Fiber-Optics and Photoni cs Technology Conference, 2007 IEEE vol., no., pp.60-61, 2-5 Oct. 2007. 9. C. Kochar., A. Kodi., and A. Louri., "nD-RAPID: a multidimensional scalable faulttolerant optoelectronic interconnection fo r high-performance computing systems," Journal of Optical Networking, May 2007 pp. 465-481. 10. A. Kumar, M. Sivakumar, D. Wang, J. Y. McNa ir, Effect of Traffic patterns on optical time-division-multiplexed/WDM networks for avionics, accepted at Avionics, FiberOptics and Photonics Technology Conference 2008. 11. W. Stallings, Data and Computer Communications, ed. 7, Prentice Hall, 2004.

PAGE 117

117 12. A. P. Da Silva, M. Varela, E. de Souza e Silva, R. M. Leo, G. Rubino, Quality assessment of interactive voice applications, Comput. Netw. 52, 6 (Apr. 2008) 11791192.

PAGE 118

118 BIOGRAPHICAL SKETCH Arvindhan Kumar graduated with a B.E., in Electronics a nd Communication Engineering from Anna University, India, in 200 6. His area of research du ring the undergra duate education was Multi-carrier modulations and OFDM in particul ar. He is currently doi ng his M.S. Thesis in Electrical and Computer Engineering at the Universi ty of Florida. He is a Research Assistant at the Wireless And Mobile Systems (WAMS) Laborat ory, University of Florida, and his current research focuses on WDM LANs for Avionic ne tworks, resource allocation, routing protocol design, and network management. He has been an active student member of Institute of Electrical and Electronics E ngineers, Inc. (IEEE) for the past three years.