[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please Clarify Doubts regarding RGT & RNC
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
-----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>