| | | +--------+ |
+--------------+ | | | |
+------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs
6.3. Topology Discovery
Topology discovery is the procedure by which the topology and
resource state of all the links in a network are determined. This
procedure may be done as part of a link state routing protocol (e.g.,
OSPF, ISIS), or it can be done via the management plane (in the case
of centralized path computation). The implementation of a link state
protocol within a network (i.e., across sub-network boundaries) means
that the same protocol runs in OXCs in every sub-network. If this
assumption does not hold then interworking of routing between sub-
networks is required. This is similar to inter-network routing
discussed in Section 6.7. The focus in the following is therefore on
standardized link state routing.
In general, most of the link state routing functionality is
maintained when applied to optical networks. However, the
representation of optical links, as well as some link parameters, are
changed in this setting. Specifically,
o The link state information may consist of link bundles [12]. Each
link bundle is represented as an abstract link in the network
topology. Different bundling representations are possible. For
instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the
underlying link bundle [12]. Also, the SRLGs corresponding to
each optical link in the bundle may be included as a parameter.
o The link state information should capture restoration-related
parameters for optical links. Specifically, with shared
protection (Section 6.5), the link state updates must have
information that allows the computation of shared protection
paths.
o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging
overhead.
o Since link availability information changes dynamically, a
flexible policy for triggering link state updates based on
availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may
trigger updates only after the availability figure changes by a
certain percentage.
These concepts are relatively well-understood. On the other hand,
the resource representation models and the topology discovery process
for hierarchical routing (e.g., OSPF with multiple areas) are areas
that need further work.
6.4. Protection and Restoration Models
Automatic restoration of lightpaths is a service offered by optical
networks. There could be local and end-to-end mechanisms for
restoration of lightpaths within a network (across the INNI). Local
mechanisms are used to select an alternate link (or network segment)
between two OXCs across the INNI when a failure affects the primary
link (or primary network segment) over which the (protected)
lightpath is routed. Local restoration does not affect the end-to-
end route of the lightpath. When local restoration is not possible
(e.g., no alternate link is available between the adjacent OXCs in
question), end-to-end restoration may be performed. Under this
scenario this, the affected lightpath may be rerouted over an
alternate diverse path to circumvent failed resources. For end-to-
end restoration, alternate paths may be pre-computed to expedite the
recovery time. End to end restoration may also be mixed with local
recovery in various ways depending on acceptable tradeoffs between
utilization of network resources and recovery times.
End-to-end protection may be based on two types of protection
schemes; "1 + 1" protection or shared protection. Under 1 + 1
protection, a back-up path is established for the protected primary
path along a physically diverse route. Both paths are active and the
failure along the primary path results in an immediate switch-over to
the back-up path. Under shared protection, back-up paths
corresponding to physically diverse primary paths may share the same
network resources. When a failure affects a primary path, it is
assumed that the same failure will not affect the other primary paths
whose back-ups share resources.
It is possible that different restoration schemes may be implemented
within optical sub-networks. It is therefore necessary to consider a
two-level restoration mechanism. Path failures within an optical
sub-network could be handled using procedures specific to the sub-
network. If this fails, end-to-end restoration across sub-networks
could be invoked. The border OXC that is the ingress to a sub-
network can act as the source for restoration procedures within a
sub-network. The signaling for invoking end-to-end restoration
across the INNI is described in Section 6.6.3. The computation of
the back-up path for end-to-end restoration may be based on various
criteria. It is assumed that the back-up path is computed by the
source OXC, and signaled using standard methods.
6.5. Route Computation
The computation of a primary route for a lightpath within an optical
network is essentially a constraint-based routing problem. The
constraint is typically the bandwidth required for the lightpath,
perhaps along with administrative and policy constraints. The
objective of path computation could be to minimize the total capacity
required for routing lightpaths [13].
Route computation with constraints may be accomplished using a number
of algorithms [14]. When 1+1 protection is used, a back-up path that
does not traverse on any link which is part of the same SRLG as links
in the primary path must be computed. Thus, it is essential that the
SRLGs in the primary path be known during alternate path computation,
along with the availability of resources in links that belong to
other SRLGs. This requirement has certain implications on optical
link bundling. Specifically, a bundled LSA must include adequate
information such that a remote OXC can determine the resource
availability under each SRLG that the bundled link refers to, and the
relationship between links belonging to different SRLGs in the
bundle. For example, considering Figure 3, if links 1,2,3 and 4 are
bundled together in an LSA, the bundled LSA must indicate that there
are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and
that links in SRLGs 2 and 3 are also part of SRLG 1.
To encode the SRLG relationships in a link bundle LSA, only links
which belong to exactly the same set of SRLGs must be bundled
together. With reference to Figure 3, for example, two bundles can
be advertised for links between OXC1 and OXC2, with the following
information:
Bundle No. SRLGs Link Type Number Other Info
-------------------------------------------------------
1 1,2 OC-48 3 ---
2 1,3 OC-192 1 ---
Assuming that the above information is available for each bundle at
every node, there are several approaches possible for path
computation. For instance,
1. The primary path can be computed first, and the (exclusive or
shared) back-up is computed next based on the SRLGs chosen for the
primary path. In this regard,
o The primary path computation procedure can output a series of
bundles the path is routed over. Since a bundle is uniquely
identified with a set of SRLGs, the alternate path can be
computed right away based on this knowledge. In this case, if
the primary path set up does not succeed for lack of resources
in a chosen bundle, the primary and backup paths must be
recomputed.
o It might be desirable to compute primary paths without choosing
a specific bundle apriori. That is, resource availability over
all bundles between a node pair is taken into account rather
than specific bundle information. In this case, the primary
path computation procedure would output a series of nodes the
path traverses. Each OXC in the path would have the freedom to
choose the particular bundle to route that segment of the
primary path. This procedure would increase the chances of
successfully setting up the primary path when link state
information is not up to date everywhere. But the specific
bundle chosen, and hence the SRLGs in the primary path, must be
captured during primary path set-up, for example, using the
RSVP-TE Route Record Object [15]. This SRLG information is
then used for computing the back-up path. The back-up path may
also be established specifying only which SRLGs to avoid in a
given segment, rather than which bundles to use. This would
maximize the chances of establishing the back-up path.
2. The primary path and the back-up path are computed together in one
step, for example, using Suurbaale’s algorithm [16]. In this
case, the paths must be computed using specific bundle
information.
To summarize, it is essential to capture sufficient information in
link bundle LSAs to accommodate different path computation procedures
and to maximize the chances of successful path establishment.
Depending on the path computation procedure used, the type of support
needed during path establishment (e.g., the recording of link group
or SRLG information during path establishment) may differ.
When shared protection is used, the route computation algorithm must
take into account the possibility of sharing links among multiple
back-up paths. Under shared protection, the back-up paths
corresponding to SRLG-disjoint primary paths can be assigned the same
links. The assumption here is that since the primary paths are not
routed over links that have the same SRLG, a given failure will
affect only one of them. Furthermore, it is assumed that multiple
failure events affecting links belonging to more than one SRLG will
not occur concurrently. Unlike the case of 1+1 protection, the
back-up paths are not established apriori. Rather, a failure event
triggers the establishment of a single back-up path corresponding to
the affected primary path.
The distributed implementation of route computation for shared back-
up paths require knowledge about the routing of all primary and
back-up paths at every node. This raises scalability concerns. For
this reason, it may be practical to consider the centralization of
the route computation algorithm in a route server that has complete
knowledge of the link state and path routes. Heuristics for fully
distributed route computation without complete knowledge of path
routes are to be determined. Path computation for restoration is
further described in [11].
6.6. Signaling Issues
Signaling within an optical network for lightpath provisioning is a
relatively simple operation if a standard procedure is implemented
within all sub-networks. Otherwise, proprietary signaling may be
implemented within sub-networks, but converted back to standard
signaling across the INNI. This is similar to signaling across the
ENNI, as described in Section 6.7. In the former case, signaling
messages may carry strict explicit route information, while in the
latter case the route information should be loose, at the level of
abstraction of sub-networks. Once a route is determined for a
lightpath, each OXC along the path must appropriately configure their
cross-connects in a coordinated fashion. This coordination is
conceptually analogous to selecting incoming and outgoing labels in a
label-switched environment. Thus, protocols like RSVP-TE [9] may be
adapted and used across the INNI for this purpose. The adaptation of
IP-based signaling protocols must take into account a number of
peculiar attributes of optical networks.
6.6.1. Bi-Directional Lightpath Establishment
Lightpaths are typically bi-directional. That is, the output port
selected at an OXC for the forward direction is also the input port
for the reverse direction of the path. Since signaling for optical
paths may be autonomously initiated by different nodes, it is
possible that two path set-up attempts are in progress at the same
time. Specifically, while setting up an optical path, an OXC A may
select output port i which is connected to input port j of the "next"
OXC B. Concurrently, OXC B may select output port j for setting up a
different optical path, where the "next" OXC is A. This results in a
"collision". Similarly, when WDM functionality is built into OXCs, a
collision occurs when adjacent OXCs choose directly connected output
ports and the same wavelength for two different optical paths. There
are two ways to deal with such collisions. First, collisions may be
detected and the involved paths may be torn down and re-established.
Or, collisions may be avoided altogether.
6.6.2. Failure Recovery
The impact of transient partial failures must be minimized in an
optical network. Specifically, optical paths that are not directly
affected by a failure must not be torn down due to the failure. For
example, the control processor in an OXC may fail, affecting
signaling and other internodal control communication. Similarly,
the control channel between OXCs may be affected temporarily by a
failure. These failure may not affect already established optical
paths passing through the OXC fabric. The detection of such failures
by adjacent nodes, for example, through a keepalive mechanism between
signaling peers, must not result in these optical paths being torn
down.
It is likely that when the above failures occur, a backup processor
or a backup control channel will be activated. The signaling
protocol must be designed such that it is resilient to transient
failures. During failure recovery, it is desirable to recover local
state at the concerned OXC with least disruption to existing optical
paths.
6.6.3. Restoration
Signaling for restoration has two distinct phases. There is a
reservation phase in which capacity for the protection path is
established. Then, there is an activation phase in which the back-up
path is actually put in service. The former phase typically is not
subject to strict time constraints, while the latter is.
Signaling to establish a "1+1" back-up path is relatively straight-
forward. This signaling is very similar to signaling used for
establishing the primary path. Signaling to establish a shared
back-up path is a little bit different. Here, each OXC must
understand which back-up paths can share resources among themselves.
The signaling message must itself indicate shared reservation. The
sharing rule is as described in Section 6.4: back-up paths
corresponding to physically diverse primary paths may share the same
network resources. It may therefore be necessary for the signaling
message to carry adequate information that allows an OXC to verify
that appropriateness of having a set of back-up paths sharing
certain.
Under both 1+1 and shared protection, the activation phase has two
parts: propagation of failure information to the source OXC from the
point of failure, and activation of the back-up path. The signaling
for these two phases must be very fast in order to realize response
times in the order of tens of milliseconds. When optical links are
SONET-based, in-band signals may be used, resulting in expedited
response. With out-of-band control, it may be necessary to consider
fast signaling over the control channel using very short IP packets
and prioritized processing. While it is possible to use RSVP or CR-
LDP for activating protection paths, these protocols do not provide
any means to give priority to restoration signaling as opposed to
signaling for provisioning. For instance, it is possible for a
restoration-related RSVP message to be queued behind a number of
provisioning messages thereby delaying restoration. It may therefore
be necessary to develop a notion of prioritization for restoration
signaling and incorporate appropriate mechanisms into existing
signaling protocols to achieve this. Alternatively, a new signaling
mechanism may be developed exclusively for activating protection
paths during restoration.
6.7. Optical Internetworking
Within an optical internetwork, it must be possible to dynamically
provision and restore lightpaths across optical networks. Therefore:
o A standard scheme for uniquely identifying lightpath end-points in
different networks is required.
o A protocol is required for determining reachability of end-points
across networks.
o A standard signaling protocol is required for provisioning
lightpaths across networks.
o A standard procedure is required for the restoration of lightpaths
across networks.
o Support for policies that affect the flow of control information
across networks will be required.
The IP-centric control architecture for optical networks can be
extended to satisfy the functional requirements of optical
internetworking. Routing and signaling interaction between optical
networks can be standardized across the ENNI (Figure 1). The
functionality provided across ENNI is as follows.
6.7.1. Neighbor Discovery
Neighbor discovery procedure, as described in Section 6.2, can be
used for this. Indeed, a single protocol should be standardized for
neighbor discovery within and across networks.
6.7.2. Addressing and Routing Model
The addressing mechanisms described in Section 6.1 can be used to
identify OXCs, ports, channels and sub-channels in each network. It
is essential that the OXC IP addresses are unique within the
internetwork.
Provisioning an end-to-end lightpath across multiple networks
involves the establishment of path segments in each network
sequentially. Thus, a path segment is established from the source
OXC to a border OXC in the source network. From this border OXC,
signaling across NNI is used to establish a path segment to a border
OXC in the next network. Provisioning then continues in the next
network and so on until the destination OXC is reached. The usage of
protocols like BGP for this purpose need to be explored.
6.7.3. Restoration
Local restoration across the ENNI is similar to that across INNI
described in Section 6.6.3. End-to-end restoration across networks
is likely to be either of the 1+1 type, or segmented within each
network, as described in Section 6.4.
7. Other Issues
7.1. WDM and TDM in the Same Network
A practical assumption would be that if SONET (or some other TDM
mechanism that is capable partitioning the bandwidth of a wavelength)
is used, then TDM is leveraged as an additional method to
differentiate between "flows". In such cases, wavelengths and time
intervals (sub-channels) within a wavelength become analogous to
labels (as noted in [1]) which can be used to make switching
decisions. This would be somewhat akin to using VPI (e.g.,
wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More
generally, this will be akin to label stacking and to LSP nesting
within the context of Multi-Protocol Lambda Switching [1]. GMPLS
signaling [4] supports this type of multiplexing.
7.2. Wavelength Conversion
Some form of wavelength conversion may exist at some switching
elements. This however may not be the case in some pure optical
switching elements. A switching element is essentially anything more
sophisticated than a simple repeater, that is capable of switching
and converting a wavelength Lambda(k) from an input port to a
wavelength Lambda(l) on an output port. In this display, it is not
necessarily the case that Lambda(k) = Lambda(l), nor is it
necessarily the case that the data carried on Lambda(k) is switched
through the device without being examined or modified.
It is not necessary to have a wavelength converter at every switching
element. A number of studies have attempted to address the issue of
the value of wavelength conversion in an optical network. Such
studies typically use the blocking probability (the probability that
a lightpath cannot be established because the requisite wavelengths
are not available) as a metric to adjudicate the effectiveness of
wavelength conversion. The IP over optical architecture must take
into account hybrid networks with some OXCs capable of wavelength
conversion and others incapable of this. The GMPLS "label set"
mechanism [4] supports the selection of the same label (i.e.,
wavelength) across an NNI.
7.3. Service Provider Peering Points
There are proposed inter-network interconnect models which allow
certain types of peering relationships to occur at the optical layer.
This is consistent with the need to support optical layer services
independent of higher layers payloads. In the context of IP over
optical networks, peering relationships between different trust
domains will eventually have to occur at the IP layer, on IP routing
elements, even though non-IP paths may exist between the peering
routers.
7.4. Rate of Lightpath Set-Up
Dynamic establishment of optical channel trails and lightpaths is
quite desirable in IP over optical networks, especially when such
instantiations are driven by a stable traffic engineering control
system, or in response to authenticated and authorized requests from
clients.
However, there are many proposals suggesting the use of dynamic,
data-driven shortcut-lightpath setups in IP over optical networks.
The arguments put forth in such proposals are quite reminiscent of
similar discussions regarding ATM deployment in the core of IP
networks. Deployment of highly dynamic data driven shortcuts within
core networks has not been widely adopted by carriers and ISPs for a
number of reasons: possible CPU overhead in core network elements,
complexity of proposed solutions, stability concerns, and lack of
true economic drivers for this type of service. This document
assumes that this paradigm will not change and that highly dynamic,
data-driven shortcut lightpath setups are for future investigation.
Instead, the optical channel trails and lightpaths that are expected
to be widely used at the initial phases in the evolution of IP over
optical networks will include the following:
o Dynamic connections for control plane traffic and default path
routed data traffic,
o Establishment and re-arrangement of arbitrary virtual topologies
over rings and other physical layer topologies.
o Use of stable traffic engineering control systems to engineer
lightpath connections to enhance network performance, either for
explicit demand based QoS reasons or for load balancing).
Other issues surrounding dynamic connection setup within the core
center around resource usage at the edge of the optical domain. One
potential issue pertains to the number of flows that can be processed
by an ingress or egress network element either because of aggregate
bandwidth limitations or because of a limitation on the number of
flows (e.g., lightpaths) that can be processed concurrently.
Another possible short term reason for dynamic shortcut lightpath
setup would be to quickly pre-provision paths based on some criteria
(e.g., a corporate executive wants a high bandwidth reliable
connection, etc.). In this scenario, a set of paths can be pre-
provisioned, but not actually instantiated until the customer
initiates an authenticated and authorized setup requests, which is
consistent with existing agreements between the provider and the
customer. In a sense, the provider may have already agreed to supply