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

[Stephen Trowbridge <[e-mail]>]

Eric,
Not really. This is a different "flavor" of protection where the paths are
NOT individually or collectively protected. It is assumed that for a service
where you would be increasing or decreasing the available bandwidth, you
are generally dealing with a packet oriented service where the bandwidth
provide affects the degree of congestion but not basic connectivity. As
a result, LCAS provides a way to remove failed components from the path,
even in the middle to operate (temporarily) with reduced bandwidth.
So if you had a VC-4-10v and one of the VC-4s fails, you can operate
by temporarily reducing the bandwidth to VC-4-9v until service is restored
on the other VC. When the VCs are routed independently, this provides a
very good "lightweight" protection and the ability to take advantage of
ALL of the bandwidth in the absence of failures.
Regards, Steve

"Mannie, Eric" wrote:
> 
> Hi all,
> 
> >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 ...
> 
> Not totally correct, if they are multiple LSPs used for the circuit, you can
> remove/add VCs at the end of each LSP separately. However, since each LSP is
> protected independently, if "any VC fails" inside, the whole LSP is
> protected (so in that case the problem is a not relevant). If you want to
> have completely separate VCs, you can have one LSP for each VC. Each LSP/VC
> is then provisioned end-to-end, protected (if required) and can be routed
> independently. The capability is the same as in LCAS in that case.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge
> To: David S. Miller
> Cc: Mannie, Eric; 'Dimitri Papadimitriou'; Steve West; 'Maarten Vissers';
> ccamp; q11/15; t1x1.5
> Sent: 12/11/01 1:52 AM
> Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> 
> 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>