The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00014



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Comments on draft-ip-optical-framework-00.txt

  • From: Bala Rajagopalan <braja@tellium.com>
  • Date: Tue, 04 Apr 2000 13:01:06 -0400
  • CC: Juha Heinanen <jh@lohi.eng.telia.fi>, lee.thomas@wcom.com, mpls@UU.NET, ip-optical@lists.research.bell-labs.com, Krishna Bala <kbala@tellium.com>

Curtis:

The dynamic overlay, as suggested, is somewhat close to the intent
of what we were calling "open". However, we need to clarify a few things.
First is the routing interaction between IP and optical domains.
I'm not sure what you mean
by "endpoints" in the dynamic overlay case. If you mean ATM endpoints,
then the so-called "open" model is different.
As Heinrich pointed out in an
earlier email, the addressing
is the same in IP and optical domains.  In the "open" model
scenario, there could be routing exchange between the domains
(e.g., BGP), so there
is really no need to know about optical endpoints corresponding
to destinations in the IP domain (but as in the dynamic overlay
case, the optical network will take care of routing within).
Second, a distinction has to
be made between control and data planes. Even if you use
the peer model with full exchange of topology etc in the control
plane, the
connectivity between routers in the data plane is over a pipe in the optical
domain. That is, the interior nodes in the optical
domain cannot see the IP data or LSPs, and data plane
connectivity is still overlay. The establishment
of the pipes and management of pipe bandwidth will
be similar in each of signalled, dynamic or peer models. Specifically,
the end routers are solely responsible for setting up and managing
the pipe bandwidth. So, it's perhaps useful to just focus on
interface functional requirements (including routing) and not
worry too much about the terminology.

Regards,

Bala

Curtis Villamizar wrote:

>
>
> We are splitting hairs but please recall that there were three cases:
>
>   static
>   signaled
>   peer
>
> One could argue that the latter two are dynamic and that the peer
> model is just a bit more dynamic that the signaled model.  The PVC
> style is certainly the most static.
>
> Since the first two have limited or no visibility into the underlying
> topology they are overlay.
>
> Juha may have added a fourth case.  The following table might help.
>
>    router's topology  type of
>    visibility         path setup      model name           example
>
>     configured*        none            static overlay       ATM-PVC
>     configured*        endpoint        signaled overlay     ATM-SVC
>     endpoints          endpoint        dynamic overlay      MPLS-loose
>     full               full path       peer                 MPLS-strict
>
>    *configured here means endpoints only are configured in the router.
>
> The model Juha proposed is a slight improvement over the pure ATM SVC
> model in that the endpoints to the ATM are advertised for the purpose
> of making ATM call setups.  This model seems similar to the use of
> MPLS with a single loose hop in the explicit route.  It is similar in
> that the ingress knows about the endpoint through signaling rather
> than configuration but leaves it to the next (signaling) hop (which
> would be an optical device) to figure out how to get there.  If the
> ingress had enough information to compute the path, we'd have the peer
> model and the ingress would use strict hops in the explicit route.
>
> It wouldn't hurt to add the distinction that Juha has pointed out and
> adapt the term "dynamic overlay" that he suggested.  I hope this
> terminology is clear.  We seem to have some growing consensus on these
> model names.
>
> Curtis

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com