Internet Draft Debashis Basak
Expires: July, 2000 Marconi
<draft-basak-mpls-oxc-issues-00.txt>
Daniel O. Awduche
UUNet (MCI WorldCom)
John Drake
Marconi
Yakov Rekhter
Cisco
Multi-protocol Lambda Switching: Issues in Combining MPLS
Traffic Engineering Control With Optical Crossconnects
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes domain specific enhancements needed to adapt
MPLS traffic engineering control plane constructs to control optical
crossconnects in emerging automatically switched optical transport
networks. These enhancements are within the framework of
Multiprotocol LAMBDA switching proposed in [1]. Specifically, this
memo investigates the behavior of the MPLS based control plane
technique for OXCs, and identifies enhancements required to both OXCs
and to existing MPLS control constructs (routing and signaling
protocols) to support the application to OXCs.
Basak Expires July, 2000 [Page 1]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
1. Introduction
Recently, a new paradigm for the design of control planes for OXCs
intended for data-centric automatically switched optical transport
networks was proposed in [1]. This new paradigm is termed
Multiprotocol Lambda Switching and exploits recent advances in MPLS
traffic engineering control plane technology to foster the expedited
development and deployment of a new class of versatile OXCs that
specifically address the optical transport needs of the Internet.
This memo describes a number of domain specific enhancements required
to map the MPLS control plane constructs to OXCs. The memo describes
enhancements to OXCs and WDM devices to the support MPLS based
control plane approach. It also discusses extensions to the existing
MPLS control plane constructs to better accommodate the needs of the
optical transport network elements.
2. Definitions
The MPLS control plane has been used (adapted) earlier in conjunction
with data planes with specific limitations e.g. ATM-LSRs, FR-LSRs.
The adaptation of MPLS control plane to OXCs, resulting in OXC-LSRs,
needs to consider specific limitations of the OXC data plane, as
identified in [1]. This section presents some definitions that take
into account such peculiarities of the OXC data plane.
A termination-capable (TC) interface on a label switching router
(LSR) is one which is capable of terminating an LSP and
demultiplexing data carried by the LSP to make further
routing/switching decisions. A point-to-point interface terminating
on a router that implements MPLS is an example of a TC interface.
A termination-incapable (TI) interface is one which is incapable of
terminating LSPs and demultiplexing data carried by the LSP to make
further routing/switching decisions. Thus, an LSP incoming on a TI
interface of a network device cannot be carrying data destined to
different egress points of the device. A fiber connected to an OXC is
an example of a TI interface.
For a given unidirectional link the interfaces associated with the
link's endpoints may be of different types with respect to their
ability to terminate an LSP. For example, for a link from a (frame-
based) LSR (e.g., router) to an OXC, the interface with the OXC is TI
while the one with the LSR is TC. The property of TI or TC is
associated with the head of a link, as well, because in a given MPLS
Basak Expires July, 2000 [Page 2]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
box it may be possible for an LSP to come in through one interface,
be switched across the box, and then terminated at the far end (at
the head of a link).
If all the interfaces of an LSR are TI interfaces, we'll refer to
such an LSR as a TI-LSR. An OXC-LSR today is an example of a TI-LSR
(an ATM-LSR is another example of a TI-LSR).
If an LSR has at least one TC interface, we'll refer to such an LSR
as TC-LSR. A router that implements MPLS is an example of a TC-LSR.
A single box may have TC and TI interfaces. For example, one could
imagine an optical box that on some interfaces forwards data based on
the wavelength/optical trail the data was received and on other
interfaces based on the label information carried by packets. One can
also envision a hybrid physical interface in which data on certain
wavelengths/optical trails is forwarded based on the
wavelength/optical trail the data was received and on other
wavelengths/optical trails based on the label information carried by
packets. Such physical interfaces may be considered as two separate
logical interfaces, one TC and the other TI.
A TI-LSR domain is a set of TI-LSRs which are mutually interconnected
by TI interfaces. An OTN made of a mesh of today's OXC-LSRs is an
example of a TI-LSR domain.
The Edge set of an TI-LSR domain is the set of TC-LSRs which are
interconnected to members of the domain by links with a TC interface
on a TC-LSR and a TI interface on a TI-LSR. A TC-LSR which is a
member of an Edge set of a TI-LSR domain is called an Edge LSR.
Examples of Edge LSRs are access devices to an OTN. Figure 1 below
depicts an example network with a single TI-LSR domain consisting of
OXCs (O1 through O8) surrounded by an Edge set of TC-LSRs consisting
of access routers (M0 through M4).
By definition LSPs cannot start/terminate on the LSRs within a TI-LSR
domain. LSPs can start/terminate at TC-LSR belonging to the Edge set
or beyond.
Basak Expires July, 2000 [Page 3]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
_________________
M0---/--O2-----O9 \
/ / \ \
M1--|--O1 --O3--O4---O6-|---M3
\ \ / /
M2--\--O5 -- O7 --O8--/---M4
\_______________/
TI-LSR domain
Mk: A TC-LSR (access routers), Ox: A TI-LSR (OXC)
Figure 1: A sample network with a TI-LSR domain
surrounded by an Edge set of TC-LSRs.
3. Required Enhancements to OXCs and WDM devices to support MPLS
The following contains the list of required enhancements to OXCs and
other WDM devices to support MPL(ambda)S:
- there should be a way to exchange control information
between OXCs, either using the same links (fiber) that
is used to carry data, or via a separate network.
- an OXC must be able to provide the MPLS control plane with the
information about the state of individual fibers attached
to that OXC, as well as with the state of individual ligthpaths
within each such fiber.
- an edge LSR may not have build-in WDM capabilities, but rather
may use external WDM device that acts as SONET-to-WDM
multiplexor/demultiplexor. That still should allow that LSR
to exchange control information with the OXCs.
4. Required Enhancements to the current MPLS control plane.
The section describes enhancements to the MPLS TE control component
(ISIS/OSPF and RSVP) in order to support MPL(ambda)S. The required
enhancements are divided into two sets (A) and (B).
A) The first set concerns enhancements to adapt to the
peculiarities of OXCs:
Basak Expires July, 2000 [Page 4]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
- the RSVP Label Object, in combination with already available
IGP and RSVP information, should be able to provide sufficient
information to program cross-connect matrix on OXCs.
- when a pair of OXCs are connected by multiple links (fibers),
an IGP needs to carry information about physical diversity
of the fiber.
- since bandwidth allocation on an OXC is discrete, an IGP should
be able to carry the information about bandwidth granularity of
a particular link. This information should allow support for
multiple granularities within a single link, as well as for
different granularities per priority.
Additional requirements imposed by OXCs that can't perform
wavelength translation are outside the scope of the discussion
in this document.
B) As indicated in [1], essential to the use of MPLS with OXCs
is the ability to aggregate LSPs by using the notion of
"nested" LSP.
MPLS allows several ways to implement nested LSPs. One way to
accomplish this is to have a single MPLS control plane, but
allow this control plane to treat some of the LSPs created and
maintained by the control plane as links for the purpose of
establishing new LSPs (by the same control plane). That is the
MPLS control plane could use an LSP as a link to form another
LSP, and that other LSP, in turn, could be used as a link to
form some other LSP, etc...
Another way to accomplish this is to have multiple instances of
the MPLS control plane, and allow LSPs created by one instance
of the control plane to be used as links by some other instance
of the control plane.
Regardless of whether one uses a single or multiple instances of
the MPLS control plane, the LSPs that are used as links could be
established by either (a) means outside of the MPLS control
plane (e.g., by configuration), or (b) by means of the MPLS
control plane itself.
The following contains the list of required enhancements to the
MPLS TE control component (ISIS/OSPF and RSVP) in order to
support the ability to aggregate LSPs in MPL(ambda)S:
Basak Expires July, 2000 [Page 5]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
- an IGP should carry information about whether a particular
link is termination capable (TC) or not (TI). OSPF should be
able to take this information into account when computing
paths for optical trails.
- the LSP setup procedures should include support for an LSR at
the edge of TI-LSR domain to aggregate multiple LSPs coming
from outside of the TI-LSR domain into an LSP that is
an optical trail.
- an LSR should be able to advertise into an IGP a link that
is formed out of an LSP originated by the LSR, and SPF/OSPF
procedures should be able to use such a link for path
computation.
- one instance of MPLS should be able to present LSPs
created/maintained by that instance as links to another
instance of MPLS. The two instances may reside either
on the same, or on different devices.
Note that the ability to aggregate LSPs by nesting may be useful
outside of the OXC environment as well. The enhancements specified
above in support of aggregate LSPs have to implemented in such a
way as to allow non-OXC environments.
The specifications of the enhancements to the MPLS TE control
component in support of MPL(ambda)S will be covered in a
supplimentary document to follow.
5. Security Considerations
Security considerations are for future study.
6. References
[1] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects", Internet Draft, Work in Progress.
[2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus,
"Requirements for Traffic Engineering Over MPLS," RFC-2702, September
1999.
Basak Expires July, 2000 [Page 6]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
[3] D. Awduche, "MPLS and Traffic Engineering in IP Networks,"
IEEE Communications Magazine, December 1999.
[4] 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
[5] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP,"
Internet Draft, Work in Progress, 1999
[6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A.
Viswanathan, "A Framework for Multiprotocol Label Switching,"
Internet Draft, Work in Progress, 1999
[7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture," Internet Draft, Work in Progress, 1999
[8] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic
Engineering with MPLS," Internet Draft, Work in Progress, 1999
[9] H. Smith and T. Li, "IS-IS extensions for Traffic Engineering,"
Internet Draft, Work in Progress, 1999
[10] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF,"
Internet Draft, Work in Progress, 1999
7. Author's Addresses
Debashis Basak
Marconi
1000 FORE Drive
Warrendale, PA 15086-7502
Phone: 724-742-7026
Email: dbasak@fore.com
Daniel O. Awduche
UUNET (MCI WorldCom)
Loudoun County Parkway
Ashburn VA
Phone: 703-886-5277
Email: awduche@uu.net
John Drake
Marconi
1000 FORE Drive
Warrendale, PA 15086-7502
Basak Expires July, 2000 [Page 7]
Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000
Phone: 724-742-6798
Email: drake@fore.com
Yakov Rekhter
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: yakov@cisco.com
Basak Expires July, 2000 [Page 8]