[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Dimitri,
LCAS is a different step in the process from LBM. If you want to
grow the capacity of the link, you need to perform more than one
step:
1. The additional capacity needs to be set up. e.g., if you have
6 VC-4s in a VC-4-6v and want to add VC-4 #7, you need to set up
the 7th VC-4 between the endpoints. If this 7th VC-4 is set up
using a BW modification request, the control plane will know that
the LSP for this new VC-4 is part of the same circuit as the LSP(s)
for the first 6 VC-4s.
2. The payload mapping at the two ends has to be changed to
utilize the additional capacity. If you want to do this hitlessly,
you use LCAS.
LBM and LCAS serve (related, but) different purposes. They are
complementary rather than being alternative choices. As a result,
I do not like the title of clause 3: "GMPLS LBM versus LCAS".
Can you use LBM without LCAS? Yes, if you don't mind a glitch to
the traffic.
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.
Can you use LCAS WITH LBM? Hopefully yes, and this would seem to
be the preferred method for many applications.
Regards,
Steve
Dimitri Papadimitriou wrote:
>
> Maarten,
>
> I think you have reach the main comparison point for this discussion
> Let's start with this:
>
> - If you want to achieve hitles adaption you need a real-time protocol
> to synchronize both ends in some way (supporting the for instance LCAS)
> this is a synchronous approach
>
> - If you just want to add more capacity and you don't focus on a
> 'glitch'
> perhaps very few millisecs when putting the capacity in use you can do
> it in
> a non-real time manner like with GMPLS - this is an asynchronous
> approach
>
> The major difference between both procedures is that GMPLS gives an
> answer
> how to allocate capacity across the network while LCAS relies on the
> fact
> that it is already available i.e. "provisioned" (see LCAS specification)
> for use and just has to be 'lit'.
>
> Hope this will help the reader to undertstand that both methods have a
> specific applicability scope, the GMPLS one is more adapted for dynamic
> environments that do not use "provisioning" of the resources ... a real
> bandwidth on demand service. I think this is what we have addressed
> with this. And from what i understood this is what carriers are looking
> for (since the bandwdith service is non-disruptive - if it can
> accomodate
> a very few ms -, flexible and doesn't require any pre-provisioning).
>
> The second (LCAS) is adapted for services that could be sensitive, but
> the price to pay is to provision the "resources". This is a static
> approach of the problem. I think that both have a specific scope.
>
> Regards,
> - dimitri.
>
> Maarten Vissers wrote:
> >
> > Eric, Dimitri,
> >
> > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so
> > I got the impression that you completely misunderstand the purpose of LCAS. LCAS
> > is NOT a signalling protocol. It is totally unrelated as such to control plane
> > based connection management (GMPLS, ASON) or network management based connection
> > management.
> >
> > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N
> > trails are set up between the A-end and Z-end, LCAS helps to hitless change the
> > number of trails being used for the actual transport of the client signal; i.e.
> > if X (X<N) trails are being used, and the operator/user wants to increase this
> > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end
> > and Z-end to make sure the increase/reduction is performed hitless.
> >
> > The steps to perform for the case X=N are:
> > A) X ==> X+1
> > 1) [Operator or User] request connection management [NMS or ASON/GMPLS]
> > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with
> > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end
> > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at
> > A-end and Z-end to control the "addition" of the (X+1)th trail to the
> > group of X trails ("Madd" command in G.7042) over which the client
> > bitstream is transported
> > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this
> > to the receiver at the other end
> > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection
> > in one direction is setup if the Trail Signal Fail (TSF) condition at
> > its end has cleared;
> > 4) LCAS communicates the TSF clearing to the other end ("MST=OK")
> > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and
> > 6) at the start of the next VC-n/ODUk frame the client bitstream is
> > distributed over X+1 (instead of X) VC-n/ODUk trails
> > 7) the receiver at the other end notices the change of CTRL=ADD to
> > CTRL=EOS, and expects the client signal to be present on X+1 (instead
> > of X) VC-n/ODUk trails at the begin of the next frame.
> >
> > Example with X=3
> > ================
> >
> > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over
> > trails #1..#3 as follows:
> > trail#1 trail#2 trail#3
> > ...
> > 1-8 9-16 17-24
> > 25-32 33-40 41-48
> > 49-56 57-64 65-72
> > 73-80 ...
> >
> > When trail #4 is added, no client bits will be transported over it, until the
> > source has indicated this via the change of the control word CTRL=ADD =>
> > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits
> > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at
> > the moment client bit 49 is to be transmitted, then trail#4 will be used for the
> > transport of bits 73-80 and further:
> >
> > trail#1 trail#2 trail#3 trail#4
> > ...
> > 1-8 9-16 17-24
> > 25-32 33-40 41-48
> > 49-56 57-64 65-72 73-80
> > 81-88 89-96 97-104 105-112
> > 113-120 ...
> >
> > Regards,
> >
> > Maarten
> >
> > Internet-Drafts@ietf.org wrote:
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > >
> > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM
> > > Networks
> > > Author(s) : E. Mannie, D. Papadimitriou
> > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > > Pages : 13
> > > Date : 15-Nov-01
> > >
> > > This document defines how GMPLS can be used to dynamically modify
> > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and
> > > will cover G.709 in a next version.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> > >
> > > To remove yourself from the IETF Announcement list, send a message to
> > > ietf-announce-request with the word unsubscribe in the body of the message.
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-mannie-ccamp-gmpls-lbm-tdm-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > mailserv@ietf.org.
> > > In the body type:
> > > "FILE /internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility. To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command. To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader. Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> > > --------------------------------------------------------------------------------
> > > Content-Type: text/plain
> > > Content-ID: <20011115154112.I-D@ietf.org>