The MPLS WG Archive

[John Drake <jdrake@calient.net>]

Yangguang,

Have you been following the work on Generalized MPLS (nee MPL(ambda)S) which
has been going on since late last year?  As I said in my note to Frank, we
already do what you're describing (to the extent that I understand what
you're describing), we just don't use a TCP session; instead an IP, GRE, or
IPSec tunnel, or an LSP is used.  

As Kireeti points out, there are practical problems associated with using a
TCP session.

Thanks,

John
-----Original Message-----
From: Yangguang Xu [mailto:xuyg@lucent.com]
Sent: Wednesday, October 18, 2000 10:58 AM
To: Kireeti Kompella
Cc: mpls@UU.NET
Subject: Re: Draft Minutes From Pittsburgh


Kireeti,

I guess I didn't address clearly about using TCP session.

There are two ways to distribute transport network topology. Either way has
pros
and cons. 

1) Piggyback through standard OSPF Opaque LSA
   If we want to apply OSPF/ISIS, CR-LDP/RSVP directly to circuit switched
transport network, you are absolutely right. There should be a one-to-one
correspondence of routing adjacency and control channel. 

   However, there is a fundamental problem here, folks (including me) always
try
to apply existing protocols directly to other applications. Protocols are
always
designed for a certain problem with unique features, assumptions and
requirement. For other "similar" problems which may have different
assumptions
and requirement, "Here it is and use it" isn't always a good solution. We
should
first understand the correct assumption and requirements of optical network
and
then tune routing and signaling protocols for them.

   Using existing solutions, protocols to define problem, application and
assumption seems to be not quite right. 

2) An independent application 
   You don't need a dedicated control channel in this case. A TCP session is
enough. 

Thanks,

Yangguang

Kireeti Kompella wrote:
> 
> > The key point is that routing adjacency in circuit switched network data
plane
> > has nothing to do with control channels (the control plane). At least
there
> > shouldn't be any assumption about their co-existence.
> 
> Actually, there is a one-to-one correspondence (for GMPLS, anyway):
> one routing adjacency for each control channel.
> 
> There is the issue of OSPF-incapable OXCs.  In this case, there may
> be a proxy intelligent device that handles OSPF/signalling/LMP;
> however, that device still needs to have an OSPF adjacency, so the
> problem doesn't go away, it just moves to this device.  However, here
> what you say may apply: the OXC may just need a simple TCP session to
> the proxy device, depending on their (private) API.
> 
> > For each routing adjacency (in data plane), you only need a TCP session
as Frank
> > hinted. Not necessary a physical control channel.
> 
> You don't need a physical control channel, but you do need more than
> a TCP session.  You need a routing adjacency (OSPF doesn't run over
> TCP, and certainly ISIS doesn't), a path for signalling messages and
> (probably) a path for LMP control messages.  Fortunately, a GRE tunnel
> will do exactly this.
> 
> > BTW, I had a feeling that LMP suggest control channel for each bundle.
(I read
> > it long time ago, can't remember exactly). If this is the case, it's
simply not
> > right. For example, a OXC has 10 neighbors, between each neighbor there
are 2
> > bundles, then do you need 20 control channels? NO!
> 
> The next rev of LMP will address this issue.  We basically realized
> that this is an issue for fast Hellos, failover and OSPF, but this
> applies to signalling as well.  So, we'll try to bring this down to
> one control channel per pair of neighboring GLSRs.
> 
> Kireeti.