MPLS Working Group Murali Krishnaswamy
Internet Draft George Newsome
Joe Gajewski
Antonio Rodriguez-Moral
Lucent Technologies
Stephen Shew
Michael Mayer
Nortel Networks
Expires August 24 2000 25 February 2000
MPLS control plane for Switched Optical Networks
<draft-krishnaswamy-mpls-son-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Krishna MPLS control plane for Switched Optical Networks [Page 1]
Internet Draft February 2000
Abstract
The advent of switched multi-channel (WDM) optical networks using
OXCs (Optical Cross-connects) presents many new opportunities for
supporting faster and more flexible provision of IP services. Key to
realizing such opportunities is providing the ability to
automatically set-up and tear-down paths (optical channels) across
the optical network, and provide means for IP services to leverage
this capability. Therefore, it is necessary to establish supporting
protocols and mechanisms. In this draft we study the requirements and
mechanisms for optical network topology discovery, signaling path
setup, data path computation, and optical channel set-up. We leverage
MPLS and other IP based protocols as a basis for achieving the above
objectives.
1. Introduction
Within an optical transport network (OTN), OXCs switch optical
channels, analogous to how routers switch packets in an IP network.
However, there are a number of differences, such as bandwidth
granularity, which is much coarser for an OXC than that for an IP
router. Additionally, routers need to inspect each IP packet for
route computation. Even when a LSP is setup, the routers still need
to inspect ingress traffic and perform label swapping operations. On
the other hand, OXCs operate on per optical channel (wavelength)
basis, and there is no equivalent IP packet routing or label swapping
operation involved (Optical Label Switching). Instead the entire
traffic on any optical channel at an ingress port in an OXC (or
networks) is switched to an egress port. This optical channel can be
carrying any client payload traffic type and rate and is totally
transparent as far as the OXC is concerned.
The second difference between an "OXC switched path" and a LSP is the
frequency of path set-up/tear- down requests and the duration of the
connection. In an OXC network, because of the high bandwidth nature
of each connection, one would expect them to persist for a much
longer duration and involve relatively infrequent connection set-
up/tear-down requests when compared to per packet routing operations.
This has an important bearing on path signaling requirements.
Strongly connected to this is the difference in resource cost of
establishing a LSP as opposed to establishing a connection in the
optical layer. When an LSP is established, the only resource consumed
is the storage necessary to specify the label mappings. When a
circuit is established, the entire capacity of that circuit is
removed from the available capacity in the network. This leads to the
observation that LSP's can be quickly established, perhaps as a
Krishna MPLS control plane for Switched Optical Networks [Page 2]
Internet Draft February 2000
response to a single packet, and can be held at little cost to see
whether future traffic makes it worthwhile to keep the LSP up. In
contrast, a high capacity circuit is unlikely to be established
without a priori knowledge of substantial traffic being available for
this circuit. For this reason, the means of deciding to establish a
circuit is likely to be very different from the means of deciding to
establish an LSP.
[1] and [2] clearly spell out the need for automating the setup of an
end-to-end optical channel connection.
The needs expressed in [1] and [2] have been elaborated with some
architectural considerations and published as [3]. This document has
been approved by the USA to communicate current work in the US to
ITU-T SG13, which currently controls Optical Transport Network
architecture and requirements.
[4] discusses in detail the role of MPLS [5, 6, 7] as a control plane
for the management of OXCs.
2. Optical IP Networking Scenario
Fig. 1 shows an optical IP network with optical line systems
(consisting of multiplexers and demultiplexers) and OXCs, with
subtending IP switch routers. The figure shows LSRs (Label Switched
Routers) connected to the OXCs by both single channel and multi-
channel networks. Note that the single connection between the LSR
(Optical Transport Network client) and OXC (OTN) actually represents
two connections, one which will eventually carry the high rate
traffic, and a much lower rate one that provides IP access to optical
network services (e.g., signaling to trigger optical channel
connection set-up).
Note: The LSRs have two functions - the first is to aggregate IP
traffic on a coarse scale into a few number of LSPs - the second is
to setup optical channel connections for the data paths.
Krishna MPLS control plane for Switched Optical Networks [Page 3]
Internet Draft February 2000
+-----+ +-----+
| | | |
| LSR | | LSR |
+-----+ +-----+
\\\ /
\\\ +----+
\\\ |OMD |
\\\ +----+
\\\ ///
+-------+
| |
+----+ +----+ | | +----+ +----+
| | | |-----| |------| | | |
|OMD |-----|OMD |-----| OXC |------|OMD |------|OMD |
| | | |-----| |------| | | |
+----+ +----+ | | +----+ +----+
||| | | |||
||| +-------+ |||
||| |||
||| |||
||| |||
+-------+ +-------+
| | +----+ +----+ | |
| |-----| | | |------| |
| OXC |-----|OMD |-----------------|OMD |------| OXC |
| |-----| | | |------| |
| | +----+ +----+ | |
+-------+ +-------+
/// \\\ /// \\\
/// +----+ /// +----+
/// | OMD| /// | OMD|
/// +----+ /// +----+
/// \ /// \
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| LSR | | LSR | | LSR | | LSR |
+-----+ +-----+ +-----+ +-----+
----- Multi-channel (WDM) connection
-----
----- Single-channel connections (Multiple fiber)
-----
OMD - Optical Multiplexer/Demultiplexer
Fig. 1 - Optical IP Network with OXCs and Label Switch Routers
Krishna MPLS control plane for Switched Optical Networks [Page 4]
Internet Draft February 2000
As the bandwidth for carriage of IP services increases beyond 10
Gb/s, one would expect to see more bandwidth routed and processed at
an optical channel level of granularity (via OXCs) and less processed
at the IP level (via routers). Thus, we should expect to see an
evolution from purely IP router based networking towards a mixture of
router and circuit switched networking.
3. IP and Optical Network Signaling Distinctions
+-------+ +-------+
| | | |
+-----+ SCI | | SC | | SCI +-----+
| |____________| |_____________| |_______| |
| | | OXC | | OXC | | |
| LSR |------------| |-------------| |-------| LSR |
| |------------| |-------------| |-------| |
| |------------| |-------------| |-------| |
| | DC | | | | | |
+-----+ | | | | +-----+
+-------+ +-------+
SC - Signaling channel
SCI - Signaling channel Interface
DC - Data channels (customer traffic))
Fig. 2 - Signaling channels and interfaces
In a router based IP network there is no physical separation of the
data and control (signaling, routing etc.) path. Both flow on the
same link (or channel in a WDM network) and the topology of the
signaling network is identical to that of the traffic network.
Referring to Fig. 2 we see that in an OTN network a separate
signaling channel may be required. This signaling channel carries
information necessary to setup the data paths, but the actual paths
taken by a signaling and data connection between the same
source/destination pair could be different. In any case there is no
physical constraint forcing or ensuring this identity. This is an
important issue especially when considering OTN network restoration
requirements. Hence in a meshed optical network, which may not be
fully interconnected, the signaling protocol must be capable of
setting up a data path that is different from the signaling path
topology.
Krishna MPLS control plane for Switched Optical Networks [Page 5]
Internet Draft February 2000
Thus, we need to talk in terms of two different network topologies,
one for the signaling infrastructure and the other for data carried
on optical channels within the OTN. Within the OTN, the signaling
channels are terminated at each OXC (just as in a router based
network) as they carry information regarding network connection set-
up (and tear-down). The data channels are, however, end-to-end
optical channels with no termination points in the middle of the OTN.
4. Connection setup details in a switched optical network
There are three fundamental steps involved in setting up a connection
in a switched optical network.
A. OXC signaling network topology discovery and signaling path setup
B. OXC traffic adjacency and port interconnection discovery
C. Data path computation
Note: The connection setup above is generally called the primary
path (also called the working path), meaning the path along which
data will flow under normal conditions for a source/destination
address/port. For network survivability reasons, alternate
restoration path(s) for the primary paths need to be computed and
allocated. These may be pre-computed or calculated and allocated
dynamically. When the primary path fails for whatever reason, a
fault is triggered and automatic switching onto the restoration path
takes place. This restoration path may be 1+1, meaning it is
dedicated for a particular primary path only, or this may involve
restoration resources shared among several primary paths. In the
later case contentions may arise and a priority based reservation
scheme may be needed.
5. OXC network topology discovery and Signaling path setup
To discover the network topology, the OXC control plane (but not
necessarily all OXC's) must be associated with a routing function.
This routing function may be built-in to an OXC or can be a separate
equipment, with necessary i/o connections to one or more OXC
controllers. The DCN (Data Communications Network) can be a part of
the OTN embedded communications channel (Optical Supervisory Channel)
or a dedicated wavelength could be allocated for this purpose. In
this regard, the OTN would be no different than any other circuit
switched network using traffic capacity to provide a signaling
network. The DCN could also be an out-of-band LAN. A link state
routing protocol like OSPF can be used for calculating the best path
between destinations.
Krishna MPLS control plane for Switched Optical Networks [Page 6]
Internet Draft February 2000
When the number of nodes (OXC) becomes large, hierarchical
partitioning of the network will be necessary to ensure that routing
can be scaled up. This DCN routing protocol is only for setting up
the signaling paths between the OXCs, and this protocol instance
should not be confused with different instances of the same protocol
handling the OTN traffic network topology, or for that matter, the
topology of the IP client network.
6. OXC adjacency and port interconnection discovery
It is essential for the adjacent OXCs to have knowledge of how the
ports (or wavelengths) are interconnected between them. While not
desirable in the long run this could be manually provisioned or a
separate protocol (or instance of it) to disseminate the port mapping
information could be run. (This protocol will be a part of a future
submission.) In either case a port map table is maintained in each
OXC. This table is consulted and updated while setting up and tearing
down data connections. Fig. 3.
+-----+ +-----+
| |-----| |
| |1 1| |
| | | |
| OXC |\ | OXC |
| A |2\ | B |
| | \ | |
| | \ | |
| | 6\| |
| |\6 | |
+-----+ \ +-----+
\
\ +-----+
1\| |
| |
| |
| OXC |
| C |
| |
| |
| |
+-----+
Krishna MPLS control plane for Switched Optical Networks [Page 7]
Internet Draft February 2000
Adjacent Local Port Remote Port Link Availability
OXC Status
B 1 1 y
B 2 6 n
C 6 1 y
Fig. 3 - OXC Adjacency and Port Interconnection Table (For OXC A)
Note: Link Availability Status indicates whether
the link is available for a new connection request or not.
Fig. 3 shows the port interconnection table for an OXC marked A.
Hence a selection of a particular data path depends on the
availability of wavelengths. Additionally an administrative cost
could be assigned to each port and this could be an additional
selection criteria. Where no wavelengths are available, the link
connection between the two OXCs is not possible.
Note: In order to avoid the need to signal the existence of every
optical channel, which in the circuit switched world is called a link
connection, we may aggregate link connections into links, where a
link is the collection of link connections that are equivalent for
the purpose of routing. This equivalence for the purpose of routing
may include attributes for link connection rate or geographically
diverse routing, so two OXCs may have more than one link between
them.
This leads to the notion that link capacity should be exchanged so
that traffic can be routed in such a way as to balance traffic on the
various links in the network.
7. Optical Channel connection setup - Two types of networks
In this draft we study the mechanisms of setting up optical channel
connections for two networking situations.
The first is the case of a CPE (Customer Premises Equipment)
connected to OXCs through dark fibers - a simple scenario wherein
only the networking of OXCs need to be taken in to consideration
without any regard to client payload, in setting up an optical
channel connection. The second is the complex case of CPEs (routers
in this case) networked to OXCs through LSRs. This requires a careful
Krishna MPLS control plane for Switched Optical Networks [Page 8]
Internet Draft February 2000
network topology layout and policy based routing is required.
8. CPE networking to OXCs by dark fibers
In this scenario a CPE is connected to the OXC network by a dark
fiber or even by a lambda (wavelength). The client may require of
the service provider to route the traffic transparently over the OXC
network - without ever looking in to the payload - this may be due
to highly sensitive data, client VPN, non-standard protocols etc.
Under such cases, the ingress and egress OXC nodes need to be pre-
computed and arranged with the client.
Thus this is the case of setting up optical channel connections
between the ingress and egress OXCs. There are no LSRs.
A routing protocol like OSPF discovers the OXC network topology. In
the simple case the optical channels connection follow the signaling
(route) path. Hence we need explicit routing to balance traffic and
meet other traffic engineering considerations. CR-LDP [8] or RSVP
with EXPLICIT ROUTE and LABEL REQUEST Objects [9] could be used to
setup the path connections.
8.1 The role of MPLS
On receiving a Label Request Message the egress OXC finds the right
label to be carried in the Label Mapping Message (or RESV message in
RSVP) to its upstream OXC. This label has much significance to the
optical network. as it is derived from the OXC Adjacency and Port
Interconnection Table in Fig. 3. Thus a label selected is a
representation of the OXC port selected for setting up the optical
channel connection. Once the MPLS LSP is determined, cross-connects
are made completing the optical channel connection setup.
If the connection request fails due to lack of resources at any
particular node, then a special label that represents the node id and
reason thereof could be sent upstream to the ingress OXC. The ingress
OXC may try a new explicit path that will not include the problem
node.
9. Client networking to OXCs by LSR
However a more typical scenario is the case where traffic from one or
more client network are input to the service provider's OXC network.
Krishna MPLS control plane for Switched Optical Networks [Page 9]
Internet Draft February 2000
The traffic then needs to be routed over the OXC network. This
involves introduction of LSRs and several additional steps (and
policies) on the part of the service provider. Primary to this, the
need to separate the networking topologies of the optical networking
elements like OXCs and the services (IP) they carry must be
understood.
9.1 Need for separation of optical transport and service layer
topologies and Control
There are many compelling reasons to have separate network
topologies, whether it is physical or logical for the OTN and the
service layer.
Most important, perhaps, is that these two layers are likely to be
under different administrative controls (or ownership) and policies.
Under such circumstances the service provider who owns the OTN will
wish to maintain full control of his network. Such an operator would
not wish to give a client insight into the structure of the OTN layer
as this is his business value.
Apart from this strong need to protect a business value, there is no
client service which would depend on having a view of the internal
structure of the OTN. Three examples have been suggested. The first
involves a pair of connections diversely routed for restoration
purposes. The second involves a connection required at a future time,
while the third involves being able to know which LSR's can be
reached via the OTN. (This is somewhat similar to the VPN neighbor
discovery problem)
The first two examples are met by correct OTN interface design, in
which appropriate parameters convey the constraint desired. The third
sounds more attractive than it really is. The definition of a network
is the set of enties that are interconnectable, so the LSRs that are
reachable via the OTN is the set of all LSRs connected to the OTN. In
a large network, this list could be extremely long and a subset of
all LSRs is what's probably meant. This need seems to be better met
by directories (or brokers) than by exposing the inner details of the
OTN.
Krishna MPLS control plane for Switched Optical Networks [Page 10]
Internet Draft February 2000
9.2 Networking of CPE routers through OXC networks
+----+
|LSR |
-----------------| A |--------------
| +----+ |
| || |
| || |
| || |
| +----+ |
| | OXC| |
| | | |
| +----+ |
| ~ ~ |
| ~ ~ |
| ~ ~ |
+----+ +----+ +----+ +----+
|LSR |======| OXC| | OXC|======|LSR |
| B | | |~~~~~~~| | | C |
+----+ +----+ +----+ +----+
| |
| |
| |
-------------------------------------
~~~~~~~~ OXC Network
________ LSR Network
======== OXC-LSR Interconnection
Fig. 4. Distinct OXC and LSR Networks (Physical and/or Logical)
This is the case of routing customer traffic through the OXC network.
The CPE equipments are in this case connected to service providers'
LSRs and not OXCs. Referring to Fig. 4. this could then be a LSR A
trying to send traffic to LSR C. (For LSR A to know that it needs to
send traffic to LSR D in the first hand, may require sharing of
routing information. This is dealt with in subsequent paragraphs).
The first step in configuring this network is to aggregate the client
traffic in to several LSPs on a coarse granularity. The reason is
Krishna MPLS control plane for Switched Optical Networks [Page 11]
Internet Draft February 2000
that the IP traffic is carried over optical channels and the number
of wavelengths in a OXC (or fiber) are limited, unlike the labels in
a MPLS environment.
Around the OXC network is the service provider's edge network
consisting of several LSRs and they aggregate the client traffic into
several LSPs. Generally the number of LSPs in a LSR is equal to the
total number of ports (or channels) in its connection to the adjacent
OXCs. These LSRs are interconnected by a network which is physically
and/or logically separated from the OXC network. A routing protocol
like OSPF discovers the LSR networking topology. Again this routing
protocol (or the instance of it) is different from the one that
discovers the OXC network topology. Or more probably the LSRs and
OXCs may have two instances of the network topology database of the
same routing protocol or even two views of a single topology
database. Thus the LSRs facilitate a knowledge of full network
connectivity from router A to router C, outside of the OXC network.
The OXCs have their own view of the network topology, and also have
information as to which LSR is connected to which OXC.
In this scenario an optical channel connection is setup between the
ingress and egress LSRs over the OXC network. The ingress LSR only
sends its request to its connected OXC. It is the OXC network that
determines the path to the egress LSR.
The OXC Adjacency and Port Interconnection Table then needs to be
extended to include LSR port connections as well. Fig. 5.
Krishna MPLS control plane for Switched Optical Networks [Page 12]
Internet Draft February 2000
+-----+ +-----+
| |-----| |
| |1 1| |
| | | |
| OXC |\ | LSR |
| A |2\ | B |
| | \ | |
| | \ | |
| | 6\| |
| |\6 | |
+-----+ \ +-----+
\
\ +-----+
1\| |
| |
| |
| OXC |
| C |
| |
| |
| |
+-----+
Adjacent Local Port Remote Port Link Availability
OXC/LSR Status
B 1 1 y
B 2 6 n
C 6 1 y
Fig. 5 - LSR-OXC Adjacency and Port Interconnection Table (For OXC A)
10. Signaling optical channel connection request (UNI)
The request to setup an optical channel connection is initiated
either by the CPE (Section 8) or by the service provider's LSR
(Section 9). In the simplest case this UNI request will be to setup
an optical channel connection setup between two OXCs or two LSRs. The
mechanisms of setting up the connections in such cases were discussed
in Sec. 8 and 9.
Krishna MPLS control plane for Switched Optical Networks [Page 13]
Internet Draft February 2000
However it is envisaged that the UNI request may specify many other
connection requirements - uni or bi-directional link connection,
network protection type required (if any) like 1+1, shared etc. Also
where the optical nodes have capabilities for providing service
specific connections like OC-192, GbE or multiplexing traffic (SONET
or even lambdas) the UNI could specify these as well.
The optical network nodes then need to authenticate the request,
setup priorities in allocating the resources and finally signal an
optical channel connection request based on these. This calls for
extensions to the routing and signaling protocols. The proposed
extensions to OSPF/IS-IS and CR-LDP/RSVP are listed in [10] and [11].
If the CPE or LSR is not capable of signaling over the UNI, the OXC
path could also be set up in a proxy signaled manner from a network
management device. Then, the client is informed via some other
method of the availability of the path.
11. Network survivability - Fault detection and network restoration
These topics will be discussed in detail in a future contribution.
12. Extensions/Modifications of IP protocols for OXC based WDM network
From the above discussions it is clear that IP based protocols can be
used for controlling Switched Optical Networks. However we feel some
extensions/modifications to these protocols may be necessary. In this
draft we have tried to explain the OXC based optical networking
scenario which necessitates some additional work on the IP protocols.
The objective of this draft is thus to initiate discussions on these.
13. Summary
In this draft we study the role of MPLS and other IP based protocols
in the control plane of a OXC based WDM optical network. The
architecture of the OXC network to support setting up optical
channels for data paths was briefly discussed.
The three important steps in setting up an optical channel viz. a)
signaling path setup, b) OXC interconnection details and c) data path
(optical channel itself) were studied. Two typical cases of client
connections to the OXC networks were discussed in detail. The first
is the CPE connecting to OXC through dark fibers. The second is the
case of CPEs connecting to OXCs through LSRs. In both cases we try to
show how protocols like OSPF, MPLS, CR-LDP, RSVP etc. could be used
Krishna MPLS control plane for Switched Optical Networks [Page 14]
Internet Draft February 2000
to setup the connections. We then clearly spell out the need for
separation of the optical layer topology and the client services (IP)
that it carries.
Lastly we stress the need for IETF to initiate work on extending some
of the standard protocols to meet the additional requirements of OXC
based Switched Optical Networks.
14. Security Considerations
This draft proposes the use of MPLS and other IP based protocols for
the control of Switched Optical Networks. Security considerations
associated with these protocols are applicable to this proposal also.
15. Acknowledgements
The authors would like to thank Bharat Doshi, John Ellson, Patrice
Lamy, Eve Varma and Ren Wu for their helpful comments on this work.
16. References:
[1] G. Newsome and P. Bonenfant, "The Automatic Switched Optical
Network," Contribution to T1 STANDARDS PROJECT - T1X1.5, 1999.
[2] P. Bonenfant and and X. Liu, "A Proposal for Automatically
Switched Optical Channel Networks (ASON)," Contribution to T1
STANDARDS PROJECT - T1X1.5, 1999.
[3] G. Newsome and M. Mayer, "Work on the Automatic Switched Opti-
cal Network," Contribution to T1 STANDARDS PROJECT - T1X1.5,
2000.
[4] D. Awduche, Y. Rekhter, J. Drake, R. Colton, "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control
With Optical Crossconnects," Internet Draft, Work in Progress,
1999.
[5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,A.
Viswanathan, "A Framework for Multiprotocol Label
Switching,"Internet Draft, Work in Progress, 1999.
[6] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture," Internet Draft, Work in Progress,
1999.
Krishna MPLS control plane for Switched Optical Networks [Page 15]
Internet Draft February 2000
[7] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J.
McManus,"Requirements for Traffic Engineering Over MPLS," RFC-
2702, September 1999.
[8] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V.
Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet
Draft, Work in Progress, 1999.
[9] B. Jamoussi et al, "Constraint-Based LSP Setup using
LDP,"Internet Draft, Work in Progress, 1999.
[10] G. Wang et al, "Extensions to OSPF/IS-IS for Optical Routing,"
Internet Draft, Work in Progress, 2000.
[11] G. Wang et al, "Extensions to CR-LDP and RSVP for Optical Path
Set-up," Internet Draft, Work in Progress, 2000.
17. Authors' Addresses
Murali Krishnaswamy
Lucent Technologies
3C-512
101 Crawfords Corner Rd.
Holmdel NJ 07733
Voice: +1 732 949 3611
Email: murali@lucent.com
George Newsome
Lucent Technologies
3C-505
101 Crawfords Corner Rd.
Holmdel NJ 07733
Voice: +1 732 949 0812
Email: gnewsome@lucent.com
Joe Gajewski
Lucent Technologies
3F-517A
101 Crawfords Corner Rd.
Holmdel NJ 07733
Voice: +1 732 332 5981
Email: joegajewski@lucent.com
Antonio Rodriguez-Moral
Lucent Technologies
3C-502A
101 Crawfords Corner Rd.
Krishna MPLS control plane for Switched Optical Networks [Page 16]
Internet Draft February 2000
Holmdel NJ 07733
Voice: +1 732 949 2164
Email: arodmor@lucent.com
Stephen Shew
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Voice: +1 613 763 2462
Email: sdshew@nortelnetworks.com
Michael Mayer
Nortel Networks
P.O. Box 402
Ogdensburg NY 13669
Voice: +1 613 765 4153
Email: mgm@nortelnetworks.com
Krishna MPLS control plane for Switched Optical Networks [Page 17]