RE: SDH/SONET concatenation signal types

[Hai Vodinh <HVoDinh@turinnetworks.com>]

The other big & complex issue that arises when considering diverse route
for VC signal is that the differential delay for the paths need to be taken
into account.  This will help the end nodes to determine if they can
actually
deal with the differential delay.  For example, if the end node can only
deal with a differential delay of N frames between the paths then some how 
the path computation step has to return paths with differential delay of <
N.

This does need a lot more work.  At a high level, signaling needs to be able
to request path with some delay contrainst, and routing need to have a delay
metric.

Regards,
Hai

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Thursday, March 15, 2001 7:13 AM
To: Heiles Juergen
Cc: 'ccamp@ops.ietf.org'
Subject: Re: SDH/SONET concatenation signal types


Juergen,

You hit an area which needs more work... 

VC-n-Xv up to now is associated with co-routing of all X VC-n signals
inthe virtual concatenated group. The introduction of LCAS feature,
requires that the X VC-n signals within a VC-n-Xv signal are NOT
co-routed; the group should be at a minimum split over two diverse
routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
identifications are not adequatly representing the two (or more)
subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
VC-n-X1 and a VC-n-X2 connection are to be set-up.

As such, we could restrict the set of Types to VC-n-X and at the
endpoints associate one or more VC-n-X's to the VC-n-Xv or VC-n-Xv LCAS.

trail						trail
endpoint					endpoint
VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv

	       /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
VC-n-Xv LCAS <=				    	   => VC-n-Xv LCAS
	       \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/

In either case, the LSPs are "VC-n-X" types. 
At the end points of the trail (where you connect the Trail Termination
Point, via matrix connections in the Fabric, to the Link end points) the
additional mapping knowledge is needed.

Being at this point in thinking, I have to ask the question if we should
differentiate between the type of "signal" being transported and the
type of "transport entity" the "signal" is transported over. 

E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
link connections" and a second "group of X2 VC-n link connections", and
a "VC-n-Xv signal" is transported over a "group of X VC-n link
connections".
And in the simple case, a "VC-n signal" is transported over a "VC-n link
connection".


Regards,

Maarten



Heiles Juergen wrote:
> 
> I have a question on the different SDH/SONET concatenation signal types
proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv
LCAS, VC-n-X). Defining different signal types makes only sense if a
different behaviour is assumed. What is the difference between these types?
Is my interpretation correct?
> 
> VC-n-Xv: fixed virtual concatenation; co-routed
> VC-n-Xv LCAS: flexible virtual concatenation; different routes
> VC-n-X: no concatenation; co-routed
> 
> For the later as it could be also used for all other signal types would it
be better to introduce some kind of grouping for signal types that have to
be co-routed?
> For all the 3 types how would you indication the timeslot, position of the
individual VCs as the may/will not use contiguous slots. If different routes
are used they even go accross via different interfaces and NEs and you
cannot include  them in a single label request.
> 
> Regards
> 
> Juergen