Status of the GMPLS extensions for SONET and SDH control draft

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Dear all,

The GMPLS extensions for SONET and SDH control are discussed since 1.5 years
by a large set of people, we had a large number of meetings at each IETF and
even during OIF. The draft itself has 30 co-authors from 16 companies. The
signaling was presented at several IETF meetings, published in various
releases of internet drafts, presented in conferences, used as a basis for
the OIF UNI, and is currently in WG last call.

For each feature we had to debate about its meaning, its use, its
applicability, etc. It is certainly not about one or two vendors that wanted
to have a proprietary feature. This signaling also represents our vision of
what we could do in the future with SDH/SONET and GMPLS, we tried to include
several ideas that, from our point of view, could be beneficial for many.

This draft speaks only about SDH/SONET SERVICES and their relevant features.
We discussed only a few services and we agreed to keep others for further
study, e.g. LCAS, control of other SDH multiplex structures, etc. We
focussed on a very few services that seems sufficiently important to be
included first: concatenation and transparency. The proof that these
services are of importance is the amount of additional debate that we had
during the last few weeks thanks to the WG last call process.

There is up to now no reason to consider transparency and concatenation as
being proprietary extensions given the support that these features had from
the community. They are implemented/being implemented by many and they are
clearly useful. Note in addition that virtual and contiguous concatenation
are an integral part of the SDH/SONET standards. Arbitrary and flexible
concatenations are behaviours using the current SDH/SONET toolbox.

There was a lot of discussion on IETF and ITU-T mailing lists about the need
of each particular type  of concatenation and there was no consensus that we
should restrict our scope to one in particular. There are different needs
and different usages. Today IP routers use almost exclusively contiguous
concatenations, Ethernet devices use mainly virtual concatenation, arbitrary
concatenation gives much more flexibility (and is used) and flexible
concatenation allows a local optimization needed because we will have
dynamic circuits. Each type has its own usage and its own applicability
field. It does not mean that somebody must implement all of them of course.

The issue that was raised during this working group last call process up to
now is relative to the flexible concatenation. Somehow this was included in
some previous versions of the draft but not fully understood by everybody.
It disappeared completely during some editing, I am guilty. We proposed a
text to clarify it and we had no negative answer about the technical content
of the text up to now (this text is re-included hereafter).

Simply a few people argued that we need new ITU-T standards to support these
features, that everything that is not described in G.707 is proprietary, and
that we are redefining SDH/SONET standards.

We are indeed defining some particular behaviours on the top of the
standardized SDH/SONET, but we are not redefining anything in the SDH/SONET
standards. These behaviours are new, some have limitations, but we think
that they are all valuable and useful. I understand that people that
discovered this work for the first time had problems to understand its
scope.

I received no technical comment about the draft with the new proposed
extension for flexible concatenation (included again hereafter). Please, I
will appreciate if you could send comments if you see any technical problem.

We are also still waiting to know what are the missing standards that are
needed to implement these features in the context that is described in Annex
2 of this e-mail, we had no answer today.

Thanks to help us.

Kind regards,

Eric

---------------------------------------------
ANNEX 1
---------------------------------------------

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."


-----------------------------------------------------------------------
Annex 2: about the service's features that we are talking about:
-----------------------------------------------------------------------

1) SDH/SONET features that need an additional standard to be able to
interoperate:
----------------------------------------------------------------------------
------

In that case this is not at all in the scope of the IETF of course. I never
heard anybody at the IETF proposing to do SDH/SONET standards, it does not
make sense of course. The IETF management was *very* clear about that. It is
well understood and agreed.

2) SDH/SONET features that don't need any new SDH/SONET standard:
-----------------------------------------------------------------

Let's speak about three important features:


About arbitrary contiguous concatenation:
----------------------------------------

Arbitrary contiguous concatenation (as described it in the proposed text)
don't need any standard, it is just a way to use SDH/SONET. It is already
implemented since a while by many manufacturers in legacy equipment's. In
that case there is NO reason why we should not define features to control it
in the GMPLS signaling. It is not because it is not described in G.707 that
we cannot do it, or that it doesn't work.

About transparency:
-------------------

Transparency at the GMPLS UNI does not require any SDH/SONET standard
because it is not implemented at the UNI, it is 100% about signaling. We
never said that GMPLS must be used at both the UNI and NNI. The NNI could be
in a proprietary cloud of a single manufacturer. So, there is no reason to
remove it from the GMPLS signaling.

If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
at the NNI between two manufacturers needs an agreement to interoperate.
This agreement can be achieved in very different ways: through the use of a
standard, an implementation agreement made by a forum, or an implementation
agreement between two manufacturers (e.g. at the request of an operator).

ITU-T, T1X1, ETSI or OIF could produce such an agreement. At the last OIF
there was a session dedicated to transparency. We can expect to see more
contributions at the next OIF meeting. Some contributions could also be
presented to T1X1. Anyway, that's not the business of IETF and has nothing
to do with transparency in the GMPLS signaling at the UNI.

About flexible arbitrary contiguous concatenation:
--------------------------------------------------

What is the additional standard that we need to support flexible arbitrary
contiguous concatenation. Could someone describe what should be standardized
and why two implementations could not interoperate ?

The GMPLS signaling allows to know the type, the number, the order, and the
position of all components. Flexible arbitrary contiguous concatenation in
GMPLS is only an indication send to the downstream node that it could use
this feature. The upstream node doesn't request it, it simply says to the
downstream node that it supports it. The downstream node can either decide
to ignore it and use a standard contiguous concatenation, or an arbitrary
contiguous concatenation; or it could refuse the connection request. This is
a local optimization to deal with local external fragmentation of the
multiplex that will happen if one route very dynamic demands. There is for
sure absolutely no interoperability issue between nodes that implement it
and nodes that doesn't implement it because it is not used in that case :-)