The MPLS WG Archive

[Alex Zinin <azinin@cisco.com>]

Neil,

Wednesday, October 18, 2000, 4:08 PM, neil.2.harrison@bt.com <neil.2.harrison@bt.com> wrote:
> Alex Zinn wrote:
>>I wouldn't oversimplify this [NH=> that is, against this statement from
> Yangguang "In circuit switched network, there should be no assumption about
> the relation of data plane topology and control plane topology at all."]
>         Don't forget about IGPs and signaling.

> Alex can you please expand on what you mean by this....taking the following
> into account line of reasonong?

I believe it was explained in the thread quite thoroughly already.
In short, we have protocols in the generalized MPLS control plane
that will not work over a TCP connection, but will require direct
connectivity (through a physical link, LSP, or a GRE tunnel) between
boxes.

See my comments below as well.


> -       the OTN is cct-sw/CO/client-layer PDU-structure transparent
> -       the OTN has no practical buffers

There's no requirement for buffering of transit traffic.
However, in the case where control channels are allocated
from the same pool of fibers (or lambdas), an optical box
will have to be able to terminate them. This is also a requirement
if you want to implement LMP link testing.

> -       IP, ATM, FR, SDH, or whatever is irrelevant as far as the OTN
> user-plane is concerned.

Well... If you use OTN in the overlay model with no dynamic
circuit provisioning, then yes. If OTN is a part of your network
(i.e., peer model is used) or if dynamic lightpath provisioning is required,
then IP becomes very much relevant, since (as far as we are talking about
generalized MPLS or MPLambdaS) OTN nodes are going to use IP/MPLS-TE control
plane (or its rudimentary version in case of UNI).

> -       "server layer trails (in an OTN) = client layer links", and networks
> operators *will* have to support multiple client layers for a very long
> time...including some large BW servives directly off the L1 fabric.

Not sure I follow the logic here. Can you elaborate a bit.

> -       above implies no congruent addressing between any pair of client
> layers or any client layer and the OTN........this implies that the
> addresing scheme used by the OTN is not related to any clients (ie not from
> the same addressing space in terms of possible trail connectivity at layer
> network access points)

Correct.
It does not mean, however, that we need to invent another
addressing system.

> -       it therefore follows (at least to many I speak to who are working on
> OTN topics) that the signalling protocol and the routing/discovery protocol
> used in the OTN can be chosen as 'best of breed' to suit its nature, ie
> cct-sw/CO/user-plane transparent. Obviously different people will have
> different views of what is best-of-breed here.......and this has not to my
> knowledge has not even been openly debated so far.

I believe it has been discussed in a number of forums for quite
a long time by now and the de facto consensus is that MPLS-TE control
plane with required extensions is the one to go with, where
one of the reasons is the presence of implemented and standardized
protocols and interoperability.

It does not mean, of course, that somebody can develop their own
set of proprietary protocols ;)


> -       further, the signalling network of the OTN needs to be designed with
> very high availability/survivability requirements.

Right, and this is what IP routing provides us with.

> To achieve this its
> topology and operating mode are a completely independent facet to how the
> user-plane is specified for the normal 'client traffic'.

Correct, but again, this does not mean we have to invent another
set of protocols.

Regards,

Alex.