[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Internet Draft Debashis Basak
Expires: August, 2000 Marconi
<draft-basak-mpls-oxc-issues-01.txt>
Daniel O. Awduche
UUNet (MCI WorldCom)
John Drake
Chromisys, Inc
Yakov Rekhter
Cisco
Multi-protocol Lambda Switching: Issues in Combining MPLS
Traffic Engineering Control With Optical Cross-connects
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 the domain specific enhancements required to
adapt MPLS traffic engineering control plane constructs to control
optical cross-connects 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 required enhancements to both OXCs
and to existing MPLS traffic engineering control plane objects
(routing and signaling protocols) to support the application to OXCs.
Basak Expires August, 2000 [Page 1]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 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.
The MPLS traffic engineering control plane has been shown to be an
extensible general purpose control plane technology for a variety of
data-centric network elements. For example, the MPLS control plane
has been used previously in conjunction with data planes that have
specific limitations e.g. ATM-LSRs and frame relay LSRs (FR-LSRs).
The adaptation of MPLS traffic engineering control plane concepts to
OXCs, which results in OXC-LSRs, needs to consider and reflect the
domain specific peculiarities of the OXC data plane. This
consideration was noted in [1], but details of the needed extensions
were not provided.
This memo describes a number of required domain specific enhancements
that are necessary to map the MPLS traffic engineering control plane
constructs to OXCs. Specifically, this memo describes required
enhancements to OXCs and associated WDM devices to support
incorporation of the MPLS traffic engineering control plane approach.
Additionally, this memo discusses required extensions to the existing
MPLS traffic engineering control plane constructs to better
accommodate the needs of optical transport network elements.
2. Terminology and Definitions
This section introduces terminology which is pertinent to the
Multiprotocol Lambda Switching concept. We discuss the notions of
termination-capable interfaces and termination-incapable interfaces,
and a related concept of termination-incapable domain.
A termination-capable (TC) interface on an LSR is an interface which
is capable of terminating a label switched path (LSP) and
subsequently demultiplexing the data carried by the LSP to make
further routing/switching decisions. This definition does not pertain
to management and control traffic destined for the LSR. A point-to-
point interface terminating on an IP router that implements MPLS is
an example of a TC interface.
A termination-incapable (TI) interface is one which is incapable of
Basak Expires August, 2000 [Page 2]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
terminating LSPs and demultiplexing the data carried by the LSPs to
make further routing/switching decisions. A fiber connected to a pure
OXC is an example of a TI interface. The definition of TI does not
pertain to interfaces which terminate management and control traffic
destined for the LSR.
For a given bidirectional link, the interfaces associated with the
endpoints of the link may be of different types with respect to their
capability to terminate LSPs. For example, consider a link between a
pure OXC and a (frame-based) LSR (e.g., an IP router); the interface
with the OXC is TI while the interface with the frame-based LSR is
TC.
A single network element may simultaneously have both TC and TI
interfaces. For example, it is easy to envision an optical device
that switches traffic on some interfaces based on the wavelength or
the optical channel trail through which the traffic was received, and
switches traffic on other interfaces based on the label information
carried by packets. It is also easy to envision a hybrid physical
interface in which traffic on certain wavelengths or optical channel
trails are forwarded based on the wavelength or optical channel trail
through which the traffic was received, and traffic on other
wavelengths or optical channel trails are forwarded based on the
label information carried by the packets. Such physical interfaces
may be considered as two separate logical interfaces, one TC and the
other TI.
If all the interfaces on an LSR are TI interfaces, then such an LSR
will be referred to as a TI-LSR. A contemporary OXC-LSR which
provides transit services for data traffic is an example of a TI-LSR
(an ATM-LSR within the context of IP-over-ATM is another example of a
TI-LSR).
If an LSR has at least one TC interface, then such an LSR is referred
to as a TC-LSR. A router that implements MPLS is an example of a TC-
LSR.
We now discuss the concept of a TI-LSR domain.
A TI-LSR domain is a set of TI-LSRs which are mutually interconnected
by TI interfaces. A transit optical transport network (OTN) composed
of contemporary OXC-LSRs is an example of a TI-LSR domain.
The Edge set of a TI-LSR domain is the set of TC-LSRs that 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 include client network elements and access
Basak Expires August, 2000 [Page 3]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
devices that interconnect to the OTN. Figure 1 below depicts an
illustrative 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 LSRs within a TI-LSR
domain. LSPs can, however, start and terminate on TC-LSRs belonging
to the Edge set of a T1-LSR domain as well as on devices situated
beyond the edge set.
_________________
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: An illustrative 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 discussion contains a list of some basic required
enhancements to OXCs and other WDM devices to support MPL(ambda)S:
- There should be a mechanism to exchange control information
between OXCs, and between OXCs and other LSRs. This can be
accomplished in-band or quasi-in-band using the same links
(fibers) that are used to carry data-plane traffic, or
out-of-band via a separate network. A combination of
in-band and out-of-band mechanisms may also be appropriate
under certain circumstances.
- An OXC must be able to provide the MPLS traffic engineering
control plane with pertinent information regarding the state of
individual fibers attached to that OXC, as well the state of
individual ligthpaths or optical channel trails within each
fiber.
- An edge LSR might not have intrinsic WDM capabilities. Instead,
Basak Expires August, 2000 [Page 4]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
it might interface to an external WDM device, using a
suitable technology such as SONET, GigEthernet, etc.
Even when an edge LSR does not have WDM capabilities, it
should still have the capability to exchange control information
with the OXCs in the domain.
4. Required Enhancements to the current MPLS control plane.
This section describes some basic required enhancements to the MPLS
traffic engineering control plane components (including ISIS/OSPF and
RSVP) in order to support MPL(ambda)S. Part (A) of this section
covers general enhancements while part (B) covers enhancements that
are specific to the nesting of LSPs.
A) General enhancements
- An MPLS domain may consist of links with different properties
depending upon the type of network elements at the endpoints
of the links (e.g., some of links may interconnect OXCs, some
links may interconnect frame-based LSRs and OXCs, while
other links may interconnect frame-based LSRs). Within the
context of Multiprotocol Lambda Switching, the properties of a
link consisting of a fiber with WDM that interconnects two OXCs
are different from the properties of a SONET link that
interconnects two LSRs. For example, a conventional LSP cannot
be terminated on a link connected to a pure OXC. However, a
conventional LSP can certainly be terminated on a link
connected to a frame-based LSR. These differences should be
taken into account when performing path computations to
determine an explicit route for an LSP. Additionally, since
the performance characteristics of an LSP will depend on the
characteristics of the links traversed by the LSP, it
may be useful to have the capability to restrict the path
of some LSPs to links with certain characteristics. The
concept of resource class attributes defined in [2] is one
approach to accomplish this containment, but other
mechanisms may also be feasible.
Thus, for example, it may be desirable for an IGP to carry
information regarding whether a particular link is TC or
TI. Path computation algorithms may then take this
information into account when computing paths LSPS.
- In certain contexts there may be multiple control
channels and bearer channels between a pair of adjacent
OXCs. Procedures are needed, therefore, to associate control
Basak Expires August, 2000 [Page 5]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
channels to bearer channels in such circumstances. Furthermore,
if a control channel is associated with multiple bearer
channels, then procedures are required to demultiplex the
control traffic for different bearer channels. Procedures are
also needed to activate and deactivate bearer channels, to
verify proper operation of bearer channels, and to assign
bearer channels to an LSP during the process of LSP
establishment. The procedures needed to accomplish the
objectives include the following aspects: a method to identify
the bearer channels associated with any given physical link,
methods to identify spare bearer channels for protection
purposes (e.g., 1+1, 1:1, and 1:N protection schemes), and
methods to identify an impaired bearer channel -- especially
in the situation where the physical links carrying the bearer
channel are not impaired.
- To perform the signaling function in Multiprotocol Lambda
Switching networks, RSVP should be extended with Objects, such
that when used in conjunction with available information
propagated through the IGP, the RSVP Objects will be able to
provide sufficient details to establish reconfiguration
parameters for OXC switch elements.
- When a pair of OXCs are directly connected by multiple links
(fibers), an IGP needs to carry information about the physical
diversity of the fibers.
- Because conventional LSRs and OXCs may support different
granularities of bandwidth allocation, an IGP should
be able to distribute information regarding the allocatable
bandwidth granularity of any particular link. This information
should allow multiple granularities within a single link. It
should also allow different granularities per priority.
Additional requirements which may be imposed by OXCs that cannot
perform wavelength translation are outside the scope of this
document.
B) As indicated in reference [1], the capability to aggregate LSPs
through the notion of nested LSPs is an important aspect of
using the MPLS traffic engineering control plane with OXCs.
Using the MPLS traffic engineering control plane, several
methods can be used to implement nested LSPs. One way to
accomplish this is to have a single MPLS traffic engineering
control plane instance for both conventional LSRs and OXCs, but
to allow the control plane to treat subsets of the LSPs as links
Basak Expires August, 2000 [Page 6]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
for the purpose of establishing new LSPs (by the same control
plane). In this way, the MPLS traffic engineering control plane
could use an LSP (which it had previously instantiated) as a
link to establish a new LSP. In principle, this technique can be
applied recursively to form several depths of LSP nesting.
Another way to accomplish LSP nesting is to have more than one
instance of the MPLS traffic engineering control plane, and to
allow LSPs created by one instance of the control plane to be
used as links by another instance of the control plane.
In general, irrespective of whether a single instance of the
MPLS traffic engineering control plane is used, or whether
multiple instances are used, the LSPs that serve as links for
other LSPs could be established by: (a) methods outside the
scope of the MPLS traffic engineering control plane (e.g., by
administrative configuration), or (b) via the MPLS traffic
engineering control plane.
The following paragraphs present a list of required enhancements
to the MPLS traffic engineering control plane components
(ISIS/OSPF and RSVP) in order to support the capability to
aggregate and nest LSPs in MPL(ambda)S:
- The LSP setup procedures should include support for an LSR at
the edge of a TI-LSR domain to aggregate multiple LSPs coming
from outside of the TI-LSR domain into an LSP that consists of
an optical channel trail.
- An LSR should be able to advertise into an IGP a link that
is formed from an LSP originated by the LSR, The IGP
should be able to advertise the link state for such links.
The link state information can be used subsequently for path
computations for other LSPs.
- In scenarios with more than one instance of the MPLS traffic
engineering control plane, one instance of the control plane
should be able to advertise LSPs created and maintained by that
instance as links to another instance of the MPLS traffic
engineering control plane. The instances of the control plane
may reside on the same network element or on different network
elements.
It should be noted that the capability to aggregate LSPs through
nesting may be useful in contexts outside of the OXC
environment. Therefore the required enhancements specified above to
support aggregation of LSPs through nesting should be implemented
Basak Expires August, 2000 [Page 7]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
in a manner such that they remain applicable in conventional
non-OXC environments.
The detailed specification of the enhancements to the MPLS traffic
engineering control component to support the MPL(ambda)S concept
will be covered in a supplementary 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.
[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
Basak Expires August, 2000 [Page 8]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000
[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)
22001 Loudoun County Parkway
Ashburn, VA 20147
Phone: 703-886-5277
Email: awduche@uu.net
John Drake
Chromisys, Inc
Phone: (408) 738-4194 x252
Email: jdrake@chromisys.com
Yakov Rekhter
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: yakov@cisco.com
Basak Expires August, 2000 [Page 9]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/