FW: Proposed text for the concatenation

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

-----Original Message-----
From: Mannie, Eric 
Sent: Tuesday, May 22, 2001 5:10 PM
To: 'tony.flavin@bt.com'
Cc: neil.2.harrison@bt.com; tsg15q11@ties.itu.int
Subject: RE: Proposed text for the concatenation


Hello Tony,

>From an operators perspective, I am very concerned at the proposal for
>arbitrary concatenation. It does nothing that virtual concatenation cannot
>achieve (in fact less, as it does not support random time slot assignment
>capability), and involves the upgrade of every network element it traverses
>(virtual only requires support in the terminating devices).

This was extensively discussed last week and apparently not everybody agreed
:-)
Of course virtual concatenation would be nice and easier from the network
point of view.
However, in the real world it is not so simple.
Two factors are important: cost and the legacy equipment.

We are operator of both a large transmission network and a large IP transit
AS. Traditionally, IP routers don't implement virtual concatenation (as far
as I know virtual concatenation is not implemented at all by Cisco, all
interfaces are contiguously concatenated).

Note that this is only relevant for IP routers connected through a switched
SDH network. It is not relevant if two IP routers are directly connected by
a lambda using POS encapsulation (that's the way the Ebone IP backbone is
build), in that case you don't care. You just implement the easiest/cheapest
solution, i.e. contiguous concatenation. However we are facing a large
demand for VC-4-4c from our customers.

There are also some *cheap* (interesting for operators) edge devices (ADM's,
terminal multiplexers) that don't implement virtual concatenation at all.
For instance, devices used to transport FE/GE in the MAN.

However, a significant number of manufacturers are proposing ADM's that
implement virtual concatenation, and some of them supports even LCAS (Link
Capacity Adjustment Scheme). That becomes really interesting and that's cool
from the network and service point of view.

So for IP we need contiguous concatenation, for Ethernet services we need
virtual concatenation and contiguous concatenation.

Flexible concatenation is a local optimization at an interface needed to
optimize the bandwidth allocation. It was not needed in the past, it is now
needed because we will have dynamic circuits that could create fragmentation
in the multiplex. See hereafter.

Arbitrary contiguous concatenation is interesting for two reasons, first if
you sell new services with new bandwidth levels e.g. a VC-3-3c, VC-4-5c,
etc. Second, because you have again the optimization problem, for instance
if you have a mix of VC-4's and concatenated VC-4's, you could want to
optimize the bandwidth allocation and to start a VC-4-4c at any place.

>Could the contributors to this technique explain why we need to define
>another Ford when we already have a Ferrari?

In the dynamic model that we are thinking about, circuits will be
established and closed dynamically. After some time you could have a
fragmented multiplex. It is similar to the hard disk fragmentation problem,
after some time your have small holes everywhere. You cannot re-use these
small holes for a contiguous block of bandwidth, except if you re-organize
your network (intrusive). A way to solve the problem is to enable flexible
concatenation. It is useful for the user if his local interface multiplex is
completely fragmented and that he cannot open a new circuit anymore due to
the lack of a contiguous block that is big enough. It is also a useful local
optimization internally to the network.

Kind regards,

Eric

>From an operators perspective, I am very concerned at the proposal for
arbitrary concatenation. It does nothing that virtual concatenation cannot
achieve (in fact less, as it does not support random time slot assignment
capability), and involves the upgrade of every network element it traverses
(virtual only requires support in the terminating devices).

The further addition of flexible arbitrary confuses matters still further
where a contiguous to virtual conversion is already fully defined.

The proposal is technically inferior to the already defined and existing
techniques, and is unlikely to receive a warm welcome if bought to the ITU.
Could the contributors to this technique explain why we need to define
another Ford when we already have a Ferrari?

Regards

	Tony Flavin

	BTexact.

	BTexact.


-----Original Message-----
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: 18 May 2001 21:28
To: ccamp@ops.ietf.org
Cc: ip-optical@lists.bell-labs.com
Subject: Proposed text for the concatenation


Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

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."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: eric.mannie@ebone.com