RFC 4054

Impairments and Other Constraints on Optical Layer Routing

📅 published May 2005, from ietf

RFC 4054: Impairments and Other Constraints on Optical Layer Routing 🦋✨

Bestie, this is the title block 📋. It's an Informational RFC from May 2005, from the Network Working Group. The editors are J. Strand, Ed. and A. Chiu, Ed., both from AT&T 💅. It's not a standard, just a survey 🌸. The title block doesn't list anything it obsoletes or updates.

Status of This Memo 📝

This memo gives information to the Internet community. It does not specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited 💖.

Copyright (C) The Internet Society (2005) 🎀.

Abstract 🌈

Okay so, optical networking throws a bunch of curveballs at GMPLS (Generalized Multi-Protocol Label Switching) 😭. Optical tech is analog, not digital, and the optical layer sits at the very bottom of the transport hierarchy. That means it's super intimate with the physical geography of the network 🗺️✨.

This doc looks at the optical network stuff that affects routing and suggests possible GMPLS responses for each one. There are four buckets: (1) constraints from designing new software-controllable network elements, (2) constraints in a single all-optical domain with no wavelength conversion, (3) complications in bigger networks that mix all-optical and opaque architectures, and (4) the impacts of diversity constraints 👑.

Table of Contents 📚

1.  Introduction .................................................  2
2.  Sub-IP Area Summary and Justification of Work ................  3
3.  Reconfigurable Network Elements ..............................  3
    3.1.  Technology Background ..................................  3
    3.2.  Implications for Routing ...............................  6
4.  Wavelength Routed All-Optical Networks .......................  6
    4.1.  Problem Formulation ....................................  7
    4.2.  Polarization Mode Dispersion (PMD) .....................  8
    4.3.  Amplifier Spontaneous Emission .........................  9
    4.4.  Approximating the Effects of Some Other
          Impairments Constraints ................................ 10
    4.5.  Other Impairment Considerations ........................ 13
    4.6.  An Alternative Approach - Using Maximum
          Distance as the Only Constraint ........................ 13
    4.7.  Other Considerations ................................... 15
    4.8.  Implications for Routing and Control Plane Design ...... 15
5.  More Complex Networks ........................................ 17
6.  Diversity .................................................... 19
    6.1.  Background on Diversity ................................ 19
    6.2.  Implications for Routing ............................... 23
7.  Security Considerations ...................................... 23
8.  Acknowledgements ............................................. 24
9.  References ................................................... 25
    9.1.  Normative References ................................... 25
    9.2.  Informative References ................................. 26
10. Contributing Authors ......................................... 26

1. Introduction ✨

Okay so, GMPLS [Mannie04] is basically trying to stretch MPLS to cover a bunch of transport architectures 🚀. That includes optical networks with all-optical and opto-electronic gear, like optical cross-connects with both optical and electrical fabrics, transponders, and optical add-drop multiplexers. Optical networking gives GMPLS a lot of challenges 😭. Again, optical tech is analog, not digital, and it sits lowest in the transport hierarchy, so it's super tied to the physical geography of the network 🗺️.

GMPLS already has some extensions for the unique optical layer stuff 💅. This doc surveys the optical network aspects that affect routing and suggests possible GMPLS responses for each one. It covers routing constraints and complications from how network elements are designed, how signal impairments build up, and the need to guarantee physical diversity for some circuits 🦋.

The point here is to push the GMPLS spec forward, so alternative ways of controlling an optical network are not discussed 🙅‍♀️. For broader issues, check out [Gerstel2000] and [Strand02] 📖.

Here's how the doc is laid out:

  • Section 2 is a section that the sub-IP Area management asked for in all new documents. It explains how this doc fits into the Area and the IPO WG, and why it belongs there 🌸.
  • Section 3 covers constraints from designing new software-controllable network elements 🎀.
  • Section 4 handles constraints in a single all-optical domain without wavelength conversion 💜.
  • Section 5 extends things to more complex networks that mix all-optical and opaque architectures 🌈.
  • Section 6 talks about the impacts of diversity constraints 🫶.
  • Section 7 deals with security requirements 🔐.
  • Section 8 has the acknowledgments 🙏.
  • Section 9 has the references 📚.
  • Section 10 has the contributing authors' addresses 💌.

2. Sub-IP Area Summary and Justification of Work 🧚

This doc merges and extends two older Internet-Drafts that had expired. Both had become IPO working group documents 🌷. They were combined into a basis for a design team at the Minneapolis IETF meeting, and it was also requested that they be merged into a requirements document for the WG 💖.

In the bigger sub-IP Area picture, this merged doc describes specific characteristics of optical tech and the requirements those place on routing and path selection 🗺️. It fits the IPO working group because the material is specific to optical networks ✨. It identifies and documents the characteristics of the optical transport network that matter for choosing paths for optical channels, which is a work area for the IPO WG 🦋. The material is aimed directly at setting up a framework and requirements for routing in an optical network 👑.

3. Reconfigurable Network Elements 🌸

3.1. Technology Background 🎀

Control plane architecture discussions (e.g., [Awduche99]) usually assume that the only software-reconfigurable network element is an optical layer cross-connect (OLXC) 🙈. But there are other software-reconfigurable elements on the horizon, specifically tunable lasers and receivers and reconfigurable optical add-drop multiplexers (OADM) 🔥. The following simple example shows these elements, and it's modeled on announced Optical Transport System (OTS) products 💅:

            +                                       +
---+---+    |\                                     /|    +---+---
---| A |----|D|          X              Y         |D|----| A |---
---+---+    |W|     +--------+     +--------+     |W|    +---+---
     :      |D|-----|  OADM  |-----|  OADM  |-----|D|      :
---+---+    |M|     +--------+     +--------+     |M|    +---+---
---| A |----| |      |      |       |      |      | |----| A |---
---+---+    |/       |      |       |      |       \|    +---+---
            +      +---+  +---+   +---+  +---+      +
             D     | A |  | A |   | A |  | A |     E
                   +---+  +---+   +---+  +---+
                    | |    | |     | |    | |

    Figure 3-1: An OTS With OADMs - Functional Architecture

Okay so, in Fig. 3-1, the part on the inner side of all the boxes labeled "A" is an all-optical subnetwork 🧠. From a routing point of view, two aspects are critical 💅:

  • Adaptation: These are the functions at the edges of the subnetwork that turn the incoming optical channel into the physical wavelength that gets carried through the subnetwork 🌈.
  • Connectivity: This defines which pairs of edge Adaptation functions can be linked up through the subnetwork ✨.

In Fig. 3-1, D and E are DWDMs, and X and Y are OADMs 🦋. The boxes labeled "A" are adaptation functions. They map one or more input optical channels, which are assumed to be standard short-reach signals, into a long-reach (LR) wavelength or wavelength group. That LR wavelength passes transparently to a distant adaptation function 💜. Adaptation functionality that affects routing includes:

  • Multiplexing: Either electrical or optical TDM can combine the input channels into a single wavelength 🍓. This increases effective capacity: a typical DWDM might handle 100 2.5 Gb/sec signals (250 Gb/sec total) or 50 10 Gb/sec signals (500 Gb/sec total), and combining the 2.5 Gb/sec signals effectively doubles capacity 🤯. Once multiplexed, the combined signal has to be routed as a group to the distant adaptation function 🫶.
  • Adaptation Grouping: Here, groups of k (e.g., 4) wavelengths are managed as a group within the system and must be added or dropped as a group 🎀. We'll call these groups an "adaptation grouping". Examples include so-called "wave group" and "waveband" [Passmore01] 🌷. Groupings on the same system can differ in basics like wavelength spacing, and that constrains the types of channels they can hold 💅.
  • Laser Tunability: The lasers producing the LR wavelengths might have a fixed frequency, might be tunable over a limited range, or might be tunable over the entire range of wavelengths the DWDM supports 🌈. Tunability speeds can vary too ⭐.

Connectivity between adaptation functions can also be limited 🙅‍♀️:

  • As mentioned above, TDM multiplexing and/or adaptation grouping by the adaptation function forces groups of input channels to be delivered together to the same distant adaptation function 💔.
  • Only adaptation functions whose lasers or receivers can tune to compatible frequencies can be connected 🎵.
  • The switching capability of the OADMs may also be constrained 🔒.

For example 👀:

  • There may be some wavelengths that can not be dropped at all 💀.
  • There may be a fixed relationship between the frequency dropped and the physical port on the OADM it gets dropped to 🧚.
  • OADM physical design may put an upper bound on the number of adaptation groupings dropped at any single OADM 🙈.
For a fixed configuration of the OADMs and adaptation functions, connectivity is fixed: each input port is basically hard-wired to some specific distant port 😭. BUT, this connectivity can be changed by reconfiguring the OADMs and adaptation functions. For example, an extra adaptation grouping might get dropped at an OADM, or a tunable laser might get retuned. Either way, the port-to-port connectivity changes 🔥.

These capabilities are expected to be under software control 💻. Right now, that control lives in the vendor-supplied Element Management system (EMS), which the operator's OSes control in turn 🏢. But in principle, the EMS could take part in the GMPLS routing process 🦋.

Part 1 of 7 is done, bestie 🎀💖 part 2 is coming, so stay tuned ✨👑

3.2. Implications for Routing 🦋

okay so an OTS (the kind from Sec. 3.1) is basically a geographically distributed but blocking cross-connect system 💅. Which ports connect to which depends on the vendor's design and also on exactly which line cards have been installed. the vibes are very "it depends on the hardware" 🙈

there are two ways GMPLS could deal with this. the first is to treat the port connectivity as externally determined ✨. in that case, the links GMPLS knows about are groups of identically routed wavebands. if the external EMS reconfigures those, the resulting connectivity changes need to be detected and advertised within GMPLS. and if the topology in Fig. 3-1 turns into a tree or a mesh instead of the linear shape it has now, those changes could cause Shared Risk Link Group (SRLG - see Section 6.2) changes. the drama is real 😭

the second option is for GMPLS to try to directly control this port connectivity. the state information needed to do that is likely to be voluminous and vendor specific 🌈 so ngl, that's a lot.

4. Wavelength Routed All-Optical Networks ✨

the optical networks we've been using until recently may be called "opaque" ([Tkach98]). basically, each link is optically isolated by transponders doing O/E/O conversions. those transponders provide regeneration with retiming and reshaping (also called 3R), which removes transparency to bit rates and frame format 🫶 the transponders are also super expensive, and their lack of transparency slows down the rollout of new services. so there are strong motivators to create "domains of transparency" (all-optical subnetworks) that are bigger than a single OTS 🚀

routing lightpaths through an all-optical network has gotten a lot of attention. (see [Yates99] or [Ramaswami98]). when people talk about routing in an all-optical network, they usually assume all routes have adequate signal quality 💜 one way to make that true is to keep all-optical networks to subnetworks of limited geographic size that are optically isolated from the rest of the optical layer by transponders. this is very practical and has been the approach so far, for example when deciding the maximum length of an Optical Transport System (OTS). plus, operational stuff like fault isolation also makes keeping domains of transparency small attractive 🍓

but there are reasons to consider contained domains of transparency where not every route has adequate signal quality. on the demand side, maximum bit rates have shot up from DS3 to OC-192 and soon OC-768 (40 Gb/sec) 📈 as bit rates go up, you need to increase power, and that makes impairments and nonlinearities way more troublesome 💀 on the supply side, optical technology is advancing super fast, which makes ever-larger domains possible 🌸 in this section, we assume these considerations will lead to deploying a domain of transparency that's too large to guarantee that all potential routes have adequate signal quality for every circuit. our goal is to understand the impacts of the various types of impairments in this environment 🧚

heads up, as we get into the section, there are a lot of types of physical impairments. which ones need to be handled explicitly during on-line distributed routing will vary a lot and depends on many variables, including:

  • Equipment vendor design choices,
  • Fiber characteristics,
  • Service characteristics (e.g., circuit speeds),
  • Network size,
  • Network operator engineering and deployment strategies.

for example, a metropolitan network that doesn't plan to support bit rates above 2.5 Gb/sec might not be constrained by any of these impairments 🌈 meanwhile, a continental or international network that wants to minimize O/E/O regeneration investment and support 40 Gb/sec connections might have to explicitly consider many of them 😤 also, a network operator can reduce or even eliminate their constraint set by building a relatively small domain of transparency so all the paths are feasible. another option is using some proprietary tools based on rules from the OTS vendor to pre-qualify paths between node pairs and put them in a table that gets checked every time a routing decision has to be made through that domain 💅

4.1. Problem Formulation 🎀

we're looking at a single domain of transparency without wavelength translation. also, because DWDM transmission technology is proprietary, we assume the domain is either single vendor or built on a single coherent design, especially when it comes to managing impairments 🔥

we want to route a unidirectional circuit from ingress client node X to egress client node Y. at both X and Y, the circuit goes through an O/E/O conversion that optically isolates the portion inside our domain. we assume we know the bit rate of the circuit. we also assume the adaptation function at X may apply some Forward Error Correction (FEC) method to the circuit. and we assume we know the launch power of the laser at X ⭐

impairments fall into two categories: linear and nonlinear. (see [Tkach98] or [Kaminow02] for more on impairment constraints.) linear effects don't depend on signal power and affect wavelengths individually. amplifier spontaneous emission (ASE), polarization mode dispersion (PMD), and chromatic dispersion are examples. nonlinearities are way more complex: they create impairments on each channel and also crosstalk between channels 🌪️

in the rest of this section, we first outline how two key linear impairments (PMD and ASE) might be handled by a set of analytical formulae as extra constraints on routing. next, we talk about how the remaining constraints might be approached. finally, we zoom out and discuss how those constraints affect control plane architecture, and also broader constrained domain of transparency architecture issues 🦋

4.2. Polarization Mode Dispersion (PMD) 🌈

for a transparent fiber segment, the general PMD requirement is that the time-average differential group delay (DGD) between two orthogonal state of polarizations should be less than some fraction a of the bit duration, T=1/B, where B is the bit rate. the value of the parameter a depends on three major factors: 1) margin allocated to PMD, e.g., 1dB; 2) targeted outage probability, e.g., 4x10-5, and 3) sensitivity of the receiver to DGD. a typical value for a is 10% [ITU]. more aggressive designs to compensate for PMD may allow values higher than 10%. (this would be a system parameter that depends on the system design, and it would need to be known to the routing process.) 🧠

the PMD parameter (Dpmd) is measured in pico-seconds (ps) per sqrt(km). the square of the PMD in a fiber span, denoted as span-PMD-square, is then given by the product of Dpmd**2 and the span length. (a fiber span in a transparent network refers to a segment between two optical amplifiers.) if Dpmd is constant, this gives an upper bound on the maximum length of an M-fiber-span transparent segment, which is inversely proportional to the square of the product of bit rate and Dpmd (the detailed equation is omitted due to the format constraint - see [Strand01] for details). 🙈

for older fibers with a typical PMD parameter of 0.5 picoseconds per square root of km, based on the constraint, the maximum length of the transparent segment should not exceed 400km and 25km for bit rates of 10Gb/s and 40Gb/s, respectively. but thanks to recent advances in fiber technology, the PMD-limited distance has increased dramatically 🚀 for newer fibers with a PMD parameter of 0.1 picosecond per square root of km, the maximum length of the transparent segment (without PMD compensation) is limited to 10000km and 625km for bit rates of 10Gb/s and 40Gb/, respectively. still lower values of PMD are attainable in commercially available fiber today, and the PMD limit can be pushed even further if a larger value of the parameter a (the ratio of DGD to the bit period) can be tolerated 👑 in general, the PMD requirement isn't an issue for most types of fibers at 10Gb/s or lower bit rates. but it will become an issue at bit rates of 40Gb/s and higher 💀

if the PMD parameter varies between spans, a slightly more complicated equation results (see [Strand01]). but either way, the only link dependent information the routing algorithm needs is the square of the link PMD, denoted as link-PMD-square. it's the sum of the span-PMD-square of all spans on the link 🫶

note that if you have some viable PMD compensation devices and deploy them everywhere on all routes with potential PMD issues in the network, then the PMD constraint disappears from the routing perspective ✨

4.3. Amplifier Spontaneous Emission 🌸

ASE degrades the optical signal to noise ratio (OSNR). an acceptable optical SNR level (SNRmin), which depends on the bit rate, transmitter-receiver technology (e.g., FEC), and margins allocated for the impairments, needs to be maintained at the receiver. to satisfy this requirement, vendors often provide some general engineering rule in terms of the maximum length of the transparent segment and number of spans. for example, current transmission systems are often limited to up to 6 spans each 80km long 📏 for larger transparent domains, more detailed OSNR computations will be needed to figure out whether the OSNR level through a domain of transparency is acceptable. this gives you flexibility when provisioning or restoring a lightpath through a transparent subnetwork 🦋

assume the average optical power launched at the transmitter is P. the lightpath from the transmitter to the receiver goes through M optical amplifiers, and each one introduces some noise power. unity gain can be used at all amplifier sites to keep constant signal power at the input of each span, which minimizes noise power and nonlinearity 🧚 a constraint on the maximum number of spans can be obtained [Kaminow97]. it's proportional to P and inversely proportional to SNRmin, optical bandwidth B, amplifier gain G-1, and spontaneous emission factor n of the optical amplifier, assuming all spans have identical gain and noise figure. (again, the detailed equation is omitted due to the format constraint - see [Strand01] for details.) let's take a typical example 🍓 assuming P=4dBm, SNRmin=20dB with FEC, B=12.5GHz, n=2.5, G=25dB, based on the constraint, the maximum number of spans is at most 10. but if FEC isn't used and the requirement on SNRmin becomes 25dB, the maximum number of spans drops down to 3 😭

for ASE, the only link-dependent information the routing algorithm needs is the noise of the link, denoted as link-noise, which is the sum of the noise of all spans on the link. so the constraint on ASE becomes that the aggregate noise of the transparent segment, which is the sum of the link-noise of all links, can not exceed P/SNRmin 👑

4.4. Approximating the Effects of Some Other Impairment Constraints 💅✨

Okay so bestie, there are a bunch of other impairment constraints that we think could be approximated with a domain-wide margin on the OSNR, plus in some cases a limit on the total number of networking elements (OXC or OADM) along the path 🌸. Most impairments generated at OXCs or OADMs, including polarization dependent loss, coherent crosstalk, and effective passband width, could be handled with this approach 🦋. In principle, impairments generated at the nodes can be bounded by system engineering rules, because the node elements can be designed and specified in a uniform manner 🧚. This approach is not feasible for PMD and noise, though, because neither can be uniformly specified 😭. Instead, they depend on node spacing and the characteristics of the installed fiber plant, and neither is likely to be under the system designer's control 💀.

Examples of the constraints we propose to approximate with a domain-wide margin are in the paragraphs below 🎀. Keep in mind that as optical transport technology evolves, it may become necessary to include some of these impairments explicitly in the routing process 👑. Other impairments that aren't mentioned here at all could also become important enough to need handling, either explicitly or with a domain-wide margin 🌈.

Other Polarization Dependent Impairments

Other polarization-dependent effects besides PMD affect system performance, and it's giving main character energy 💜. For example, many components have polarization-dependent loss (PDL) [Ramaswami98], and it builds up in a system with lots of components on the transmission path 🫶. The state of polarization fluctuates over time, and its distribution matters a lot too 🌀. It is generally required that the total PDL on the path be kept within some acceptable limit, potentially using some compensation technology on relatively long transmission systems, plus a small built-in margin in OSNR 🍓. Since total PDL goes up with the number of components in the data path, the system vendor must take it into account when working out the maximum allowable number of spans 🔥.

Chromatic Dispersion

In general, this impairment can be adequately (but not optimally) compensated on a per-link basis, and/or at system initial setup time 🦋. Today, most deployed compensation devices are based on Dispersion Compensation Fiber (DCF) 🌸. DCF provides per-fiber compensation using a spool of fiber with a CD coefficient opposite to the fiber's 🧚. Because the CD slope of the fiber and the DCF don't match perfectly, some lambdas end up over compensated while others end up under compensated 😭. Also, DCF modules may only come in fixed lengths of compensating fiber, so sometimes it's impossible to find a DCF module that exactly compensates the CD introduced by the fiber 💀. These effects create what's known as residual CD, and residual CD varies with the frequency of the wavelength ✨. If you know the characteristics of both the fiber and the DCF modules along the path, this can be calculated with a sufficient degree of precision 👑. However, this is a very challenging task 😩. In fact, the per-wavelength residual dispersion needs to be combined with other information in the system (e.g., the types of fiber, to figure out how much nonlinearity there is) to get the net effect of CD, either by simulation or by some analytical approximation 🤯. It appears that the routing/control plane should not be burdened with such a large set of information, since it can be handled at the system design level 🎀. Therefore, it will be assumed until proven otherwise that residual dispersion should not be reported 🙈. For high bit rates, dynamic dispersion compensation may be required at the receiver to clean up any residual dispersion 🌈.

Crosstalk

Optical crosstalk refers to the effect of other signals on the desired signal, and it's a whole thing 🫠. It includes both coherent (i.e., intrachannel) crosstalk and incoherent (i.e., interchannel) crosstalk 💜. The main contributors are the OADM and OXC sites that use a DWDM multiplexer/demultiplexer (MUX/DEMUX) pair 🍓. For a relatively sparse network, where the number of OADM/OXC nodes on a path is low, crosstalk can be treated with a low margin in OSNR without being a binding constraint 🌸. But for some relatively dense networks, where crosstalk might become a binding constraint, you need to propagate the per-link crosstalk information so you can make sure the end-to-end path crosstalk, which is the sum of the crosstalks on all the corresponding links, stays within some limit 😤. For example, that could be a -25dB threshold with a 1dB penalty ([Goldstein94]) 🔥. Another way to handle it, without having to propagate per-link crosstalk information, is to have the system evaluate the maximum number of OADM/OXC nodes that have a MUX/DEMUX pair for the worst route in the transparent domain, using a low built-in margin 🧠. The latter approach should work well where all the OXC/OADM nodes have a similar level of crosstalk 🦋.

Effective Passband

As more and more DWDM components are cascaded, the effective passband narrows 📉. The number of filters along the link, along with their passband width and shape, determines the end-to-end effective passband 🌷. In general, this is a system design issue: the system is designed for a certain maximum bit rate, using the proper modulation format and filter spacing 💅. For linear systems, the filter effect can be turned into a constraint on the maximum number of narrow filters, on the condition that the filters in the system are at least as wide as the one in the receiver 🎀. Because traffic at lower bit rates can tolerate a narrower passband, the maximum allowable number of narrow filters goes up as the bit rate goes down 🌈.

Nonlinear Impairments

It seems unlikely that these can be dealt with explicitly in a routing algorithm, because they lead to constraints that can couple routes together and create complex dependencies, e.g., on the order in which specific fiber types are traversed [Kaminow97] 🌀. Different fiber types (standard single mode fiber, dispersion shifted fiber, dispersion compensated fiber, etc.) have very different effects from nonlinear impairments 💫. A full treatment of the nonlinear constraints would likely require very detailed knowledge of the physical infrastructure 🧐. That includes measured dispersion values for each span, fiber core area and composition, and knowledge of subsystem details such as dispersion compensation technology 📋. This information would need to be combined with knowledge of the current loading of optical signals on the links of interest, to determine the level of nonlinear impairment 🫶. Alternatively, you could assume that nonlinear impairments are bounded and result in an X dB margin in the required OSNR level for a given bit rate 🦋. In that case, X would be limited to 1 or 2 dB for performance reasons, which consequently sets a limit on the maximum number of spans 🌸. For the approach described here to be useful, it is desirable for this span length limit to be longer than the one imposed by the constraints that can be treated explicitly 🙌. When designing a DWDM transport system, there are tradeoffs between the signal power launched at the transmitter, the span length, and the nonlinear effects on BER, and these need to be considered jointly 🧚. Here, we assume that an X dB margin is obtained after the transport system has been designed with a fixed signal power and maximum span length for a given bit rate 🍓. OTSs can be designed in very different ways, in linear, pseudo-linear, or nonlinear environments 🌈. The X dB margin approach may be valid for some of these but not for others 🤷‍♀️. However, there is likely an advantage in designing systems that are less aggressive with respect to nonlinearities, and therefore somewhat sub-optimal, in exchange for improved scalability, simplicity, and flexibility in routing and control plane design 👑✨.

4.5. Other Impairment Considerations 🎀

There are many other types of impairments that can degrade performance 😮‍💨. In this section, we briefly mention one other type of impairment, which we propose be dealt with either by the system designer or by the transmission engineers at the time the system is installed 🛠️. If it's dealt with successfully this way, it shouldn't need to be considered in the dynamic routing process 🦋.

Gain Nonuniformity and Gain Transients

For simple noise estimates to be useful, the amplifiers must be gain-flattened and must have automatic gain control (AGC) 📶. Furthermore, each link should have dynamic gain equalization (DGE) to optimize power levels each time wavelengths are added or dropped 💖. Variable optical attenuators on the output ports of an OXC or OADM can be used for this purpose, and in-line devices are starting to become commercially available 🌸. Optical channel monitors are also required to provide feedback to the DGEs 📡. AGC must be done rapidly if signal degradation after a protection switch or link failure is to be avoided 🚨.

Note that the impairments considered here are treated more or less independently 🧩. By considering them jointly, and varying the tradeoffs between the effects from different components, more routes may be feasible 🌈. If that's desirable, or if the system is designed so that certain impairments (e.g., nonlinearities) need to be considered by a centralized process, then distributed routing is not the one to use 🙅‍♀️💅.

4.6. An Alternative Approach - Using Maximum Distance as the Only Constraint

Okay bestie, this section is giving "keep the simple rule" energy 🦋. Carriers today often engineer point-to-point OTS systems using maximum distance, with a fixed per-span length based on the OSNR constraint for a given bit rate 📏. They might want to keep that same engineering rule once they move to all-optical networks 🌈. So here we talk about what has to be true for this approach to stay viable, and how to handle the network elements sitting between two adjacent links 💅.

To use the maximum distance for a given bit rate as the only binding constraint that meets an OSNR constraint, operators need their all-optical networks to satisfy the following:

  • All the other non-OSNR constraints from the previous subsections are not binding factors, as long as the maximum distance constraint is met ✨.
  • For PMD specifically, the whole all-optical network is built on top of sufficiently low-PMD fiber, so the upper bound on the mean aggregate path DGD is always satisfied for any path that does not exceed the maximum distance. Otherwise, PMD compensation devices might be used for routes with high-PMD fibers 🔧.
  • For the ASE/OSNR constraint, the network needs a fixed fiber distance D for each span, so that the ASE can be mapped directly to a distance constraint. The gain of the amplifier equals the loss of the previous fiber span, which makes this work. A common choice is 80km spacing, which carriers commonly pick 🧚. But when spans have variable lengths, you have to make some adjustments and compromises so that you don't have to treat ASE explicitly as in section 4.3 😭. These include:
    1. Unless the OTS has a certain mechanism built in to take advantage of shorter spans, any span shorter than a typical span length D has to be treated as a span of length D, not its real length.
    2. Spans longer than D have a higher average span loss. In general, the maximum system reach decreases when the average span loss increases. So to accommodate longer spans in the network, the maximum distance upper bound has to be set with respect to the average span loss of the worst path in the network. This sub-optimality may be acceptable for some networks if the variance is not too large, but it may be too conservative for others 🥲.

If these assumptions hold, the second issue is how to treat a transparent network element (for example, a MEMS-based switch) between two adjacent links in terms of a distance constraint. It's a problem because it also introduces an insertion loss 💀. If the network element can't somehow compensate for this OSNR degradation, one approach is to convert each network element into an equivalent length of fiber based on its loss/ASE contribution 🍓. So in general, introducing a set of transparent network elements effectively reduces the overall actual transmission distance between the OEO edges 🫶.

With this approach, the link-specific state information is the link-distance, which is the length of a link. It equals the distance sum of all fiber spans on the link, plus the equivalent length of fiber for the network element(s) on the link. The constraint is that the sum of all the link-distance values over all links of a path should be less than the maximum-path-distance, which is the upper bound of all paths 👑.

4.7. Other Considerations

Routing in an all-optical network without wavelength conversion brings up a few extra issues, and ngl they're a whole mood 🌸:

  • Since the route you pick must have the chosen wavelength available on all links, that information has to be part of the routing process 🎀. One approach is to spread information all over the network about the state of every wavelength on every link. But the state you need, and the overhead of processing and maintaining it, grows with the total number of links (so, the number of nodes squared), the maximum number of wavelengths (which keeps doubling every couple of years 😭), and how often wavelength availability changes, which can be very high 🙈. So instead, [Hjalmtysson00] proposes a different method that probes along a chosen path to figure out which wavelengths (if any) are available 🔍. That would need a big addition to the routing logic normally used in OSPF. Others have proposed probing multiple paths at the same time 🦋.
  • Choosing a path first and then a wavelength along it is known to give decent results in simple topologies like rings and trees ([Yates99]) 💅. But that doesn't seem to hold in large mesh networks under realistic provisioning scenarios 💀. Instead, you get way better results when wavelength and route are chosen at the same time ([Strand01b]) 🔥. The catch is that this approach would also have a significant effect on OSPF 🙃.

4.8. Implications For Routing and Control Plane Design

If you want distributed routing, the routing will need extra state information to deal with the impairments described in Sections 4.2 - 4.4 🧠:

  • As mentioned earlier, an operator who wants to avoid giving impairment-related parameters to the control plane can choose not to handle them at the routing level 🫧. Instead they can deal with them at the system design and planning level, if that's a viable approach for their network. In this approach, the operator can pre-qualify all of a set of feasible end-to-end optical paths through the domain of transparency for each bit rate, or just some of them. This works well with relatively small and sparse networks 🌱, but it may not scale for large and dense networks, where the number of feasible paths can be very large 😵‍💫.
  • If the optical paths aren't pre-qualified, the routing algorithm needs additional link-specific state information for each type of impairment that could be limiting for some routes 🚦. Note that for one operator, PMD might be the only limiting constraint, while for another it might be ASE, or it could be both plus some other constraints from this document. Some networks might not be limited by any of these constraints at all ✨.
  • For an operator who needs to deal with these constraints explicitly, the link-dependent information identified above for PMD is link-PMD-square, which is the square of the total PMD on a link. For ASE, the link-dependent information is link-noise, which is the total noise on a link. Other link-dependent information includes link-span-length, which is the total number of spans on a link; link-crosstalk or OADM-OXC-number, which is the total crosstalk or the number of OADM/OXC nodes on a link, respectively; and filter-number, which is the number of narrow filters on a link. When the alternative distance-only approach is chosen, the link-specific information is link-distance 🎀.
  • On top of the link-specific information, bounds on each of the impairments need to be quantified. These bounds come from the system designer's impairment allocations, so they're system dependent 🧁. For PMD, the constraint is that the sum of the link-PMD-square of all links on the transparent segment is less than the square of (a/B), where B is the bit rate. So the required information is the parameter "a". For ASE, the constraint is that the sum of the link-noise of all links is no larger than P/SNRmin. So the information needed includes the launch power P and the OSNR requirement SNRmin. The minimum acceptable OSNR, in turn, depends on the strength of the FEC being used and the margins reserved for other types of impairments 🧪. Other bounds include the maximum span length of the transmission system, the maximum path crosstalk or the maximum number of OADM/OXC nodes, and the maximum number of narrow filters. These are all bit rate dependent. With the alternative distance-only approach, the upper bound is the maximum-path-distance. In single-vendor "islands," some of these parameters may already be in a local or EMS database and wouldn't need to be advertised 🏝️
  • The physical layer parameters probably don't change value rapidly, so they could be stored in some database 🗄️. The catch is that these physical layer parameters are frequently not known at the granularity that's required today 😬. If the ingress node of a lightpath does path selection, these parameters would need to be available at that node 🚀.
  • The specific constraints needed in a given situation depend on the design and engineering of the domain of transparency. For example, it will be essential to know whether chromatic dispersion has been dealt with on a per-link basis, and whether the domain is operating in a linear or nonlinear regime 🌈.
  • As optical transport technology evolves, the set of constraints that need to be considered, either explicitly or through a domain-wide margin, may change 🦋. So the routing and control plane design should be as open as possible, allowing parameters to be included as necessary 💜.
  • Without wavelength conversion, you have to find a single wavelength that's available on all links. That means you either advertise detailed information on wavelength availability (which probably doesn't scale), or you have some mechanism for probing potential routes, with or without crankback, to determine wavelength availability 😤. Choosing the route first and then the wavelength may not yield acceptable utilization levels in mesh-type networks 💅✨.

5. More Complex Networks 🌸

okay so mixing a bunch of optical gear inside ONE domain of transparency that nobody designed to work together? that's beyond the scope of this doc 🙅‍♀️ and that includes most multi-vendor all-optical networks, sorry not sorry 💅

ok but a network made of multiple domains of transparency, each one cut off from the others by O/E/O devices (transponders), is way more plausible ✨ the combo that's of particular interest is "opaque" (optically isolated) OLXCs plus one or more all-optical "islands" walled off by transponders, because honestly this is probably how all-optical tech (like the stuff in Sec. 2) is gonna get rolled out 🦋 (we say "island" here instead of "domain" or "area" bc those words are already tied to specific stuff like BGP or OSPF 🙈)

we're gonna look at the complexities these options bring now 🧠

so the first requirement for routing in a multi-island network is that the routing process needs to know where each island starts and ends. there are a few reasons why:

  • when you enter or leave an all-optical island, the regeneration process cleans up the optical impairments from Sec. 3 💖
  • each island might have its own limits on each impairment 🙅‍♀️
  • the routing process has to care about the costs of "island-hopping" 💸

that last one needs some extra love 🫶 it's super important to realize that, at least in the short to intermediate term, a single routing decision can commit a LOT of resources. one coast-to-coast OC-192 can easily tie up equipment with a first cost of $10**6 😭, and once a circuit is up, its holding times are likely measured in months. carriers are gonna expect the routing algorithms to be sensitive to these costs, and simplistic measures like counting "hops" probably won't cut it 💀

take an all-optical island that's an "ultra long-haul" system like the one in Fig. 3-1, sitting inside an OEO network of electrical fabric OLXCs. ULH gear is likely to be pricey for short hops but pretty economical over longer distances, so it's likely to get deployed as a sort of "express backbone" 🚄. in that setup, carriers will expect the routing algorithm to balance OEO costs against the extra costs of ULH tech, and to route a bit circuitously so the backbone gets used where it makes sense 👑. just note: the metrics used to do this have to be consistent across the whole routing domain for that expectation to hold 🎀

the first-order implications for GMPLS seem to be:

  • island boundaries need to be advertised 📣
  • routing has to be sensitive to island transitions and to the connectivity limits and impairment constraints specific to each island ✨
  • the cost function used in routing has to let you balance transponder costs, OXC and OADM costs, and line haul costs across the entire routing domain 💅

a few distributed approaches to multi-island routing seem worth investigating 🔍

  • advertise each island's internal topology and constraints globally, and let the ingress node compute an end-to-end strict explicit route that's sensitive to all constraints and wavelength availabilities. in this approach, the routing algorithm on the ingress node has to be able to handle the details of routing within each island 🧩
  • have the EMS or control plane of each island figure out and advertise the connectivity between its boundary nodes, along with extra info like costs and the bit rates and formats supported. as spare capacity changes, updates get advertised. here, impairment constraints get handled inside each island, so impairment-related parameters don't need to be advertised outside of it 🔒 the ingress node then does a loose explicit route and leaves routing and wavelength selection inside each island to that island 🫧
  • have the ingress node send out probes or queries to nearby gateway nodes or to an NMS to get routing guidance 📡

6. Diversity 🌈

6.1. Background on Diversity ✨

Okay bestie, so "diversity" is a relationship between lightpaths 🦋 Two lightpaths are diverse if they have no single point of failure. In traditional telephony the dominant failure was in the interoffice plant, like a fiber cut from a backhoe 🚧💀

Why is this a unique problem for optical networks? Data network operators used to lean on their private line providers to handle diversity, so they never had to deal with it directly 🙈 GMPLS changes that. It makes the complexities the private line provisioning process handled, diversity included, part of the common control plane, so now it's visible to everyone 👀✨

To figure out whether two lightpath routings are diverse, you have to find the single points of failure in the interoffice plant 🗺️ So here's the vocab. A fiber cable is a uniform group of fibers inside a sheath. An Optical Transport System occupies fibers across a sequence of fiber cables. Each fiber cable sits in a sequence of conduits (buried honeycomb structures that cables get pulled through) or gets buried in a right of way (ROW) 🌸 A ROW is land where the network operator has the right to install their conduit or fiber cable. Fun fact: for economic reasons, ROWs are frequently obtained from railroads, pipeline companies, or thruways 🚂 Several carriers often lease ROW from the same source, so a bunch of carriers' fiber cables end up hanging out super close together 👯‍♀️ Same deal in a metro network, where several carriers might lease duct space in the same RBOC conduit. There are also "carrier's carriers" 🫶, optical networks that provide fibers to multiple carriers, all of whom could get hit by one failure in the "carrier's carrier" network 😭

In a typical intercity facility network there might be on the order of 100 offices that are candidates for OLXCs. To represent the interoffice fiber network accurately you need a network with an order of magnitude more nodes 🤯 Besides Optical Amplifier (OA) sites, those extra nodes include:

  • Places where fiber cables enter/leave a conduit or right of way;
  • Locations where fiber cables cross; Locations where fiber splices are used to interchange fibers between fiber cables.

Here's an example of the first one 👇

                                 A                 B
   A-------------B                 \             /
                                     \         /
                                       X-----Y
                                     /         \
   C-------------D                 /             \
                                 C                 D

   (a) Fiber Cable Topology      (b) Right-Of-Way/Conduit Topology

          Figure 6-1:  Fiber Cable vs. ROW Topologies

So the A-B fiber cable is physically routed A-X-Y-B, and the C-D cable is physically routed C-X-Y-D 🛣️ This can happen because of some physical bottleneck, like X-Y being the Lincoln Tunnel or the Bay Bridge 🌉

Fiber route crossing (the second case) is basically a special case of this, where X and Y coincide 💫 In that case the crossing point might not even be a manhole. The fiber routes could just be buried at different depths 🪱

Fiber splicing (the third case) happens a lot when a major fiber route runs near a small office 🏢 To dodge the expense and the extra transmission loss, only a small number of fibers get spliced out of the major route into a smaller route heading to the small office. This can totally happen in a manhole or hut 🛖 Check out Fig. 6-2(a), where A-X-B is the major route, X is the manhole, and C is the smaller office. The actual fiber topology then looks like Fig. 6-2(b), where there are typically way more A-B fibers than A-C or C-B fibers, and A-C and C-B might have different fiber counts. (One of the latter might even be missing 👀)

                  C                             C
                  |                           /   \
                  |                         /       \
                  |                       /           \
           A------X------B              A---------------B

           (a) Fiber Cable Topology     (b) Fiber Topology

             Figure 6-2.  Fiber Cable vs Fiber Topologies

Now the imminent deployment of ultra-long (>1000 km) Optical Transport Systems adds another layer of drama 🎭 Two OTSes could interact a number of times! Hypothetically: a New York - Atlanta OTS and a Philadelphia - Orlando OTS might share the same right of way for x miles in Maryland and then again for y miles in Georgia 🗺️ They could also cross at Raleigh, or some other intermediate node, without sharing right of way at all. Chaotic, honestly 🌀

Diversity is often equated with routing two lightpaths between a single pair of points, or between different pairs of points, so that no single route failure disrupts both of them. Sweetie, this is too simplistic, for a few reasons 💅

  • A sophisticated client of an optical network will want to derive diversity needs from their end customers' availability requirements. Those often lead to more complex diversity requirements than just "be diverse between two lightpaths" 🧠 For example, a common requirement is that no single failure should isolate a node or nodes. If node A has single lightpaths to nodes B and C, that means A-B and A-C have to be diverse. In real applications, a large data network with N lightpaths between its routers might describe its needs in an NxN matrix, where (i,j) defines whether lightpaths i and j must be diverse 📊
  • Two circuits that count as diverse for one application might not count as diverse in another situation 🙃 Diversity is usually thought of as a reaction to interoffice route failures, but high reliability applications may need other types of failures taken into account. Some examples:
    • Office Outages: Although less frequent than route failures, fires, power outages, and floods do happen 🔥 Many network managers require that diverse routes have no (intermediate) nodes in common. In other cases an intermediate node might be acceptable as long as there is power diversity within the office 🔋
    • Shared Rings: Lots of applications are willing to let "diverse" circuits share a SONET ring-protected link. Presumably they'd allow the same for optical layer rings 💍
    • Disasters: Earthquakes and floods can cause failures over an extended area 🌋 Defense Department circuits might need routing with nuclear damage radii taken into account ☢️
  • On the flip side, some networks are willing to take somewhat bigger risks 😤 Taking route failures as an example: such a network might consider two fiber cables in heavy duty concrete conduit to have a low enough chance of simultaneous failure to be "diverse". They might also view two fiber cables buried on opposite sides of a railroad track as diverse, since there's minimal danger of one backhoe taking out both, even though a bad train wreck might jeopardize them both 🚆 A network seeking N mutually diverse paths from an office with fewer than N diverse ROWs will have to live with some level of compromise in the immediate vicinity of that office 🫠

These considerations strongly suggest that the routing algorithm should be sensitive to the types of threat the requester considers unacceptable 🎯 Also, the impairment constraints from the previous section may eliminate some of the long, circuitous routes sometimes needed to provide diversity. That makes it harder to find many diverse paths through an all-optical network than through an opaque one 😩

[Hjalmtysson00] introduced the term "Shared Risk Link Group" (SRLG) to describe the relationship between two non-diverse links ✨ Based on the examples and discussion at the start of this section, an SRLG should be characterized by 2 parameters:

  • Type of Compromise: Examples would be shared fiber cable, shared conduit, shared ROW, shared optical ring, shared office without power sharing, etc.)
  • Extent of Compromise: For compromised outside plant, this would be the length of the sharing.

A CSPF algorithm could then penalize a diversity compromise by an amount that depends on these two parameters 💜

Two links could be related by many SRLGs. (AT&T's experience indicates that a link may belong to over 100 SRLGs, each corresponding to a separate fiber group 🤯) Each SRLG might relate a single link to many other links 🕸️ For the optical layer, similar situations can be expected where a link is an ultra-long OTS.

The mapping between links and the different types of SRLGs is generally defined by network operators, based on the definition of each SRLG type 📋 Since SRLG information isn't yet discoverable by a network element and doesn't change dynamically, it doesn't need to be advertised along with other resource availability information by network elements 🙌 It could be configured in a central database and distributed to or retrieved by the nodes, or advertised by network elements at the topology discovery stage 🗂️

6.2. Implications For Routing 🛣️

Dealing with diversity is an unavoidable requirement for routing in the optical layer 🚨 It means handling constraints in the routing process, but most importantly it requires additional state information, like the SRLG relationships. The routings of any existing circuits that the new circuit must be diverse from also have to be available to the routing process 🧩

Right now SRLG information can't be self-discovered 😵‍💫 Honestly, in a large network it's very difficult to keep SRLG information accurate. It gets especially daunting whenever multiple administrative domains are involved, like after one network acquires another, because there's normally a good chance of diversity violations between the domains 💀 It's very unlikely that diversity relationships between carriers will be known any time in the near future 🙃

Expect considerable variation in what different customers mean by acceptable diversity 🌈 So we suggest defining an SRLG like this: (i) it's a relationship between two or more links, and (ii) it's characterized by two parameters, the type of compromise (shared conduit, shared ROW, shared optical ring, etc.) and the extent of the compromise (e.g., the number of miles over which the compromise persisted). This lets you easily identify the SRLGs that matter for a particular routing request 🎀✨

7. Security Considerations 🔐

Okay bestie, this part is serious, so let's be careful. We're assuming the domains we've been talking about use OEO interfaces (see Sec. 4.1 above). If we dropped that assumption and let externally generated optical signals into the domain, new security issues would show up. Someone could sneak in signals at the wrong wavelengths, or with power levels or impairments that don't match what the domain expects. With OEO interfaces, though, these layer one threats should be controllable. 💅

A big layer one security issue is staying resilient when someone physically attacks the network. Diversity, as described in Sec. 6, is part of the answer. But it doesn't help if there isn't enough spare capacity to make the network whole again after an attack. Here are the major related issues:

  • Defining the threat: Say an electro-magnetic interference (EMI) burst counts as an in-scope threat. Then, in the terminology of Sec. 6, every link close enough to be disrupted by that burst has to be included in a single SRLG. The same idea goes for other threats too. For each in-scope threat, SRLGs should be defined so that every link vulnerable to one incident of that threat ends up grouped together in a single SRLG. 🧚
  • Allocating responsibility for responding to a layer one failure between the various layers (especially the optical and IP layers): This needs to be clearly specified so we avoid churning and unnecessary service interruptions. 😭

The whole process we've described relies on the integrity of the impairment characterization information (PMD parameters, etc.) and on the SRLG definitions. So keeping this information secure, both when it's stored and when it's distributed, is essential. 🔥

This document doesn't cover control plane issues, so control-plane security is out of scope. IPO control plane security considerations are discussed in [Rajagopalam04]. Security considerations for GMPLS, a likely control plane candidate, are discussed in [Mannie04]. 🌸

8. Acknowledgments 🫶

Thank you so much to everyone who chatted with us while this was being made! This document has benefited from discussions with Michael Eiselt, Jonathan Lang, Mark Shtaif, Jennifer Yates, Dongmei Wang, Guangzhi Li, Robert Doverspike, Albert Greenberg, Jim Maloney, John Jacob, Katie Hall, Diego Caviglia, D. Papadimitriou, O. Audouin, J. P. Faure, L. Noirie, and our OIF colleagues. 💜

9. References 📚

9.1. Normative References

[Goldstein94]   Goldstein, E. L., Eskildsen, L., and Elrefaie, A. F.,
                Performance Implications of Component Crosstalk in
                Transparent Lightwave Networks", IEEE Photonics
                Technology Letters, Vol.6, No.5, May 1994.

[Hjalmtysson00] Gsli Hjalmtysson, Jennifer Yates, Sid Chaudhuri and
                Albert Greenberg, "Smart Routers - Simple Optics: An
                Architecture for the Optical Internet, IEEE/OSA
                Journal of Lightwave Technology, December 2000, Vo
                18, Issue 12, Dec. 2000, pp. 1880-1891.

[ITU]           ITU-T Doc. G.663, Optical Fibers and Amplifiers,
                Section II.4.1.2.

[Kaminow97]     Kaminow, I. P. and Koch, T. L., editors, Optical
                Fiber Telecommunications IIIA, Academic Press, 1997.

[Mannie04]      Mannie, E., Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Architecture", RFC 3945, October
                2004.

[Rajagopalam04]  Rajagopalan, B., Luciani, J., and D. Awduche, "IP
                over Optical Networks: A Framework", RFC 3717, March
                2004.

[Strand01]      Strand, J., Chiu, A., and R. Tkach, "Issues for
                Routing in the Optical Layer", IEEE Communications
                Magazine, Feb. 2001, vol. 39 No. 2, pp. 81-88.

[Strand01b]     Strand, J., Doverspike, R., and G. Li, "Importance of
                Wavelength Conversion In An Optical Network", Optical
                Networks Magazine, May/June 2001, pp. 33-44.

[Yates99]       Yates, J. M., Rumsewicz, M. P., and J. P. R. Lacey,
                "Wavelength Converters in Dynamically-Reconfigurable
                WDM Networks", IEEE Communications Surveys, 2Q1999
                (online at
                www.comsoc.org/pubs/surveys/2q99issue/yates.html).

9.2. Informative References

[Awduche99]     Awduche, D. O., Rekhter, Y., Drake, J., R. and
                Coltun, "Multi-Protocol Lambda Switching: Combining
                MPLS Traffic Engineering Control With Optical
                Crossconnects", Work in Progress.

[Gerstel2000]   Gorstel, O., "Optical Layer Signaling: How Much Is
                Really Needed?" IEEE Communications Magazine, vol. 38
                no. 10, Oct. 2000, pp. 154-160

[Kaminow02]     Ivan P. Kaminow and Tingye Li (editors), "Optical
                Fiber Communications IV: Systems and Impairments",
                Elsevier Press, 2002.

[Passmore01]    Passmore, D., "Managing Fatter Pipes," Business
                Communications Review, August 2001, pp. 20-21.

[Ramaswami98]   Ramaswami, R. and K. N. Sivarajan, Optical Networks:
                A Practical Perspective, Morgan Kaufmann Publishers,
                1998.

[Strand02]      John Strand, "Optical Network Architecture
                Evolution", in [Kaminow02].

[Tkach98]       Tkach, R., Goldstein, E., Nagel, J., and J. Strand,
                "Fundamental Limits of Optical Transparency", Optical
                Fiber Communication Conf., Feb. 1998, pp. 161-162.

10. Contributing Authors 🎀

This document was a collective work of a number of people. The text and content of this document was contributed by the editors and the co-authors listed below. Here are all the lovely people behind it:

Ayan Banerjee
Calient Networks
6620 Via Del Oro
San Jose, CA 95119
EMail: abanerjee@calient.net


Prof. Dan Blumenthal
Eng. Science Bldg., Room 2221F
Department of Electrical and Computer Engineering
University of California
Santa Barbara, CA 93106-9560
EMail: danb@ece.ucsb.edu
Dr. John Drake
Boeing
2260 E Imperial Highway
El Segundo, Ca 90245
EMail: John.E.Drake2@boeing.com


Andre Fredette
Hatteras Networks
PO Box 110025
Research Triangle Park, NC 27709
EMail: afredette@hatterasnetworks.com


Change Nan Froberg's reach info to:
Dr. Nan Froberg
Photonic Systems, Inc.
900 Middlesex Turnpike, Bldg #5
Billerica, MA 01821
EMail: nfroberg@photonicsinc.com


Dr. Taha Landolsi
King Fahd University
KFUPM Mail Box 1026
Dhahran 31261, Saudi Arabia
EMail: landolsi@kfupm.edu.sa


James V. Luciani
900 Chelmsford St.
Lowell, MA 01851
EMail: james_luciani@mindspring.com


Dr. Robert Tkach
32 Carriage House Lane
Little Silver, NJ 07739
908 246 5048
EMail: tkach@ieee.org
Yong Xue
Dr. Yong Xue
DoD/DISA
5600 Columbia Pike
Falls Church VA 22041
EMail: yong.xue@disa.mil

Editors' Addresses 🖋️

Angela Chiu
AT&T Labs
200 Laurel Ave., Rm A5-1F13
Middletown, NJ 07748

Phone: (732) 420-9061
EMail: chiu@research.att.com


John Strand
AT&T Labs
200 Laurel Ave., Rm A5-1D33
Middletown, NJ 07748

Phone: (732) 420-9036
EMail: jls@research.att.com

Here's the legal stuff, kept word for word so nothing gets fuzzy. ✨

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

Same deal here, the IPR wording stays exactly as written. 💅

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society! 💖

📦 where this page comes from