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

[Huub Van Helvoort <[e-mail]>]

Hello Eric,
 
> >> 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.

[hvh2] first you claim there is a difference

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

[hvh2] then you claim they are similar

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

[hvh2] I still see no difference between GMPLS-LCAS and GMPLS-LBM

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

[hvh2] or create more confusion

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

[hvh2] you propose a different functionality for the use of C2 
       LCAS uses spare bits in the Virtual concatenation overhead and
       does not affect existion functionalities.

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

[hvh2] there is a clean separation: GMPLS takes care of the path setup through
       the network, LCAS manages the payload provided by the individual members
       to construct a contiguous signal.
> 
> >> 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.

[hvh2] this depeands on the validation process, see also the email from
       Grant Cyboron.
> 
> >> 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 ?

[hvh2] see my previous comment

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

[hvh2] the values you mention are not coming from the same source (VC-AIS is
       not even sent on purpose but is indirectly caused by another defect)
       these values are used for fault localisation

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

[hvh2] should remarks on a draft zero be different from remarks on a draft one?
       if yes, please tell me what kind of remarks you did expect for draft zero
> 
> Thanks for your help,

You're welcome.

Cheers, Huub
-- 
------------------------------------------------------------------------
| Huub van Helvoort    |     Lucent Technologies     | PO Box 18       |
| TEL: [phone] |     ONG Systems Engineer    | 1270 AA  Huizen |
| FAX: [phone] | mailto:[e-mail] | The Netherlands |
------------------------------------------------------------------------
   Always remember that you are unique...    Just like everyone else.