Re:

[Maarten Vissers <mvissers@lucent.com>]

Don,

Thanks for the pointer to this routing delay metrics draft.

On the delay issue itself, I did some further investigations to the
differntial delay compensation capabilities state of the art
implementations would support. 

As an example, 1 GbE interfaces are added to SONET/sDH equipment using a
VC-4-Xv LCAS (X=1..7) signal to transport the Ethernet packets in the
GbE interface signal. 

The differential delay compensation capability such a VC-4-Xv LCAS
egress point (where the payload signals in the individual VC-4s are
interleaved again and the ethernet packets are mapped into another 1 GbE
interface signal) supports is these days 16 ms (32 ms buffer). This is
equivalent to about a 3000 km fiber lenght difference (transfer delay in
fiber is 5 us/km).

Do you agree that there is not much to worry about in such case, unless
you try to go world wide.

Regards,

Maarten



Don Fedyk wrote:
> 
> Hai
> 
> On the comment for Routing Delay Metric please see draft
> 
> http://www.ietf.org/internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt
> 
> I have been a supporter of this for some time and I do believe such a
> feature is valuable to both Packet and Optical GMPLS networks. There has
> been reluctance on the part of the various routing groups to embrace this
> there are a few outstanding updates to make the draft clearer.
> The CCAMP area is where the work is supposed to fall right now. Our tactic
> with the draft was to introduce a few optional metrics to give flexibility
> in this area.
> 
> Don
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> > Sent: Thursday, March 15, 2001 3:41 PM
> > To: 'Maarten Vissers'; Heiles Juergen
> > Cc: 'ccamp@ops.ietf.org'
> > Subject: RE: SDH/SONET concatenation signal types
> >
> >
> > 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