RE: LMP vs. NTIP vs. "funiculus"

[Jonathan Lang <[e-mail]>]

Maarten,
  I agree that reproduction of capabilities already present is a bad idea.
LMP was initially designed to address issues between GMPLS peers (OXC-OXC,
router-OXC, etc.) that were not addressed with current mechanisms.  There
was a joint proposal in the OIF (oif2000.254; I can send it if you don't
have access to the OIF website) identifying the need for an OXC-WDM
interface (we called it an OLI for Optical Layer Interface) and proposing
that LMP be extended for this purpose.  The lmp-wdm draft that was submitted
to the IETF last December began outlining some simple extensions to LMP for
the OXC-WDM interface.  So, looking again at your diagram (slightly modified
to remove the single channel limitation in case of wavebands), this is how
LMP-WDM fits in.

      parallel      DWDM        parallel    parallel       DWDM
     interfaces     line       interfaces  interfaces      line
  OXC ======= DWDM ------- DWDM ======= OXC ======== DWDM------- DWDM ==
   \ \_______/    \_______/    \_______// \ \________/    \_______/
    \ lmp-wdm       OSC        lmp-wdm /   \ lmp-wdm        OSC
     \________________________________/     \_______________________
                    LMP                                 LMP

>From our prospective, it seems easy to make a few extensions to an existing
protocol (LMP) to meet these requirements.

Thanks,
Jonathan

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]]
> Sent: Thursday, March 29, 2001 10:49 PM
> To: Andre Fredette
> Cc: [e-mail]
> Subject: Re: LMP vs. NTIP vs. "funiculus"
> 
> 
> 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.
>