[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please Clarify Doubts regarding RGT & RNC
Hai Vodinh [mailto:HVoDinh@turinnetworks.com] wrote Sent: 23 March 2001
23:13
> Maarten,
>
> Thanks for the clear and concise explanation of how LCAS work.
> The 'create_new->switch_to_new->delete_old' scheme definitely
> won't work for LCAS then.
>
> Hai
>From the trail defined by the *LCAS framing perspective* this is
correct....with the additional (minor, but subtley important) observation
that these new (LCAS) layers are not networked themselves. But you are
still creating (and deleting, potentially at least) new (old) pt-pt trails
in the SDH fabric. However, for the general pt-pt L1 trail case then what
I/Juegen said is perfectly correct.....LCAS is an exception not the rule
*and* it is because there is a new trail entity ('the LCAS group') being
created above the basic L1 server fabric. Further, although I am not
familar with the actual LCAS framing algorithm I am sure it will impose
constraints on the nature/type of add/remove L1 trails that can be used, ie
I am sure you cannot mix arbitrary L1 server trails.....so this will impose
BW granularity/route-availability constraints on the server SDH layer
networks, as defined by the LCAS algorithm.
neil
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Friday, March 23, 2001 2:38 AM
> To: Hai Vodinh
> Cc: ccamp@ops.ietf.org
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
>
>
> Neil, Hai,
>
> LCAS is developed to grow and shrink the bandwidth of a connection
> without introducing any interruption to the bit stream going over it.
> LCAS is the coordination protocol which synchronises the tail end with
> the head end.
>
> So, when a service (manager) detects that it is time to increase the
> bandwidth of the (virtual concatenated) connection, it will
> request one
> or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
> Once the trail is set-up (trail signal fail (TSF) condition clears at
> tail end), the tail end will inform the head end via the LCAS protocol
> (Member State from "fail" to "ok") that it is ready to include the new
> trail into the connection. The head end will then include the
> new trail
> into the group, increasing the bandwidth of the connection;
> before bits
> are send over the new member, the tail end is notified that
> at the next
> frame start bits are transmitted over the new member as well.
>
> I hope this illustrates that you can not use
> 'create_new->switch_to_new->delete_old' scheme in this case.
>
> Ethernet over SDH/SONET will be deploying this LCAS technique for its
> bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
> Ethernet streams. The Ethernet PHY will be terminated,
> ethernet packets
> extracted, encapsulated via GFP and mapped into virtual concatenated
> STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
> grows, the virtual concatenated signal is increased.
>
> Note 1 - same can be done ofcourse for IP/PPP packet streams.
> Note 2 - mapping in virtual concatenated STS/VT/VC signal
> with LCAS may ofcourse be performed within the
> channalized interface port of an IP Router or
> Ethernet Switch. It is not required to do this in
> the SONET/SDH transport equipment.
>
> If such virtual concatenated group of STS/VT/VC signals is diverse
> routed (half over one fiber, other half over another fiber), a signal
> fail condition in one of the two fibers will not stop transport, only
> reduce the bandwidth to 50%. The LCAS protocol will help to
> temporarily
> reduce the connection bandwidth being used to the fault free part, and
> the signal flow is restored. As soon as the failed trails are
> restored,
> the LCAS protocol will include those again (hitless) in its connection
> bandwidth, so that the full capacity can be used again.
>
> Note 3 - if the virtual concatenated group is transported over
> 3 different fibers, the failure group decreases and
> after a signal fail still 67% of the bandwidth is
> available.
>
> Recovery can be after a repair action, a protection switch
> action in the
> network's transport plane, a restoration action by the
> network's control
> plane restoring the failed trails, or a redial action of the trail
> endpoints.
>
>
>
> Regards,
>
> Maarten
>
>
> Hai Vodinh wrote:
> >
> > Neil
> >
> > The 'create_new->switch_to_new->delete_old' scheme seems to me to be
> fairly
> > inefficient mechanism for making small bandwidth change to
> large pipe.
> > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would
> have to first
> > make a sts-1-46v, switch the client signal over, then
> delete the original
> > sts-1-43v. I do agree that it is a more straight forward
> way to achieve
> the
> > goal, it is probably also simpler to keep track of the
> sts-1s also. I
> think
> > however if bandwidth modification (to existing pipe) is an important
> service
> > then we need a more efficient mechanism. I'm not saying
> that this would be
> > easy.
> >
> > My question to carriers would be: is b/w modification for virtually
> > concatenated SPE important? in the short term & long term?
> >
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Thursday, March 22, 2001 1:38 AM
> > To: Juergen.Heiles@icn.siemens.de; vishal@JasmineNetworks.com;
> > HVoDinh@turinnetworks.com; zwlin@lucent.com
> > Cc: ccamp@ops.ietf.org; GregB@ciena.com
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> > Vishal....you asked (in mail below) for operator
> input.....perhaps you
> > missed this item I posted Wed 14/03/2001 13:35 on the
> thread 'RE: Three
> > GMPLS related IDs' against this ID from Yangguang Xu
> >
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> intra-domain-0
> > 0.txt
> >
> > <prior text snipped NH>
> > 10 In section 5.4.1.5 'actions' on trails are defined.
> For a CO
> > network with fixed BW selection at trail creation time it
> is very hard to
> > see what a 'modify' action could be....other than perhaps a
> change of
> > restoration priority and/or change of dedicated back-up
> trail/resource.
> If
> > there is any notion of (working) BW change here (be it a
> scalar magnitude
> > change, ie same route, or a vector change, ie new route
> (with or without a
> > scalar magnitude change)), it would seem to me that this is
> really a new
> > pair of 'create_new->switch_to_new->delete_old' actions. I
> note however
> > that this has been marked as TBD, but I think it would help
> if it was made
> > clear that BW changes cannot (IMO) be a single 'modify' action.
> > <post text snipped NH>
> >
> > So in essence I agreed with what Juergen is saying.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> > > Sent: 22 March 2001 09:07
> > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Vishal,
> > >
> > > in the circuit switched world he connection has a fixed
> > > bandwidth. You cannot change the bandwidth. You have to tear
> > > down the connection and set-up a new one with a different
> > > bandwidth. For example if you want to change from VC-3
> > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > > released and a VC-4 connection is setup. The route could be
> > > different as some equipment migth support VC-3 but not VC-4s
> > > or vice versa.
> > > Virtual concatenation toegether with LCAS provides
> > > flexibility in certain steps. However it applies only to the
> > > end points as you mentioned. Between the end points you still
> > > setup connections with fixed bandwidth.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [SMTP:vishal@JasmineNetworks.com]
> > > > Sent: Thursday, March 22, 2001 9:36 AM
> > > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > > Hai,
> > > >
> > > > Yes, now that you mention it, it probably is an important
> > > capability.
> > > > (Although,
> > > > I am not sure how soon it needs to be made available.)
> > > > [Again, any carriers listening on this channel??
> "Hello, calling all
> > > > carriers... we need some service provider input here."]
> > <snipped to end NH>
>