[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Hi,
We had presented couple of contributions at the previous T1X1 to address
some limitations of LCAS. We had proposed a lightweight LCAS protocol that
doesn't require A-end and Z-end handshake and doesn't assume a provisioning
event before each bandwidth update event.
As Maarten correctly points out LCAS as currently defined is not a
signalling protocol, but enables a hitless bandwidth change.
There are couple of documents attached - justification.doc and proposal.doc.
Pls feel free to comment on the justification document and the actual
proposal document. The actual proposal document is a work in progress. The
justification document presents examples of scenarios where "dynamic"
real-time changes of bandwidths may be required and how a lightweight LCAS
may be used to solve it.
regards,
Krishna
-----Original Message-----
From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
Sent: Friday, November 16, 2001 10:28 AM
To: Maarten Vissers
Cc: ccamp; q11/15; t1x1.5
Subject: [T1X1.5] 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.
> >
> >
----------------------------------------------------------------------------
----