[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
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: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen |
| FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands |
------------------------------------------------------------------------
Always remember that you are unique... Just like everyone else.