Re: LMP vs. NTIP vs. "funiculus"

Maarten Vissers <mvissers@lucent.com> Fri, 30 March 2001 06:49 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 29 Mar 2001 22:58:58 -0800
Cc: ccamp@ops.ietf.org
Message-ID: <3AC42C6E.D404C714@lucent.com>
Date: Fri, 30 Mar 2001 08:49:18 +0200
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
MIME-Version: 1.0
To: Andre Fredette <fredette@photonex.com>
Original-CC: ccamp@ops.ietf.org
Subject: Re: LMP vs. NTIP vs. "funiculus"
Content-Type: multipart/mixed; boundary="------------F9B1A2F86CF530BD38B6F266"

Andre,

I have in general problems with reproduction of capabilities already
present in e.g. a transport plane. Seems a waste of time to me.
But when the transport plane doesn't have the capabilites an action
is required. Either extend the transport plane or rebuild the mechanism
in the management or control plane.

I prefer to extend the transport plane when this is a simple extension
of a common practice which is already present in other parts of it; it
maintains amongst others the performance. For the OTN this is definitely
the case, and therefore there would be no need for an LMP in the OTN.

Other technologies like Ethernet and also SONET/SDH are not designed to
support PXCs (optical fabric equipment). That's why we are building the
OTN. I assume that is why LMP is being defined. But as we will "extend"
the transport plane for OTN, it may be well possible to use the same
extension for SONET/SDH and Ethernet...

For OTN (and also SONET/SDH/Ethernet) signal transport through a DWDM
line we already defined a supervisory channel (the OSC) as an extra
wavelenght in the DWDM line. The extension proposal for the OTN (and
perhaps also to be used for SDH/SONET/Ethernet) is to add another
supervisory channel between the DWDM terminal and the PXC (also referred
to as OXC). I have called this the "funiculus" (which is another word
for umbilical cord). In a WDM network, you will have the OSC and the
funiculus located as follows: 

     parallel      DWDM        parallel    parallel       DWDM
      single       line         single      single        line
     channel                   channel     channel
    interfaces                interfaces  interfaces
 OXC ======= DWDM ------- DWDM ======= OXC ======== DWDM ------- DWDM ==
    \_______/    \_______/    \_______/   \________/    \_______/
    funiculus       OSC       funiculus   funiculus        OSC

OSC is between two DWDM line terminals, whereas the funiculus is between
optical fabric (OXC) and DWDM line terminal (tributary side).

OSC is on a wavelenght within the fiber, whereas the funiculus is on a
dedicated fiber or copper wire/coax cable.

The funiculus is part of the new (multi-fiber) OTM-LF interface I am
proposing (see Q.11/15 correspondence document cd-otmlf01 (attached) or
at http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.pdf ).

Regards,

Maarten


Andre Fredette wrote:
> 
> Maarten,
> 
> You make some good points.  I believe that one of the objectives of LMP is
> to reproduce the capabilities currently present in the transport plane.  As
> you point out, with the advent of PXCs, some of the functionality
> traditionally handled with in-band SONET signalling needs to be exchanged
> in another way.  We will also be dealing with other technologies, such as
> Ethernet, that does not have built-in overhead.
> 
> Also, as we move towards distributed control of multi-vendor optical
> networks via GMPLS, open protocols are needed between the different nodes
> for exchanging the necessary information.  In addition to the fault
> handling capabilities you describe, I think we need discovery capabilities
> that will reduce the required manual configuration.
> 
> I believe there are two questions at hand:
> (1)  Which protocol should be used to exchange the information in
> GMPLS-controlled networks?, and
> (2)  What information needs to be exchanged?
> 
> The mpls, and now ccamp, working groups in the IETF have been working on
> LMP to solve question (1) for the past year.  Unless there is an
> overwhelming need to create a new protocol, I think we should stick with
> LMP (and I haven't even seen an underwhelming reason to switch :-).
> 
> Question (2) could use some additional discussion as it pertains to
> transport systems.  We have a proposal in draft-fredette-lmp-wdm-01.  Some
> good ideas exist in draft-sahay-ccamp-ntip-00, and you've made some good
> points in your note.
> 
> Andre
> 
> At 01:05 PM 3/26/2001 +0200, Maarten Vissers wrote:
> >When looking at the LMP work I am have the impression at the moment that
> >it is partly duplicating capabilities already present in the transport
> >plane.