| |
+-------+-----------------------+-------+
| |
| Optical Network |
| |
+-------+-----------------------+-------+
| |
UNI UNI
| |
+-----+----- --+ +-----+------+
| | | |
| Other Client | |Other Client|
| Network | | Network |
| (e.g., ATM) | | |
+- ------------+ +------------+
Figure 1: Optical Internetwork Model
Multiple traffic streams exiting from an OXC may be multiplexed onto
a fiber optic link using WDM technology. The WDM functionality may
exist outside of the OXC, and be transparent to the OXC. Or, this
function may be built into the OXC. In the later case, the cross-
connect table (conceptually) consists of pairs of the form, <{input
port i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that
the data stream received on wavelength Lambda(j) over input port i is
switched to output port k on Lambda(l). Automated establishment of
lightpaths involves setting up the cross-connect table entries in the
appropriate OXCs in a coordinated manner such that the desired
physical path is realized.
Under this network model, a switched lightpath must be established
between a pair of IP routers before the routers can transfer user
traffic among themselves. A lightpath between IP routers may
traverse multiple optical networks and be subject to different
provisioning and restoration procedures in each network.
The IP-based control plane issue for optical networks pertains to the
design of standard signaling and routing protocols for provisioning
and restoration of lightpaths across multiple optical networks.
Similarly, IP transport over optical networks involves establishing
IP reachability and seamlessly constructing forwarding paths from one
IP endpoint to another over an optical network.
3.2. Control Structure
There are three logical control interfaces identified in Figure 1.
These are the client-optical internetwork interface, the internal
node-to-node interface within an optical network (between OXCs in
different sub-networks), and the external node-to-node interface
between nodes in different optical networks. These interfaces are
also referred to as the User-Network Interface (UNI), the internal
NNI (INNI), and the external NNI (ENNI), respectively.
The distinction between these interfaces arises out of the type and
amount of control information flow across them. The client-optical
internetwork interface (UNI) represents a service boundary between
the client (e.g., IP router) and the optical network. The client and
server (optical network) are essentially two different roles: the
client role requests a service connection from a server; the server
role establishes the connection to fulfill the service request --
provided all relevant admission control conditions are satisfied.
Thus, the control flow across the client-optical internetwork
interface is dependent on the set of services defined across it and
the manner in which the services may be accessed. The service models
are described in Section 4. The NNIs represent vendor-independent
standardized interfaces for control flow between nodes. The
distinction between the INNI and the ENNI is that the former is an
interface within a given network under a single technical
administration, while the later indicates an interface at the
administrative boundary between networks. The INNI and ENNI may thus
differ in the policies that restrict control flow between nodes.
Security, scalability, stability, and information hiding are
important considerations in the specification of the ENNI. It is
possible in principle to harmonize the control flow across the UNI
and the NNI and eliminate the distinction between them. On the other
hand, it may be required to minimize flow of control information,
especially routing-related information, over the UNI; and even over
the ENNI. In this case, UNI and NNIs may look different in some
respects. In this document, these interfaces are treated as
distinct.
The client-optical internetwork interface can be categorized as
public or private depending upon context and service models. Routing
information (i.e., topology state information) can be exchanged
across a private client-optical internetwork interface. On the other
hand, such information is not exchanged across a public client-
optical internetwork interface, or such information may be exchanged
with very explicit restrictions (including, for example abstraction,
filtration, etc). Thus, different relationships (e.g., peer or
over-lay, Section 5) may occur across private and public logical
interfaces.
The physical control structure used to realize these logical
interfaces may vary. For instance, for the client-optical
internetwork interface, some of the possibilities are:
1. Direct interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between an edge router and each OXC to
which it is connected. This control channel is used for
exchanging signaling and routing messages between the router and
the OXC. With a direct interface, the edge router and the OXC it
connects to are peers with respect to the control plane. This
situation is shown in Figure 2. The type of routing and signaling
information exchanged across the direct interface may vary
depending on the service definition. This issue is addressed in
the next section. Some choices for the routing protocol are OSPF
or ISIS (with traffic engineering extensions and additional
enhancements to deal with the peculiar characteristics of optical
networks) or BGP, or some other protocol. Other directory-based
routing information exchanges are also possible. Some of the
signaling protocol choices are adaptations of RSVP-TE or CR-LDP.
The details of how the IP control channel is realized is outside
the scope of this document.
2. Indirect interface: An out-of-band IP control channel may be
implemented between the client and a device in the optical network
to signal service requests and responses. For instance, a
management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling
may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective OXCs.
One reason to have an indirect interface would be that the OXCs
and/or clients do not support a direct signaling interface.
+---------------------------+ +---------------------------+
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | |
| | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | |
| | IP Layer +....IPCC.....+ IP Layer | |
| | | | | | | |
| +------------------+ | | +------------------+ |
| | | |
| Edge Router | | OXC |
+---------------------------+ +---------------------------+
Figure 2: Direct Interface
3. Provisioned interface: In this case, the optical network services
are manually provisioned and there is no control interactions
between the client and the optical network.
Although different control structures are possible, further
descriptions in this framework assume direct interfaces for IP-
optical and optical sub-network control interactions.
4. IP over Optical Service Models and Requirements
In this section, the service models and requirements at the UNI and
the NNIs are considered. Two general models have emerged for the
services at the UNI (which can also be applied at the NNIs). These
models are as follows.
4.1. Domain Services Model
Under the domain services model, the optical network primarily offers
high bandwidth connectivity in the form of lightpaths. Standardized
signaling across the UNI (Figure 1) is used to invoke the following
services:
1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and
security procedures.
2. Lightpath deletion: This service allows an existing lightpath to
be deleted.
3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified.
4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath.
An end-system discovery procedure may be used over the UNI to verify
local port connectivity between the optical and client devices, and
allows each device to bootstrap the UNI control channel. Finally, a
"service discovery" procedure may be employed as a precursor to
obtaining UNI services. Service discovery allows a client to
determine the static parameters of the interconnection with the
optical network, including the UNI signaling protocols supported.
The protocols for neighbor and service discovery are different from
the UNI signaling protocol itself (for example, see LMP [2]).
Because a small set of well-defined services is offered across the
UNI, the signaling protocol requirements are minimal. Specifically,
the signaling protocol is required to convey a few messages with
certain attributes in a point-to-point manner between the router and
the optical network. Such a protocol may be based on RSVP-TE or LDP,
for example.
The optical domain services model does not deal with the type and
nature of routing protocols within and across optical networks.
The optical domain services model would result in the establishment
of a lightpath topology between routers at the edge of the optical
network. The resulting overlay model for IP over optical networks is
discussed in Section 5.
4.2. Unified Service Model
Under this model, the IP and optical networks are treated together as
a single integrated network from a control plane point of view. In
this regard, the OXCs are treated just like any other router as far
as the control plane is considered. Thus, in principle, there is no
distinction between the UNI, NNIs and any other router-to-router
interface from a routing and signaling point of view. It is assumed
that this control plane is IP-based, for example leveraging the
traffic engineering extensions for MPLS or GMPLS, as described in
[1]. The unified service model has so far been discussed only in the
context of a single administrative domain. A unified control plane
is possible even when there are administrative boundaries within an
optical internetwork, but some of the integrated routing capabilities
may not be practically attractive or even feasible in this case (see
Section 5).
Under the unified service model and within the context of a GMPLS
network, optical network services are obtained implicitly during
end-to-end GMPLS signaling. Specifically, an edge router can create
a lightpath with specified attributes, or delete and modify
lightpaths as it creates GMPLS label-switched paths (LSPs). In this
regard, the services obtained from the optical network are similar to
the domain services model. These services, however, may be invoked
in a more seamless manner as compared to the domain services model.
For instance, when routers are attached to a single optical network
(i.e., there are no ENNIs), a remote router could compute an end-to-
end path across the optical internetwork. It can then establish an
LSP across the optical internetwork. But the edge routers must still
recognize that an LSP across the optical internetwork is a
lightpath, or a conduit for multiple packet-based LSPs.
The concept of "forwarding adjacency" can be used to specify virtual
links across optical internetworks in routing protocols such as OSPF
[3]. In essence, once a lightpath is established across an optical
internetwork between two edge routers, the lightpath can be
advertised as a forwarding adjacency (a virtual link) between these
routers. Thus, from a data plane point of view, the lightpaths
result in a virtual overlay between edge routers. The decisions as
to when to create such lightpaths, and the bandwidth management for
these lightpaths is identical in both the domain services model and
the unified service model. The routing and signaling models for
unified services is described in Sections 5 and 6.
4.3. Which Service Model?
The relative merits of the above service models can be debated at
length, but the approach recommended in this framework is to define
routing and signaling mechanisms in support of both models. As noted
above, signaling for service requests can be unified to cover both
models. The developments in GMPLS signaling [4] for the unified
service model and its adoption for UNI signaling [5, 6] under the
domain services model essentially supports this view. The
significant difference between the service models, however, is in
routing protocols, as described in Sections 5 and 6.
4.4. What are the Possible Services?
Specialized services may be built atop the point-to-point
connectivity service offered by the optical network. For example,
optical virtual private networks and bandwidth on demand are some of
the services that can be envisioned.
4.4.1. Optical Virtual Private Networks (OVPNs)
Given that the data plane links between IP routers over an optical
network amounts to a virtual topology which is an overlay over the
fiber optic network, it is easy to envision a virtual private network
of lightpaths that interconnect routers (or any other set of clients)
belonging to a single entity or a group of related entities across a
public optical network. Indeed, in the case where the optical
network provides connectivity for multiple sets of external client
networks, there has to be a way to enforce routing policies that
ensure routing separation between different sets of client networks
(i.e., VPN service).
5. IP transport over Optical Networks
To examine the architectural alternatives for IP over optical
networks, it is important to distinguish between the data and control
planes. The optical network provides a service to external entities
in the form of fixed bandwidth transport pipes (optical paths). IP
routers at the edge of the optical networks must necessarily have
such paths established between them before communication at the IP
layer can commence. Thus, the IP data plane over optical networks is
realized over a virtual topology of optical paths. On the other
hand, IP routers and OXCs can have a peer relation with respect to
the control plane, especially for routing protocols that permit the
dynamic discovery of IP endpoints attached to the optical network.
The IP over optical network architecture is defined essentially by
the organization of the control plane. The assumption in this
framework is that an IP-based control plane [1] is used, such as
GMPLS. Depending on the service model(Section 4), however, the
control planes in the IP and optical networks can be loosely or
tightly coupled. This coupling determines the following
characteristics:
o The details of the topology and routing information advertised by
the optical network across the client interface;
o The level of control that IP routers can exercise in selecting
explicit paths for connections across the optical network;
o Policies regarding the dynamic provisioning of optical paths
between routers. These include access control, accounting, and
security issues.
The following interconnection models are then possible:
5.1. Interconnection Models
5.1.1. The Peer Model
Under the peer model, the IP control plane acts as a peer of the
optical transport network control plane. This implies that a single
instance of the control plane is deployed over the IP and optical
domains. When there is a single optical network involved and the IP
and optical domains belong to the same entity, then a common IGP such
as OSPF or IS-IS, with appropriate extensions, can be used to
distribute topology information [7] over the integrated IP-optical
network. In the case of OSPF, opaque LSAs can be used to advertise
topology state information. In the case of IS-IS, extended TLVs will
have to be defined to propagate topology state information. Many of
these extensions are occurring within the context of GMPLS.
When an optical internetwork with multiple optical networks is
involved (e.g., spanning different administrative domains), a single
instance of an intra-domain routing protocol is not attractive or
even realistic. In this case, inter-domain routing and signaling
protocols are needed. In either case, a tacit assumption is that a
common addressing scheme will be used for the optical and IP
networks. A common address space can be trivially realized by using
IP addresses in both IP and optical domains. Thus, the optical
network elements become IP addressable entities as noted in [1].
5.1.2. The Overlay Model
Under the overlay model, the IP layer routing, topology distribution,
and signaling protocols are independent of the routing, topology
distribution, and signaling protocols within the optical domain.
This model is conceptually similar to the classical IP over ATM or
MPOA models, but applied to an optical internetwork instead. In the
overlay model, a separate instance of the control plane (especially
the routing and signaling protocols) would have to be deployed in the
optical domain, independent of what exists in the IP domain. In
certain circumstances, it may also be feasible to statically
configure the optical channels that provide connectivity for the IP
domain in the overlay model. Static configuration can be effected
through network management functions. Static configuration, however,
is unlikely to scale in very large networks, and may not support the
rapid connection provisioning requirements of future highly
competitive networking environments.
5.1.3. The Augmented Model
Under the augmented model, there are separate routing instances in
the IP and optical domains, but certain types of information from one
routing instance can be passed through to the other routing instance.
For example, external IP addresses could be carried within the
optical routing protocols to allow reachability information to be
passed to IP clients.
The routing approaches corresponding to these interconnection models
are described below.
5.2. Routing Approaches
5.2.1. Integrated Routing
This routing approach supports the peer model within a single
administrative domain. Under this approach, the IP and optical
networks are assumed to run the same instance of an IP routing
protocol, e.g., OSPF with suitable "optical" extensions. These
extensions must capture optical link parameters, and any constraints
that are specific to optical networks. The topology and link state
information maintained by all nodes (OXCs and routers) may be
identical, but not necessarily. This approach permits a router to
compute an end-to-end path to another router across the optical
network. Suppose the path computation is triggered by the need to
route a label switched path (LSP) in a GMPLS environment. Such an
LSP can be established using GMPLS signaling, e.g., RSVP-TE or CR-LDP
with appropriate extensions. In this case, the signaling protocol
will establish a lightpath between two edge routers. This lightpath
is in essence a tunnel across the optical network, and may have
capacity much larger than the bandwidth required to support the first
LSP. Thus, it is essential that other routers in the network realize
the availability of excess capacity within the lightpath so that
subsequent LSPs between the routers can use it rather than
instantiating a new lightpath. The lightpath may therefore be
advertised as a virtual link in the topology as a means to address
this issue.
The notion of "forwarding adjacency" (FA) described in [3] is
essential in propagating existing lightpath information to other
routers. An FA is essentially a virtual link advertised into a link
state routing protocol. Thus, an FA could be described by the same
parameters that define resources in any regular link. While it is
necessary to specify the mechanism for creating an FA, it is not
necessary to specify how an FA is used by the routing scheme. Once
an FA is advertised in a link state protocol, its usage for routing
LSPs is defined by the route computation and traffic engineering
algorithms implemented.
It should be noted that at the IP-optical interface, the physical
ports over which routers are connected to OXCs constrain the
connectivity and resource availability. Suppose a router R1 is
connected to OXC O1 over two ports, P1 and P2. Under integrated
routing, the connectivity between R1 and O1 over the two ports would
have been captured in the link state representation of the network.