[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP vs. NTIP vs. "funiculus"
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
>From our prospective, it seems easy to make a few extensions to an existing
protocol (LMP) to meet these requirements.
> -----Original Message-----
> From: Maarten Vissers [mailto:email@example.com]
> Sent: Thursday, March 29, 2001 10:49 PM
> To: Andre Fredette
> Cc: firstname.lastname@example.org
> Subject: Re: LMP vs. NTIP vs. "funiculus"
> 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
> 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
> 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 ).
> 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.