No abstract

No abstract

The demand for 100 Gb/s optical links is rapidly spreading across all levels of the optical networking infrastructure. Many of the first deployments will be in the local area network (LAN) and metro-core and regional network environments. To address needs in LAN, the upcoming IEEE standard (IEEE P802.3ba) seeks 100 Gb/s over distances up to 40km. Furthermore metro-core/regional dense wavelength division multiplexing (DWDM) architectures require reach of several hundred km and the ability to pass through ten or more ROADMs. However, a number of fundamental challenges remain including the selection of appropriate modulation formats that are robust to a variety of nonlinearities, are sufficiently spectrally efficient, and able to withstand the strong optical filtering of cascaded ROADMs. Here we compare a variety of single-carrier quaternary modulation formats, each providing 2 bits/symbol/polarization and each likely to provide some advantages at 100Gb/s. Each format is presented with an appropriate MZM-based transmitter, and constrained by practical signal fidelity limitations that also enable comparison to experimental results from our 100G testbed. We primarily examine direct detection for cost-sensitive metro networks; however we also quantify the performance of coherent receivers, where applicable. Simulation results demonstrate the relative OSNR penalty (at a pre-FEC BER of 10 -3 ) for a range of launch powers and adjacent channel formats.

Networks are transitioning from TDM to packet transport optimized architectures. Packet networks are based on technologies traditionally lacking OAM tools. We will present the OAM tools being developed and their application to the transport layers. Packet networks environmentWAN and MAN networks are transitioning from TDM to packet transport optimized architectures; this change is driven by the large increase in data traffic and the need to support this growth with networks that are cost effective and future proof. Networks optimized for packet transport take advantage of statistical multiplexing over wide transmission "pipes" and are not constrained to the rigid SONET containers.Some of the technologies developed for packet transport include powerful OAM tools. The best example in this category is ATM. ITU-T I.610 [1], defines a full set of OAM tools for ATM. Nevertheless ATM OAM has not been widely deployed (even though some of the defined OAM tools are common practice) and ATM seems to be loosing ground to other technologies due to factors not related with its OAM capabilities.The prevailing technologies on which packet networks are being build traditionally lack OAM tools. Some of them, like Ethernet, were developed for LAN environments where the added value of OAM tools is low; others, like IP/MPLS, were developed primarily to "move" large amounts of data without SLA guarantees, mostly in a besteffort manner.Small networks owned by a single organization who is also the only customer of the network services, can be operated without automated and powerful OAM tools. LAN networks are a good example of these types of networks. But, large networks that may be owned by several organizations and provide services to several customers, present new challenges on the area of cost effective maintenance. This fact has been recognized by the main standard bodies and efforts are being made to define OAM tools that will promote the acceptance of these technologies in the MAN and WAN environment. OAM definitionOperation, Administration, and Maintenance (OAM) is a group of management functions and tools that provide network fault indication, performance monitoring, diagnostic and testing functions, configuration and user provisioning.In this paper we will concentrate on two issues of OAM: fault management and performance monitoring. Fault managementFault management includes alarm surveillance, fault localization, fault correction and testing. Alarm surveillance provides the capability to monitor failures detected in the network elements (NEs). In support of alarm surveillance, the NEs should perform checks on hardware and software in order to detect failures, and generate alarms for such failures. Upon detecting a failure, in addition to generating and sending alarms to the management system, the NEs should also send indications in the forward and backward directions in order to notify downstream/upstream NEs that a failure has occurred (and some action may be required). Fault localization determines the root cause of a failu...

No abstract