If your company is like most that are involved with building or utilizing fiber optic systems, chances are you have a few spools of bare optical fiber laying around the lab.  Since it is critical to ensure fiber-based equipment works as intended prior to deployment in the field, it is a recommended and common practice for engineers to simulate networks using spools of bare optical fiber.  Because there have been a variety of different fibers available over the years, engineers can end up with fair amount of spools at their disposal.

Traditionally, products have gone down the path of modularity for two reasons: cost and/or ease of replacement without effecting existing services.  When the LGX form factor was first created for optical splitters, it made sense to have a modular approach for the first reason and to a lesser extent, the latter reason.  When optical splitter modules were first put into the LGX form factor, the cost per splitter was considerably higher than it is today. Therefore, inserting modules into a chassis became a cost effective way to “grow” as needed.  At the same time, the quality of those modules was not as high nor as repeatable as it is today, so despite any changes being service effecting (passive elements are not capable of protection switching around an outage) having the ability to replace the modules was also a key advantage.

In recent years, companies have shown the benefits of “copying” and sending traffic from network backbones to purpose-built monitoring devices…no interference with the existing, “live” traffic and the traffic can be analyzed in real-time or stored for later playback. However, the best approaches to “copying” and sending the traffic to be monitored has been a source of contention.  As 40/100G becomes more prevalent, how the traffic is accessed will become increasingly important.

Initially, the Switched Port Analyzer (SPAN) ports were used to deliver copies of traffic to analyzers, but this has posed several problems at the 1G and 10G data rates, which likely will increase exponentially with 40/100G:

• SPAN ports are part of the switch/router and operate in much the same way as typical ports, so the data is not always an exact copy
   
• Traffic congestion both on the router and on the SPAN port itself can result in increased latency or the traffic to be dropped completely
   
• Relying on a device that could be creating the problem to help identify it can be a self-defeating exercise
   

Learning to operate an OTDR properly is a critical skill for field technicians managing and servicing fiber optic networks.  The OTDR is used frequently to determine length and loss characteristics, including testing optical fibers for faults and related issues that can negatively affect network performance.

As virtualization and cloud applications become more and more prevalent in Data Centers, POPs, Head-ends, and Central Offices, the available rack space needed to house the equipment for these applications is shrinking.  While the space needed to store, process, route, or switch the data becomes more compact, one thing that remains difficult to reduce is the physical layer infrastructure. As traffic enters or exits a facility, most providers want the capability to monitor what is being delivered or sent to/from their site. At the larger sites, this data traffic is riding on fiber, and in many cases, there are a number of fibers coming into or out of a given site. To be able to accurately monitor this traffic, a passive optical tap is used to duplicate the traffic and send it to a monitoring device that can analyze the header information native to the traffic type.  In the past, these optical taps were relatively expensive and bulky. Even today, most vendors cannot provide more than 24 taps in a single 1RU footprint. 

With most of the world now relying on fiber optic systems for communication, a key component to ensuring a high level of performance from operators is network monitoring.  When we think of network monitoring, much of the focus is usually on the equipment itself, as well as the management of all the data flowing through the system.  As a result, an area often overlooked when deploying and monitoring a network is the actual fiber optic cable, through which all the data is sent from one location to another.

This new, free whitepaper from M2 Optics Inc. discusses the importance of simulating a physical fiber optic network in the laboratory and best practices for achieving maximum results.
 

As the demand for faster speeds has grown rapidly over recent decades, new communications networking equipment and systems are constantly being developed to accommodate these requirements. One result of these efforts is a series of established networking protocols and terminology that are used to identify various speed thresholds and the related equipment.

Latency is a term that is used to describe a time delay in a transmission medium such as a vacuum, air, or a fiber optic waveguide.  In free space, light travels at 299,792,458 meters per second.  This equates to 299.792 meters per microsecond (µs) or 3.34µs per kilometer.  In fiber optics, the latency of the fiber is the time it takes for light to travel a specified distance through the glass core of the fiber.  Light moving through the fiber optic core will travel slower than light through a vacuum because of the differences of the refractive index of light in free space and in the glass.

An Optical Time Domain Reflectometer (OTDR) is an optical measurement instrument designed to detect faults, splices and bends in optical fiber cables.  It functions by launching pulses of light into the optical fiber and measuring the back reflections created by the faults, splices, and bends.  It can identify the exact location of the fault by measuring the round trip time from the launch to the detection of the reflected returning pulse.  The time is determined by the speed of light in the glass core of the optical fiber.