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

["Mannie, Eric" <[e-mail]>]

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>