[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SDH/SONET concatenation signal types
Maarten,
I agree with you to restrict the signal types for virtual concatenation. In order to determine the requried signal types and otehr information lets have a look on the applicaitons and required features:
Virtual concatenation requires only support at the end nodes (trail termination). Intermediate nodes process only the individual signals (VCs). For the routing of the individual signals that form the virtual concatenated signal several options exist:
- don't care: the signals can have common or diverse routes
- common route: minimize differential delay
- diverse routes for all signals or group of signals: LCAS
If I assume that common routing is achieved by the bundling feature independent of virtual concatenation we don't need a special virtual concatenation signal lable for routing. Diverse routing is another feature that is/should be independent of virtual concatenation and a story of its own.
Only if bundling doesn't mean common routing and we don't need common routing for any other application we need a special VC-n-X signal type which just means X VC-n with common routing.
We still have the need to signal the virtual concatenation information between the trail terminating nodes in order to check if end poitns with matching capabilites are connected or are configured accordingly. What information is needed?
- A indication that it is a virtual concatenated signal
- The number of concatenated signals or LCAS
We have already the G-PID type which is also only used at the end points in order to check the client mapping. Putting the information into the G-PID is a possibility, may be not the best. Any ideas?
Regards
Juergen
> -----Original Message-----
> From: Maarten Vissers [SMTP:mvissers@lucent.com]
> Sent: Thursday, March 15, 2001 4:13 PM
> 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 << File: Card for Maarten Vissers >>