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

[Steve West <[e-mail]>]

Dimitri:

Thank you for your clarification.  These are my observations:

1.  Truelly hitless capacity adjustment requires bit-interval accurate
indication to the payload mapper as to when to begin/stop
inserting/extracting payload to/from a VC group member.

2.  Both LBM and LCAS propose that this indication be provided by
information in the member Path Overhead.   

3.  In HOVC virtual concatenation systems, H4 is already used by the payload
mappers on the two ends of the link to coordinate sequence numbers.
Coordinating and synchronizing member additions and deletions involves in
part, control of these sequence numbers.  Extending H4 to control member
additions and deletions is therefore consistent with the sequence number
function of the H4 octet.  

4.  On the other-hand C2 is already used to provide payload type
information.  Extending the application of C2 is complicated by the
established (formal and de-facto) practise for its use.

5.  The state machine/protocol specifications for LCAS, also supports
resilient management of the virtual concatenated group.  H4 functionality
extensions support sequence number reassignment through member exclusions
and inclusions required to respond to member path failure and recovery.
LCAS requirements can and will be economically implemented as state-machine
hardware additions to the Virtual Concatenation Packet Mapper.  

6.  LCAS may be considered an extension to virtual concatenation.  It
potentially supports provisioning/signaling by  a number of alternative
management plane / control plane architectures (potentially including
GMPLS).

I would suggest that GMPLS-LBM spec be revised to support and take full
advantage of the benefits of LCAS.  It would be a shame to spoil the
GMPLS/LBM proposal by leaving such an important capability out. 

Kind Regards,

Steve


-----Original Message-----
From: Dimitri Papadimitriou [mailto:[e-mail]]
Sent: Sunday, November 18, 2001 6:44 AM
To: Steve West
Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp;
q11/15; t1x1.5
Subject: Re: [T1X1.5] Re: LCAS and
draft-mannie-ccamp-gmpls-lbm-tdm-00.txt


Hi Steve,

Thanks for your comments, see in-line...

Steve West wrote:
> 
> 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 ?

It is mentioned in the proposal that the source waits for a 
confirmation from the destination (i.e. Resv Message). THEN 
the source "equip" the VC/SPE and sends. After the destination 
sees in the POH that the VC is "equipped" (transition).

So instead of using the transitions proposed in LCAS (based 
on the H4 CTRL words) we use the ones already available.

Since we are the beginning, we were very cautious but we expect to 
reach more than reasonable robustness and reliability.

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

At the transport plane level C2 is the field that LBM uses for the 
transition in the HOVC POH.
 
> 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 ?

See above, yes and yes (since we re-use existing VC mechanisms)
 
> 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 ?

The scope of this proposal is to use GMPLS-LBM without LCAS. In fact 
(from what i understand in your question) see it more from transport 
to control plane impact taking the assumption that you expect some 
hardware improvement. Let's first determine if this can be achieved 
and then discuss the implementation issues that can arise from this 
proposal. In a sense, GMPLS-LBM is a self-consistent solution.

Regards,
- dimitri.
 
> Thanks,
> 
> Steve
> 
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:[e-mail]]
> 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:[e-mail]]
> > 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>