[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SDH/SONET concatenation signal types
Hai,
Are you trying to tell me that the control plane will have less
capabilities than the management plane :-)?
I expect that in most cases equipment have enough delay compensation to
not have to worry about it. If 99% of all set-ups would result in a good
path, you may decide to redo the set-up if a diff delay alarm is
raised...
Note - The diff delay compensation capabillity is expressed in number of
milliseconds that can be accommodated (not in number of frames).
But for long connections it would be helpful to have transfer delay
values per fiber span (that's were most of the delay is in the network)
that would result in transfer delay values for each Link in a layer
network.
As this would be a refinement, it could be a release 2 feature...
Nevertheless, I had the impression that there are control planes today
that support a lot of parameters per link; e.g. look at ATM. So why
can't SDH have one parameter... :-).
For me the control plane must be able to support the same functionality
that is now supported by the connection management in the management
plane. The control plane should not restrict the operator in deploying
the features offered by the transport plane.
Regards,
Maarten
Hai Vodinh wrote:
>
> 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
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:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:mvissers@lucent.com
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard