Re: Please Clarify Doubts regarding RGT & RNC

[Maarten Vissers <mvissers@lucent.com>]

Neil,

Your observation that the VC-n-Xv LCAS trail isn't networked it self is
correct. The VC-n-Xv LCAS is to be viewed as a sublayer located between
VC-n Trail Termination functions and VC-n/Client Adaptation function.

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

The VC-n-Xv signal definition assumes one type of VC-n (e.g. n=4) being
used in a virtual concatenated group. If you would like to identify this
as a "constraint" because you want to mix e.g. VC-12, VC-3 and VC-4
signals in one virtual concatenated group, I would have to agree with
you. But, I don't view it as a constraint myself, while nobody has
requested such type mix being supported.

A state of the art VC-4-Xv LCAS implementation transporting the ethernet
packets in a 1 GbE interface signal can accomodate 16 ms of differential
delay; this is about 3000 km of fiber. So as long as the X (X<=7) VC-4
signals are routed through the network with diff delays between each two
VC-4 routes of less than 16 ms, there are no constraints. 
I.e. you may even route each VC-4 signal in the group via different
fibers/ducts and different nodes to the endpoint; e.g. VC--4 #1 is
routed via nodes B,C,D to Z, VC-4 #2 via nodes E,F to Z, VC-4 #3 via
nodes G,H,I,J,K,L to Z, etc.

The delay compensation process in node Z is adaptive, and optimises its
operation for minimum transfer delay (latency). E.g. if diff delay is in
microsecond range, then latency is in microsecond range; if diff delay
is in millisecond range, then latency is in millisecond range; etc.

As such, I can't see any real constraints at this moment, and with
technology continuously enhancing (e.g. buffer sizes) it will only be
better in future.


Regards,

Maarten

neil.2.harrison@bt.com wrote:
> 
> 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>
> >
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