The MPLS WG Archive

[Bala Rajagopalan <braja@tellium.com>]

Hello:

darren.freeland@bt.com wrote:

> Hi Kireeti,
>
> >> However, the point of GMPLS is NOT a peer model.  It is an IP-based
> >> control plane, leveraging existing work, and the flexibility of a
> >> peer or overlay or hybrid model.
>
> Perhaps you missed my point.  I didn't say the point of GMPLS is a peer
> model (I have read the draft) - I questioned the assumption that IP-centric
> control protocols will be appropriate for an optical (or indeed any) control
> plane.  As far as I can see (having read the IPO framework, the MPLambdaS,
> and the Generalised MPLS drafts I hasten to add), this assumption has been
> made without giving full consideration to the requirements of the particular
> networks the protocols will be applied to.  My interest is the OTN, so
> that's what I've been focussing on.

Our practical experience so far (w.r.t product development)
has been that IP centric control protocols are both appropriate and
also practical for controlling dynamic provisioning. We are able to reuse
available protocol  implementations (of course,
some degree of customization is needed). We have not found it suitable
(yet) to utilize an IP-centric protocol for restoration under our tight
time constraints. Note that this is a control plane inside a single vendor
network. Models for multi-vendor interoperability using IP-centric
protocols are still evolving, IMO.

>
>
> The IPO framework document starts out in the introduction by saying that
> "there is wide consensus in the industry that the optical control plane
> should be IP-centric".  I would question this 'wide consensus'.  There is a
> few (very basic) requirements set out in the introduction, but nothing that
> justifies thoroughly the choice of IP-centric control protocols for the OTN.

The statement on consensus is true to the degree that  optical network
equipment vendors would like to use IP-centric protocols for control within
their network. As for requirements, there are three aspects. First, the
requirements
for control within a network: these are met by the IP-centric control plane in
the view of many vendors (other than restoration for which IP-centric
control may not be a choice for all vendors). Second, the requirements for
controlling
interoperability: the premise is that an IP-centric control plane will be
suitable for this also. The debate is on the type of control and this centers on

 the peer and overlay. Finally, the service requirements: these are the
least articulated requirements. There is some effort in the OIF to involve
service providers in formulating these requirements, and these will be
reflected in the IETF also.

>
>
> The MPL(ambda)S document does the same - we're told in the intro that the
> optical control plane will be based on the MPLS TE control plane model.  The
> only justification that is given for this is the reuse of existing
> protocols.  Cool - why not reuse PNNI then?  I'm not advocating one or the
> other yet - what I am saying is that the requirements of the OTN (or any
> other network in the case of GMPLS) should be fully considered in the first
> place.  The choice (and extensions) of control plane protocols should then
> be made to fit these requirements.

The rationale for choosing an IP-centric control plane (as opposed to
say, PNNI) is the focus on IP clients. I don't think there is any secret here.
There is a hope that an IP-centric control plane inside an optical network
would make it possible to achieve flexible interaction with IP client networks
(leaving aside the peer and overlay issues for the moment).

>
>
> The other problem I have with the MPL(ambda)S philosophy is its clear bias
> towards the 'peer' option.  Sure, the 'overlay' option is described, but it
> is not fully discussed - we are simply told that "to understand the
> drawbacks of this approach ... one need look no further than the experience
> with IP over ATM".  This is a whole discussion in itself which Neil Harrison
> has touched on in his reply to you.  ATM is not the OTN.  This aside, my
> point is that the peer model is clearly advocated over the overlay model -
> but there is no mention to the effect the peer model would have on an
> operator who has a multi-client environment.  There is also a clear
> reluctance on this list to recognise the problems the peer model may bring.

I am personally not a  fan of peer model, but I accept that there are many
who believe in it strongly. I agree with you that no (optical) service
provider (to my knowledge)
has made a statement about deploying a service to IP clients using the peer
model.
Neither have I seen any statement from any network operator as to their
intention on using the peer model for an IP-optical intranet. It has also not
been quantified (in any scientific manner) what the traffic engineering
advantages
of the peer model are. But this is irrelevant now, since the signaling
developments
in GMPLS and OIF are towards using a common framework for peer and
overlay models, with a path for evolution from overlay to peer. The IPO
framework document has tended to be very balanced in its view with
regard to the interoperability models and it describes the evolution
approach. In particular, it describes how an IP-centric control plane
in the optical network eases IP-optical interaction even for establishing
overlays (under the routing models section).

Regards.
--

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