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

[Stephen Trowbridge <[e-mail]>]

David,
Virtual Concatenation, with or without LCAS accomodates differential
delay for different parts of the payload.

LCAS provides hitless add/remove. Also it provides for removal of
failed components, even when this results in non-contiguous
component numbering.

LBM does not give you hitless add and remove from the payload.
LBM also does not accomodate removal of non-contiguous components:
e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need
to back down to 2 and then build up ...
Steve

"David S. Miller" wrote:
> 
> Am I missing something?
> 
> I thought that LCAS gains 2 things:
> 1) Hitless and and remove of payload (dynamic bandwidth allocation)
> but more importantly
> 2) Differential Delay through the network for differents parts of the
> payload (i.e. diverse routing of network traffic).
> 
> How does GMPLS w/ LBM address the second issue?
> 
> David Miller
> Vitesse Semiconductor
> 
> "Mannie, Eric" wrote:
> >
> > Hello Steve,
> >
> > Just to complement the answer of Dimitri,
> >
> > > You believe that the packet loss rate and robustness of LMB is
> > > similar to LCAS ?
> >
> > LCAS waits for the end of control packet which is multi-framed to decide
> > when the payload is significant (the "transition"). LBM uses for instance
> > the C2 byte for the HOVC, since this byte appears directly in the POH and is
> > not part of a control packet, that should go faster, right ? I.e. less
> > glitch than with LCAS ?
> >
> > But having a field in the transport plane to indicate a transition (whatever
> > is the field ) is not the most important issue. Even if you have that field,
> > you need some time to provision the additional VCs/SPEs in the network. This
> > is not done by LCAS, and any control plane or management plane will imply
> > some time for that operation, and the glitch will really come from that
> > process, not from the way that you detect a transition in the transport
> > plane.
> >
> > > 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 ?
> >
> > When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS
> > implies issues on this control plane. LCAS is a stand-alone solution that
> > bypass the control plane to change the resource reservation in both end
> > systems. A control plane maintains states in end systems (e.g. at the UNI)
> > and in intermediate systems ! So, bandwidth modifications must be reflected
> > in the control plane otherwise it will become inconsistent.
> >
> > Now, the control plane is natively designed to deal with these resource
> > reservations including in the source and the destination (with the UNI).
> > Moreover, GMPLS is natively designed to deal with bandwidth modification (in
> > the packet world this was one of the major requirements). Originally, we
> > just wanted to describe how to generalize these bandwidth modification
> > principles to SDH/SONET and how to interwork with LCAS.
> >
> > Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all
> > the protocol part. The rest was the issue about when to decide that a VC/SPE
> > contains real user data or not (the transition).
> >
> > Since LCAS added a control message, naturally it used a field in that
> > control message to indicate that transition. But with GMPLS we didn't need
> > any new control message, se we looked at what was available *in the
> > transport plane* to detect the fact that a VC/SPE contains now real user
> > data (i.e the transition). We found natural to use the so-called SDH/SONET
> > "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with
> > the GMPLS label :-). So we added these aspects to the draft. This is the
> > part that we expected to validate with the ITU-T/T1X1 folks, but flames came
> > first...
> >
> > What we are certainly going to do, is to add in the draft a section about
> > how GMPLS should work when LCAS is used at the same time. However, we think
> > that using GMPLS and LCAS at the same time will be more complex than simply
> > using GMPLS and will not bring something additional. So the natural
> > observation came, "why should we use LCAS with GMPLS and build something
> > more complex when there is almost no issue to solve when simply using GMPLS
> > alone". Using GMPLS and LCAS at the same time to modify the bandwidth
> > implies that we will have two signaling flows between the source and the
> > destination running in parallel and overlapping. GMPLS will also speak with
> > the source and the destination to do the same as LCAS, and with a
> > distributed control plane you need GMPLS anyway (or PNNI or etc).
> >
> > We also added a section to explain how several GMPLS LSPs (i.e. circuits)
> > can be combined together to form a larger virtually concatenated circuit.
> > This allows to deal with the non co-routing of VCs/SPEs with GMPLS.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Dimitri Papadimitriou [mailto:[e-mail]]
> > Sent: Sunday, November 18, 2001 3:44 PM
> > 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>