Now, suppose an FA at full port bandwidth is created from R1 to
another router R2 over port P1. While this FA is advertised as a
virtual link between R1 and R2, it is also necessary to remove the
link R1-O1 (over P1) from the link state representation since that
port is no longer available for creating a lightpath. Thus, as FAs
are created, an overlaid set of virtual links is introduced into the
link state representation, replacing the links previously advertised
at the IP-Optical interface. Finally, the details of the optical
network captured in the link state representation is replaced by a
network of FAs. The above scheme is one way to tackle the problem.
Another approach is to associate appropriate dynamic attributes with
link state information, so that a link that cannot be used to
establish a particular type of connection will be appropriately
tagged. Generally, however, there is a great deal of similarity
between integrated routing and domain-specific routing (described
next). Both ultimately deal with the creation of a virtual
lightpath topology (which is overlaid over the optical network) to
meet certain traffic engineering objectives.
5.2.2. Domain-Specific Routing
The domain-specific routing approach supports the augmented
interconnection model. Under this approach, routing within the
optical and IP domains are separated, with a standard routing
protocol running between domains. This is similar to the IP inter-
domain routing model. A specific approach for this is considered
next. It is to be noted that other approaches are equally possible.
5.2.2.1. Domain-Specific Routing using BGP
The inter-domain IP routing protocol, BGP [8], may be adapted for
exchanging routing information between IP and optical domains. This
would allow routers to advertise IP address prefixes within their
network to the optical internetwork and to receive external IP
address prefixes from the optical internetwork. The optical
internetwork transports the reachability information from one IP
network to others. For instance, edge routers and OXCs can run
exterior BGP (EBGP). Within the optical internetwork, interior BGP
(IBGP) is may be used between border optical switches, and EBGP may
be used between different networks (over ENNI, Figure 1).
Under this scheme, it may be necessary to identify the egress points
in the optical internetwork corresponding to externally reachable IP
addresses. To see this, suppose an edge router intends to establish
an LSP to a destination node across the optical internetwork. It may
request a direct lightpath to that destination, without explicitly
specifying the egress optical port for the lightpath because the
optical internetwork has knowledge of externally reachable IP
addresses. However, if the same edge router were to establish
another LSP to a different external destination, then for efficiency
reasons, it may first need to determine whether there is an existing
lightpath (with sufficient residual capacity) to the target
destination. For this purpose, it may be necessary for edge routers
to keep track of which egress ports in the optical internetwork lead
to which external destinations. Thus, a border OXC receiving
external IP prefixes from an edge router through EBGP must include
its own IP address as the egress point before propagating these
prefixes to other border OXCs or edge routers. An edge router
receiving this information need not propagate the egress address
further, but it must keep the association between external IP
addresses and egress OXC addresses. When optical VPNs are
implemented, the address prefixes advertised by the border OXCs may
be accompanied by some VPN specific identification.
There are however, some potential negative effects that could result
from domain-specific routing using BGP in an IPO environment:
o The amount of information that optical nodes will have to maintain
will not be bound by the size of the optical network anymore, but
will have to include external routes as well.
o The stability of the optical network control plane will no longer
be dictated solely by the dynamics emanating within the optical
network, but may be affected by the dynamics originating from
external routing domains from which external reachability
information is received.
5.2.3. Overlay Routing
The overlay routing approach supports the overlay interconnection
model. Under this approach, an overlay mechanism that allows edge
routers to register and query for external addresses is implemented.
This is conceptually similar to the address resolution mechanism used
for IP over ATM. Under this approach, the optical network could
implement a registry that allows edge routers to register IP
addresses and VPN identifiers. An edge router may be allowed to
query for external addresses belonging to the same set of VPNs it
belongs to. A successful query would return the address of the
egress optical port through which the external destination can be
reached.
Because IP-optical interface connectivity is limited, the
determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions. Furthermore, after an
initial set of such lightpaths are established, these may be used as
adjacencies within VPNs for a VPN-wide routing scheme, for example,
OSPF. With this approach, an edge router could first determine other
edge routers of interest by querying the registry. After it obtains
the appropriate addresses, an initial overlay lightpath topology may
be formed. Routing adjacencies may then be established across the
lightpaths and further routing information may be exchanged to
establish VPN-wide routing.
5.3. Signaling-Related
5.3.1. The Role of MPLS
It is possible to model wavelengths, and potentially TDM channels
within a wavelength as "labels". This concept was proposed in [1],
and "generalized" MPLS (GMPLS) mechanisms for realizing this are
described in [4]. MPLS signaling protocols with traffic engineering
extensions, such as RSVP-TE, can be appropriately extended and used
for signaling lightpath requests. These protocols can be adapted for
client/server signaling in the case of the domain services model, and
for end-to-end integrated signaling in the case of the unified
services model.
5.3.2. Signaling Models
With the domain-services model, the signaling control plane in the IP
and optical network are completely separate as shown in Figure 3
below. This separation also implies the separation of IP and optical
address spaces (even though the optical network would be using
internal IP addressing). While RSVP-TE and LDP can be adapted for
UNI signaling, the full functionality of these protocols will not be
used. For example, UNI signaling does not require the specification
of explicit routes. On the other hand, based on the service
attributes, new objects need to be signaled using these protocols as
described in [5, 6].
MPLS Signaling UNI Signaling MPLS or other signaling
|
+-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Internetwork |
| +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+
|
|
Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling Model
With the unified services model, the addressing is common in the IP
network and optical internetwork and the respective signaling control
are related, as shown in Figure 4. It is understood that GMPLS
signaling is implemented in the IP and optical domains, using
suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of
services within the optical internetwork may be different from that
in the IP network. As an example, the protection services offered in
the optical internetwork may be different from the end-to-end
protection services offered by the IP network. Another example is
with regard to bandwidth. While the IP network may offer a continuum
of bandwidths, the optical internetwork will offer only discrete
bandwidths. Thus, the signaling attributes and services are defined
independently for IP and optical domains. The routers at the edge of
the optical internetwork must therefore identify service boundaries
and perform suitable translations in the signaling messages crossing
the IP-optical boundary. This may still occur even though the
signaling control plane in both networks are GMPLS-based and there is
tighter coupling of the control plane as compared to the domain
services model.
Service Boundary Service Boundary
| |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| |
+--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
| | | | | | LSR | | LSR | | | |
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
Common Address Space, Service Translation
Figure 4: Unified Services Signaling Model
Thus, as illustrated in Figure 4, the signaling in the case of
unified services is actually multi-layered. The layering is based on
the technology and functionality. As an example, the specific
adaptations of GMPLS signaling for SONET layer (whose functionality
is transport) are described in [10].
5.4. End-to-End Protection Models
Suppose an LSP is established from an ingress IP router to an egress
router across an ingress IP network, a transit optical internetwork
and an egress IP network. If this LSP is to be afforded protection
in the IP layer, how is the service coordinated between the IP and
optical layers?
Under this scenario, there are two approaches to end-to-end
protection:
5.4.1. Segment-Wise Protection
The protection services in the IP layer could utilize optical layer
protection services for the LSP segment that traverses the optical
internetwork. Thus, the end-to-end LSP would be treated as a
concatenation of three LSP segments from the protection point of
view: a segment in the ingress IP network, a segment in the optical
internetwork and a segment in the egress IP network. The protection
services at the IP layer for an end-to-end LSP must be mapped onto
suitable protection services offered by the optical internetwork.
Suppose that 1+1 protection is offered to LSPs at the IP layer, i.e.,
each protected LSP has a pre-established hot stand-by in a 1+1 or 1:1
configuration. In case of a failure of the primary LSP, traffic can
be immediately switched to the stand-by. This type of protection can
be realized end-to-end as follows. With reference to Figure 5, let
an LSP originate at (ingress) router interface A and terminate at
(egress) router interface F. Under the first protection option, a
primary path for the LSP must be established first. Let this path be
as shown in Figure 5, traversing router interface B in the ingress
network, optical ports C (ingress) and D (egress), and router
interface E in the egress network. Next, 1+1 protection is realized
separately in each network by establishing a protection path between
points A and B, C and D and E and F. Furthermore, the segments B-C
and D-E must themselves be 1+1 protected, using drop- side
protection. For the segment between C and D, the optical
internetwork must offer a 1+1 service similar to that offered in the
IP networks.
+----------------+ +------------------+ +---------------+
| | | | | |
A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
| | | | | |
+----------------+ +------------------+ +---------------+
Figure 5: End-to-End Protection Example
5.4.2. Single-Layer Protection
Under this model, the protection services in the IP layer do not rely
on any protection services offered in the optical internetwork. Thus,
with reference to Figure 5, two SRLG-disjoint LSPs are established
between A and F. The corresponding segments in the optical
internetwork are treated as independent lightpaths in the optical
internetwork. These lightpaths may be unprotected in the optical
internetwork.
5.4.3. Differences
A distinction between these two choices is as follows. Under the
first choice, the optical internetwork is actively involved in end-
to-end protection, whereas under the second choice, any protection
service offered in the optical internetwork is not utilized directly
by client IP network. Also, under the first choice, the protection
in the optical internetwork may apply collectively to a number of IP
LSPs. That is, with reference to Figure 5, many LSPs may be
aggregated into a single lightpath between C and D. The optical
internetwork protection may then be applied to all of them at once
leading to some gain in scalability. Under the second choice, each
IP LSP must be separately protected. Finally, the first choice
allows different restoration signaling to be implemented in the IP
and optical internetwork. These restoration protocols are "patched
up" at the service boundaries to realize end-to-end protection. A
further advantage of this is that restoration is entirely contained
within the network where the failure occurs, thereby improving the
restoration latency, and perhaps network stability as a fault within
an optical domain is contained and corrected within the domain. For
instance, if there is a failure in the optical internetwork, optical
network protocols restore the affected internal segments. Under the
second choice, restoration signaling is always end-to-end between IP
routers, essentially by-passing the optical internetwork. A result
of this is that restoration latency could be higher. In addition,
restoration protocols in the IP layer must run transparently over the
optical internetwork in the overlay mode. IP based recovery
techniques may however be more resource efficient, as it may be
possible to convey traffic through the redundant capacity under
fault-free scenarios. In particular, it may be possible to utilize
classification, scheduling, and concepts of forwarding equivalence
class to route lower class traffic over protect facilities and then
possibly preempt them to make way for high priority traffic when
faults occur.
6. IP-based Optical Control Plane Issues
Provisioning and restoring lightpaths end-to-end between IP networks
requires protocol and signaling support within optical sub-networks,
and across the INNI and ENNI. In this regard, a distinction is made
between control procedures within an optical sub-network (Figure 1),
between sub-networks, and between networks. The general guideline
followed in this framework is to separate these cases, and allow the
possibility that different control procedures are followed inside
different sub-networks, while a common set of procedures are followed
across sub-networks and networks.
The control plane procedures within a single vendor sub-network need
not be defined since these can be proprietary. Clearly, it is
possible to follow the same control procedures inside a sub-network
and across sub-networks. But this is simply a recommendation within
this framework document, rather than an imperative requirement. Thus,
in the following, signaling and routing across sub-networks is
considered first, followed by a discussion of similar issues across
networks.
6.1. Addressing
For interoperability across optical sub-networks using an IP-centric
control plane, one of the fundamental issues is that of addressing.
What entities should be identifiable from a signaling and routing
point of view? How should they be addressed? This section presents
some high level guidelines on this issue.
Identifiable entities in optical networks include OXCs, optical
links, optical channels and sub-channels, Shared Risk Link Groups
(SRLGs), etc. An issue here is how granular the identification
should be as far as the establishment of optical trails are
concerned. The scheme for identification must accommodate the
specification of the termination points in the optical network with
adequate granularity when establishing optical trails. For instance,
an OXC could have many ports, each of which may in turn terminate
many optical channels, each of which contain many sub-channels etc.
It is perhaps not reasonable to assume that every sub-channel or
channel termination, or even OXC ports could be assigned a unique IP
address. Also, the routing of an optical trail within the network
does not depend on the precise termination point information, but
rather only on the terminating OXC. Thus, finer granularity
identification of termination points is of relevance only to the
terminating OXC and not to intermediate OXCs (of course, resource
allocation at each intermediate point would depend on the granularity
of resources requested). This suggests an identification scheme
whereby OXCs are identified by a unique IP address and a "selector"
identifies further fine-grain information of relevance at an OXC.
This, of course, does not preclude the identification of these
termination points directly with IP addresses(with a null selector).
The selector can be formatted to have adequate number of bits and a
structure that expresses port, channel, sub-channel, etc,
identification.
Within the optical network, the establishment of trail segments
between adjacent OXCs require the identification of specific port,
channel, sub-channel, etc. With a GMPLS control plane, a label
serves this function. The structure of the label must be such that
it can encode the required information [10].
Another entity that must be identified is the SRLG [11]. An SRLG is
an identifier assigned to a group of optical links that share a
physical resource. For instance, all optical channels routed over
the same fiber could belong to the same SRLG. Similarly, all fibers
routed over a conduit could belong to the same SRLG. The notable
characteristic of SRLGs is that a given link could belong to more
than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs. This is illustrated in
Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links
1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
contains links from two different adjacencies).
While the classification of physical resources into SRLGs is a manual
operation, the assignment of unique identifiers to these SRLGs
within an optical network is essential to ensure correct SRLG-
disjoint path computation for protection. SRLGs could be identified
with a flat identifier (e.g., 32 bit integer).
Finally, optical links between adjacent OXCs may be bundled for
advertisement into a link state protocol [12]. A bundled interface
may be numbered or unnumbered. In either case, the component links
within the bundle must be identifiable. In concert with SRLG
identification, this information is necessary for correct path
computation.
6.2. Neighbor Discovery
Routing within the optical network relies on knowledge of network
topology and resource availability. This information may be gathered
and used by a centralized system, or by a distributed link state
routing protocol. In either case, the first step towards network-
wide link state determination is the discovery of the status of local
links to all neighbors by each OXC. Specifically, each OXC must
determine the up/down status of each optical link, the bandwidth and
other parameters of the link, and the identity of the remote end of
the link (e.g., remote port number). The last piece of information
is used to specify an appropriate label when signaling for lightpath
provisioning. The determination of these parameters could be based
on a combination of manual configuration and an automated protocol
running between adjacent OXCs. The characteristics of such a
protocol would depend on the type of OXCs that are adjacent (e.g.,
transparent or opaque).
Neighbor discovery would typically require in-band communication on
the bearer channels to determine local connectivity and link status.
In the case of opaque OXCs with SONET termination, one instance of a
neighbor discovery protocol (e.g., LMP [2]) would run on each OXC
port, communicating with the corresponding protocol instance at the
neighboring OXC. The protocol would utilize the SONET overhead bytes
to transmit the (configured) local attributes periodically to the
neighbor. Thus, two neighboring switches can automatically determine
the identities of each other and the local connectivity, and also
keep track of the up/down status of local links. Neighbor discovery
with transparent OXCs is described in [2].
+--------------+ +------------+ +------------+
| +-1:OC48---+ +-5:OC192-+ |
| +-2:OC48---+ +-6:OC192-+ |
| OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 |
| +-4:OC192--+ +-8:OC48--+ |
| | | | +------+ |
+--------------+ +----+-+-----+ | +----+------+-----+
| | | | |
| | | | |
+--------------+ | | | | |
| | +----+-+-----+ | | +------+-----+
| +----------+ +--+ | | |
| OXC4 +----------+ +----+ | |
| +----------+ OXC5 +--------+ OXC6 |