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

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Huub,

>> Simple example:
>> 
>> 1) you first signal an additional VC/SPE to the destination (via a Path).
>
>[hvh] I don't see any difference with LCAS.

There is an enormous difference with LCAS: GMPLS does in addition the
signaling hop-by-hop.

We are arguing that GMPLS-LBM covers the functions of LCAS, so by definition
you can expect to have a similar behavior.

>> 2) the destination knows exactly which VC/SPE is added (via the label).
>
>[hvh] isn't this already done in step 1) ?

Yes, this is just to better explain (to emphasize something).

>> 3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
>>    so the VC/SPE is not yet added to concatenated signal.
>
>[hvh] G.806 clause 6.2.1.1: unequiped is an indication for loss of
>      connectivity. This can also be monitored at intermediate points.
>      If it should be interpreted as indicated, G.806 has to be changed
>      as well as the installed base.

I think that you are confusing the contexts. We are looking for a unequipped
to non-unequipped transition, as the first transition. When the VC starts to
transport a payload the C2 becomes non-unequipped (e.g. takes one of the
payload values defined in G.707) and then a transition back to unequipped is
not in our scope.

By the way you could instead use another transition, e.g. from a test signal
(0.181) to a data signal. The only thing is to find the best transition.
Would you prefer this one ?

Intermediate systems don't change at all. End systems are a new class of
devices supporting GMPLS, like LCAS requires new equipments.

>> 4) then, you wait at the source for a confirmation from the destination
>> (i.e. Resv).
>
>[hvh] here signals in the transport plane (C2) and control plane (Resv)
>      are mixed, imho this is worse than having it fully in the control
>      or ttransport plane.

It is completely mixed with GMPLS if you use LCAS. Anyway, the confirmation
(Resv) is a normal operation of the control plane (please see RSVP).

>> 5) the source "equip" the VC/SPE and sends.
>
>[hvh] I am missing the exact definition of when the first bit is sent.

I am missing the exact definition of the bit that you are talking about :-).
More seriously, if you speak about the first user data bit, it is obviously
in the container of the VC having made the transition.

>> 6) the destination sees in the POH that the VC is "equipped"
(transition).
>
>[hvh] where is the definition of the validation for this detection?

Like in SDH, when the Signal Label changes its value to go from state A to
state B.

>> 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
:-)
>
>[hvh] the explicit indication is required in order not to loose data
>      (similar to pointer justification process).

Like with GMPLS-LBM. Do you mean that C2 is not explicit. Tell us how and
when you loose data with a C2 transition ?

>> 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.
>
>[hvh] in regular SDH/SONET C2 is fixed

Not at all... It can change from unequipped to non unequipped, it can change
to VC-AIS, etc. You can use a test signal and then change to an ATM payload,
etc...

>> 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).
>
>[hvh] 6.3.1 describes the insertion after validation, LBM needs also to
>      describe the validation process for C2 and the exact insertion.

Yes, this is draft zero (at the IETF it means the first version that you put
on paper).

Thanks for your help,

Kind regards,

Eric