Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

[Maarten Vissers <mvissers@lucent.com>]

Eric,

LCAS is added to the networks to resize the pipe over which e.g. Ethernet
packets flow in a hitless manner. The A and Z endpoints need therefore to be
synchronised at frame level. There is no alternative in the control plane which
can support this.

Looking at your simple example, I get the impression that you do not fully
understand the use of the UNEQ value in C2/V5. The UNEQ value in C2/V5 is
generated by the HOVC/LOVC connection function (see G.783) as part of the UNEQ
VC-n signal generation process. The UNEQ value is not generated by the path
termination function or its associated adaptation function. An adaptation
function alsways generates an equipped-specific signal label (>= 2).

So, as soon as the fabrics in the to be setup connection have setup their matrix
connections, the VC-n path termination function will receive an
equipped-specific signal label value, and consequently clears its UNEQ defect.

I.e. the assumptions underlying your steps 2 to 6 are incorrect and not aligned
with the SDH specifications in ITU-T.

Regards,

Maarten



"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>
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:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard