RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

[Steve West <Swest@turinnetworks.com>]

Dimitri:

Please confirm my understanding of your proposal:

1.  Your proposal supports hitless link capacity adjustment. (Capacity
changes that occurs during transmission of a packet will not corrupt that
packet.)  You believe that the packet loss rate and robustness of LMB is
similar to LCAS ?

2.  LMB requires hardware coordination between the SONET payload mapper and
the SONET POH processor (C2 octet insertion/extraction logic) ?  

3.  The hardware based synchronization performance requirements are similar
to those required by LCAS.  Except that LCAS coordinates the critical
transitions using H4 instead of C2 ?  And that Virtual Concatenation systems
require to coordinate their payload mappers with bits 1-4 of the H4 byte to
determine the sequence number anyway ?  

4.  LBM is an extension to GMPLS.  GMPLS is required for LBM, whereas LCAS
could potentially be used with GMPLS or with other control plane or
management plane mechanisms ? 

Thanks,

Steve  

-----Original Message-----
From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
Sent: Friday, November 16, 2001 4:09 PM
To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'
Cc: ccamp; q11/15; t1x1.5
Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt


Hi folks,

What happens... when we start the technical discussion
all guys taking part to the previous one now are gone ?

We would like to start a technical discussion.. rather 
difficult if we stay alone... or everybody agree on
proposal made in the previous e-mail ? (this in order
to refine the mechanism detailed in the GMPLS LBM I-D.)

Any technical feedback is highly appreciated. 

Cheers,
- dimitri.

"Mannie, Eric" wrote:
> 
> Hello Stephen
> 
> > GMPLS-LBM and LCAS ARE solutions to different problems.
> 
> No, please see explanations below.
> 
> > If you use LBM and change the mappings at the two ends without some
> coordination such as LCAS, you will have a glitch to the traffic
> (I think this is simple enough).
> 
> No, please see below (C2 or V5 transition).
> 
> >The compare/contrast discussion of LBM and LCAS is appropriate not
> >because LCAS is "sacred", but because you are comparing apples to
> >oranges. Statements in this document such as "One drawback of LCAS is .."
> >are unnecessary and inappropriate in this context, since LBM does
> >NOT solve the problem LCAS was designed to solve. Perhaps if you
> >were solving the SAME problem better, this would be OK, but this
> >is not the case.
> 
> No, please see below.
> 
> Simple example:
> 
> 1) you first signal an additional VC/SPE to the destination (via a Path).
> 2) the destination knows exactly which VC/SPE is added (via the label).
> 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
>    so the VC/SPE is not yet added to concatenated signal.
> 4) then, you wait at the source for a confirmation from the destination
> (i.e. Resv).
> 5) the source "equip" the VC/SPE and sends.
> 6) the destination sees in the POH that the VC is "equipped" (transition).
> 
> The difference between LCAS and LBM is that LCAS uses an additional
explicit
> indication in the overhead to say "this is the payload" to use. LBM
doesn't
> change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead
:-)
> 
> LCAS uses a new field in the POH (CTRL) to know when the new VC
transitions
> to a significant payload. LBM proposes to do the same simply by looking at
> the C2 (for HOVC) transition - regular SDH/SONET field that will change
> anyway and that is used to indicate the type of payload.
> 
> To be more precise about LCAS (I copy from the LCAS specification, section
> 6.3.1): "The first container frame to contain payload data for the new
> member shall be the container frame immediately following the container
> frame that contained the last bit(s) (i.e. the CRC) of the control packet
> with NORM/EOS message for that member" (the LCAS control packet).
> 
> So, LCAS waits for the last bit of the appropriate LCAS control packet in
> the POH with the appropriate transition of its CTRL field. LBM waits
simply
> for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH
> (don't change SDH/SONET).
> 
> By the way, this is version 0 of the draft and it was just posted.
> 
> Suggestions, technical comments and improvements are welcome.
> 
> I would appreciate if people could first read and speak before shooting
> directly :-)
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Friday, November 16, 2001 7:49 PM
> To: Mannie, Eric
> Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
> Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> 
> Eric,
> The point of my earlier email (items again below, this time with
> numbers) was not to prompt the comment "#3 is out of scope, therefore
> it is a choice between #1 and #2" (my parsing of recent statements).
> 
> The issue (and I think the reason for Maarten's strong reaction) is this:
> GMPLS-LBM and LCAS are NOT different solutions to the same problem.
> GMPLS-LBM and LCAS ARE solutions to different problems.
> (I hope this is not too subtle for non-native English speakers).
> 
> LCAS is a method to hitlessly change the mappings at the two
> ends of a virtually concatenated trail to increase or decrease the
> bandwidth. It does not say anything about how components to be
> added or removed from the virtually concatenated "bundle" are
> set up or taken down.
> 
> LBM talks about how to set up or take down those added or removed
> components, but not about the details of changing the mapping (other
> than that it is done after the new components are successfully
> established.
> 
> If you use LBM and change the mappings at the two ends without some
> coordination such as LCAS, you will have a glitch to the traffic
> (I think this is simple enough).
> 
> The compare/contrast discussion of LBM and LCAS is appropriate not
> because LCAS is "sacred", but because you are comparing apples to
> oranges. Statements in this document such as "One drawback of LCAS is .."
> are unnecessary and inappropriate in this context, since LBM does
> NOT solve the problem LCAS was designed to solve. Perhaps if you
> were solving the SAME problem better, this would be OK, but this
> is not the case.
> 
> Time to try to be constructive:
> - I think most of the current discussion of LCAS should be removed from
> this document. It is irrelevant since LCAS solves a different problem than
> LBM. To say that one is "better" than the other would only be meaningful
> if they were solving the same problem (can you really say that LBM solves
> problem A better than LCAS solves problem B?).
> - LCAS can be a good informative reference as a way to hitlessly modify
> the size of a virtually concatenated trail.
> - Clarify in the scope that the current draft describes the use of LBM
> without LCAS, which results in a traffic glitch when bandwidth is
modified.
> Indicate that the use of LCAS to hitlessly negotiate the changes to
> the size of virtually concatenated pipes after LBM sets up new
component(s)
> or before LBM takes down old component(s) is a topic for further study
> and perhaps to be addressed in a future version of the draft.
> 
> Regards,
> Steve
> 
> Steve Trowbridge wrote:
> > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to
> > the traffic.
> >
> > 2. Can you use LCAS without LBM? Yes, if you don't care whether the
> > control plane knows that the different LSPs are part of the same
> > circuit.
> >
> > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to
> > be the preferred method for many applications.
> 
> "Mannie, Eric" wrote:
> >
> > Hello Maarten,
> >
> > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of
> > >understanding of LCAS's objective (my very strong opinion).
> >
> > Sorry, do you mean that it is forbidden to speak about your LCAS
document
> > and to compare GMPLS and LCAS functionalities ?
> >
> <snip, to save BW>