No Subject

[Don Fedyk <dwfedyk@nortelnetworks.com>]

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
> 
>