Subject: Question about Multiprotocol Lambda Switching (a bit long)

From: Francisco Javier Ortiz Oliveira <[email-masked]>
Date: Mon, 22 Nov 1999 15:49:00 +0100

Hi,

    I have some questions about draft-awduche-mpls-te-optical-01.txt.

    In what sense does the use of MPLS Traffic Engineering control
component try to move MPLS to lower levels in the stack? I mean, I do
not know whether the approach suggested is essentially "transform labels
into lambdas" or at least as a first step towards stack reduction 
(IP->MPLS->WDM), or it is much more simple, this is, to reuse that control 
component in a level that can be modeled as a "small" (even with thousands of lambdas, it would
still be small compared with a network with millions of labels) network since lambdas, which are
similar to labels, are much fewer than these.

    Also I think of an hybrid approach in which some huge LSPs can be
directly put on a lambda (of course there is an implicit inefficiency), 
the rest of them put together in one or several lambdas. Is this ridiculous
or does it make a little sense?

Thanks.

---

From: "Stephen Shew" <[email-masked]>
Date: Mon, 22 Nov 1999 10:25:00 -0500

> into lambdas" or at least as a first step towards stack reduction

Yes, I think the draft suggests that lambdas be treated as labels as far as the control plane is
concerned.  Further these labels would be on par with other labels since they state in section 6.2
that "a Label Switching Path could traverse an intermix of routers and OXCs".

> similar to labels, are much fewer than these.

I'm not sure what you mean.  Are you suggesting that MPLS control is only reused within L1 or L0 and
not related to MPLS for L2?

> or does it make a little sense?

This makes sense and was pointed out in the draft at the end of section 6.2.  Putting several LSPs
together into the same lambda is accomplished by stacking those LSPs inside the lambda LSP.  This
makes a lot of sense because current LSPs can be multiplexed over the same bandwidth (e.g., several
LSPs using PPP shims on the same link) whereas lambdas or SONET time slots represent fixed
bandwidths (like ATM CBR).  So stacking LSPs which use an encapsulation that is usually stat muxed,
into the lambda LSP makes a lot of sense.

--
Stephen Shew                Voice: 613-763-2462   Fax: 613-765-3165
Nortel - Carrier Packet Solutions  email: [email-masked]
P.O. Box 3511, Station C
Ottawa, ON  K1Y 4H7

---

From: [email-masked] (Daniel Awduche)
Date: Mon, 22 Nov 1999 12:13:13 -0500 (EST)

Thank you for your comments.

The intent is not to move MPLS to lower levels in the stack.

Simply stated, the draft suggests the use of MPLS TE control plane
artifacts as a control plane for OXCs in the optical domain. We
justified this approach by enumerating several commonalities (at a
suitable level of abstraction) between LSRs and OXCs on the one hand,
and between LSPs and optical channel trails on the other.

Numerous advantages of this scheme were identified. One particular
advantage is that it obviates the need to reinvent duplicate control
constructs in the optical domain. It also enables new and interesting
architectural possibilities.

The reason why we submitted a revised version of the draft is that
we've included a new section on "Architectural Considerations for
Deployment in Operational Networks," which clarifies some issues
raised following my presentation at the MPLS WG meeting in DC,
including some of the issues that you've reiterated below.

Best wishes,
/Dan

---

From: Antonio Rodriguez-Moral <[email-masked]>
Date: Mon, 22 Nov 1999 12:40:54 -0500

Francisco Javier,

During the last IETF meeting in Washington DC, at the MPLS WG session, I
tried to clarify some of the issues raised by the draft that you
mention. After talking to Daniel Awduche, this is my view:

There are 2 separate problems here:

Problem 1: Design of a control plane for OXCs that enables the
development of feature-rich OXC, with the following features:
-fast provisioning of optical channels
-optical channel layer bandwidth management
-protection and restoration

Problem 2: Design of an control plane for OXCs in "optical
internetworks" consisting of OXCs and LSRs that results in an optimized
IP-centric solution. Optimized mean that uniform semantics for
management and control of both OXCs and LSRs is a very important
feature.

Problem 1 is an "optical-layer only" problem, independent of whether the
OXC are interconnecting LSRs, ATM switches, GbE switches, or just
SONET/SDH gear.
Problem 2 is of relevance for ISPs, backbone builders and network
operators which control both the LSR and OXC infrastructure.

With respect to protocol stack: In problem 1 the protocol stack can be
IP/X/WDM, depending on the equipment that the OXCs are interconnecting
(e.g. X can be ATM/SDH, or ATM, or GbE, etc.). In problem 2 the protocol
stack will look like IP/MPLS/Y/WDM. Note that a layer 2 (denoted by Y)
is still required for the protocol stack mapping (it could be a new,
thin, layer 2 protocol, with packet encapsulation and delineation as a
minimum, or still POS or ATM).

With respect to the control plane: I can think of several possibilities
for the solution of problem 1, but it is clear that a possible strategy
(as proposed by the authors) is to reuse/tailor MPLS-TE (including the
required extensions to IGPs, etc.) to form this control plane, which
also looks as the preferred solution for problem 2. The challenge is how
to do this in such a way that the resulting tailoring accommodates both
problems. For example, common semantics between OXCs and LSRs can be
considered as a required feature for problem 2, but it does not apply to
problem 1, which is more general than problem 2. A peering model between
OXCs and LSRs seems appropriate for problem 2, while a layered model
seems more appropriate for problem 1, etc.

And, among some other issues, the solution also should take into account
that in a not distant future the optical layer will be built on a
multiplexing hierarchy (40 Gbps per wavelength is almost here, and 160
Gbs per wavelength will be here in a few years, and then it makes not
sense to have a flat optical layer), and that the solution should allow
for integration of optical layer restoration and existing and emergent
signaling platforms at the optical layer (as opposed to solutions based
only on SONET/SDH overhead)

				Saludos

				Antonio
-- 
Antonio Rodriguez Moral
Bell Laboratories - Lucent Technologies
Advanced Optical Networking Center
Rm. 3C-502A, 101 Crawfords Corner Rd.
Holmdel, NJ 07733, US
voice: +1 732 949 2164
fax:   +1 732 949 3210
email: [email-masked]
--