Re: [IP-Optical] concatenation extensions in sonet/sdh

[Maarten Vissers <mvissers@lucent.com>]

Virtual concatenation is intended to offer the support of new ("odd
sized") service signals by the existing network.

Arbitrary concatenation (at least per "real problem" described by Greg)
is intended to offer "non blocking" links (connection between two
adjacent SDH/SONET equipment) without the need to perform a bandwidth
defragmentation action once every ... days.

The link which can't have this defragmenation, is surrounded by
arbitrary concatenation capable STM-N/OC-N line ports. A simple and
local upgrade in the existing network (replace/install 2 port units).

The network which want to offer the new ("odd sized") service is
surrounded by virtual concatenation capable client signal tributary
ports (e.g. 1GE port). A simple and local upgrade in the existing
network (install 2 port units).

As long as arbitrary concatenation isn't sold as a means to introduce
new ("odd sized") services, arbitrary concatenation and virtual
concatenation provide additional capabilities to the existing network
with local upgrades only, and without introducing new interworking
problems.

Hope this is a fair summary up to here.

Now lets have a look at the signalling impact.

- Virtual concatenation most likely doesn't need any special treatment
(in first instance) in the signalling for connection setup (latest
understanding by me). If a virtual concatenated trail is to be set up,
actually a set of X basic VC-n/STS/VT network connections are to be set
up. This may be done as the set up of X individual connections, the set
up of one group of X (co-routed) connections, the set up of n subgroups
with X1, X2, .., Xn connections each. 
The group of network connections is to be set up between two Access
Groups (AG) of the same type (virtual concatenated and same client (i.e.
G-PID)).

- Arbitrary concatenation most likely doesn't need any special treatment
in the signalling for the STM-N/OC-N trail to be set up. The STM-N/OC-N
connection can be a (virtual) fiber, and in this case STM-N/OC-N trail
setup is manual (connecting fibers). The STM-N/OC-N connection can be
created via a WDM/OTN network, and in this case the OCh/ODUk trail set
up can be performed as normal; i.e. between two access groups of the
same type and with the same G-PID (indicating STM-N/OC-N with arbitrary
concatenation support).

The use of this HOVC/STS link with arbitrary concatenation is the same
as any other HOVC/STS link (without arbitrary concatenation); at least
from the outside. Between the two SDH/SONET equipments however (i.e.
internal to the link), the signalling message will have to include the
list of timeslots. But this can be kept local to the link.

In G.ason/G.dcm the assumption is to use a link connection identifier
(i.e. address), hiding the multiplexing details during the connection
setup. The link connections have been discovered during the service
discovery phase of the creation of the link. Only in this service
discovery phase the multiplex numbers play a role. Also for arbitrary
concatenation this two step approach can be used, preventing any need to
include in the connection creation signaling message on the link the
list of timeslots allocated to this link connection. I.e. any possible
link connection allocation has its own identifier/address, which is
assigned during service discovery.

I am not sure if I am completely correct in this second part... but at
the moment it looks positive to me.

Regards,

Maarten
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard