handled by the private line provisioning process, including
diversity, part of the common control plane and so visible to all.
To determine whether two lightpath routings are diverse it is
necessary to identify single points of failure in the interoffice
plant. To do so we will use the following terms: A fiber cable is a
uniform group of fibers contained in a sheath. An Optical Transport
System will occupy fibers in a sequence of fiber cables. Each fiber
cable will be placed in a sequence of conduits - buried honeycomb
structures through which fiber cables may be pulled - or buried in a
right of way (ROW). A ROW is land in which the network operator has
the right to install his conduit or fiber cable. It is worth noting
that for economic reasons, ROWs are frequently obtained from
railroads, pipeline companies, or thruways. It is frequently the
case that several carriers may lease ROW from the same source; this
makes it common to have a number of carriers’ fiber cables in close
proximity to each other. Similarly, in a metropolitan network,
several carriers might be leasing duct space in the same RBOC
conduit. There are also "carrier’s carriers" - optical networks
which provide fibers to multiple carriers, all of whom could be
affected by a single 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 inter-
office fiber network accurately a network with an order of magnitude
more nodes is required. In addition to Optical Amplifier (OA) sites,
these additional 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.
An example of the first might be:
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
Here the A-B fiber cable would be physically routed A-X-Y-B and the
C-D cable would be physically routed C-X-Y-D. This topology might
arise because of some physical bottleneck: X-Y might be the Lincoln
Tunnel, for example, or the Bay Bridge.
Fiber route crossing (the second case) is really a special case of
this, where X and Y coincide. In this case the crossing point may
not even be a manhole; the fiber routes might just be buried at
different depths.
Fiber splicing (the third case) often occurs when a major fiber route
passes near to a small office. To avoid the expense and additional
transmission loss only a small number of fibers are spliced out of
the major route into a smaller route going to the small office. This
might well occur in a manhole or hut. An example is shown in Fig.
6-2(a), where A-X-B is the major route, X the manhole, and C the
smaller office. The actual fiber topology would then look like Fig.
6-2(b), where there would typically be many more A-B fibers than A-C
or C-B fibers, and where A-C and C-B might have different numbers of
fibers. (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
The imminent deployment of ultra-long (>1000 km) Optical Transport
Systems introduces a further complexity: Two OTSes could interact a
number of times. To make up a hypothetical example: A New York -
Atlanta OTS and a Philadelphia - Orlando OTS might ride on the same
right of way for x miles in Maryland and then again for y miles in
Georgia. They might also cross at Raleigh or some other intermediate
node without sharing right of way.
Diversity is often equated to routing two lightpaths between a single
pair of points, or different pairs of points so that no single route
failure will disrupt them both. This is too simplistic, for a number
of reasons:
- A sophisticated client of an optical network will want to derive
diversity needs from his/her end customers’ availability
requirements. These often lead to more complex diversity
requirements than simply providing diversity between two
lightpaths. For example, a common requirement is that no single
failure should isolate a node or nodes. If a node A has single
lightpaths to nodes B and C, this requires A-B and A-C to be
diverse. In real applications, a large data network with N
lightpaths between its routers might describe their needs in an
NxN matrix, where (i,j) defines whether lightpaths i and j must be
diverse.
- Two circuits that might be considered diverse for one application
might not be considered diverse for in another situation.
Diversity is usually thought of as a reaction to interoffice route
failures. High reliability applications may require other types
of failures to be taken into account. Some examples:
o Office Outages: Although less frequent than route failures,
fires, power outages, and floods do occur. 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.
o Shared Rings: Many applications are willing to allow "diverse"
circuits to share a SONET ring-protected link; presumably they
would allow the same for optical layer rings.
o Disasters: Earthquakes and floods can cause failures over an
extended area. Defense Department circuits might need to be
routed with nuclear damage radii taken into account.
- Conversely, some networks may be willing to take somewhat larger
risks. Taking route failures as an example: Such a network might
be willing to consider two fiber cables in heavy duty concrete
conduit as having a low enough chance of simultaneous failure to
be considered "diverse". They might also be willing to view two
fiber cables buried on opposite sides of a railroad track as being
diverse because there is minimal danger of a single backhoe
disrupting them both even though a bad train wreck might
jeopardize them both. A network seeking N mutually diverse paths
from an office with less than N diverse ROWs will need to live
with some level of compromise in the immediate vicinity of the
office.
These considerations strongly suggest that the routing algorithm
should be sensitive to the types of threat considered unacceptable by
the requester. Note that the impairment constraints described in the
previous section may eliminate some of the long circuitous routes
sometimes needed to provide diversity. This would make it harder to
find many diverse paths through an all-optical network than an opaque
one.
[Hjalmtysson00] introduced the term "Shared Risk Link Group" (SRLG)
to describe the relationship between two non-diverse links. The
above examples and discussion given at the start of this section
suggests that 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 dependent 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 different types of SRLGs is in general
defined by network operators based on the definition of each SRLG
type. Since SRLG information is not yet ready to be discoverable by
a network element and does not change dynamically, it need not be
advertised with other resource availability information by network
elements. It could be configured in some central database and be
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 requires dealing with constraints in the
routing process, but most importantly requires additional state
information (e.g., the SRLG relationships). The routings of any
existing circuits from which the new circuit must be diverse must
also be available to the routing process.
At present SRLG information cannot be self-discovered. Indeed, in a
large network it is very difficult to maintain accurate SRLG
information. The problem becomes particularly daunting whenever
multiple administrative domains are involved, for instance after the
acquisition of one network by another, because there normally is a
likelihood that there are diversity violations between the domains.
It is very unlikely that diversity relationships between carriers
will be known any time in the near future.
Considerable variation in what different customers will mean by
acceptable diversity should be anticipated. Consequently we suggest
that an SRLG should be defined as follows: (i) It is a relationship
between two or more links, and (ii) it is 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 will
allow the SRLGs appropriate to a particular routing request to be
easily identified.
7. Security Considerations
We are assuming OEO interfaces to the domain(s) covered by our
discussion (see, e.g., Sec. 4.1 above). If this assumption were to
be relaxed and externally generated optical signals allowed into the
domain, network security issues would arise. Specifically,
unauthorized usage in the form of signals at improper wavelengths or
with power levels or impairments inconsistent with those assumed by
the domain would be possible. With OEO interfaces, these types of
layer one threats should be controllable.
A key layer one security issue is resilience in the face of physical
attack. Diversity, as describe in Sec. 6, is a part of the solution.
However, it is ineffective if there is not sufficient spare capacity
available to make the network whole after an attack. Several major
related issues are:
- Defining the threat: If, for example, an electro-magnetic
interference (EMI) burst is an in-scope threat, then (in the
terminology of Sec. 6) all of the links sufficiently close
together to be disrupted by such a burst must be included in a
single SRLG. Similarly for other threats: For each in-scope
threat, SRLGs must be defined so that all links vulnerable to a
single incident of the threat must be 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 must be clearly specified to avoid churning and unnecessary
service interruptions.
The whole proposed process depends on the integrity of the impairment
characterization information (PMD parameters, etc.) and also the SRLG
definitions. Security of this information, both when stored and when
distributed, is essential.
This document does not address control plane issues, and 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
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 with 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.
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
Full Copyright Statement
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
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.