[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
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>
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard