[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Dimitri,
Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of
understanding of LCAS's objective (my very strong opinion). LCAS plays a role
after the extra connection is setup or before a connection is released. How this
connection is setup or released is not relevant for LCAS.
NMS and ASON/GMPLS are concerned with connection setup and release. And also
with modification, if such is relevant for a connection.
Modification of connection parameters is relevant for the connection (group(s))
supporting the transport of a Virtual Concatenated signal (VC-n-Xv, ODUk-Xv).
If this modification isn't covered yet in GMPLS drafts, it is important to
extend GMPLS and add it. But never ever relate it to LCAS :-).
When we developed virtual concatenation and LCAS we where very much aware that
we would get much more out of these two when there would be a switched network.
The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) could
then monitor the fill level of the virtual concatenated pipe, and when crossing
a threshold could request another VC-n or ODUk to be setup. In a switched
network the setup only takes a few seconds, and essentially in no time the
bandwidth of the pipe can be increased.
If LCAS is present, this new capacity can be included in the transmission of the
ehternet bit stream without introducing any errors in the ehternet stream.
If LCAS is not present, the ethernet transport will be interrupted for a shorter
or longer period and (depending on the bandwidth of the pipe) fewer or many more
packets will be lost before the transmission is restored. I.e. as long as the
transmitter is using X+1 trails and the receiver is using X trails (or vice
versa) transmission is interrupted. With NMS ordering the increase at A-end and
Z-end (after the additional trail is setup) this period may be a couple of
seconds; i.e. NMS has to generate two messages to the A node and the Z node,
these messages have to travel through the DCN, the two nodes have to accept the
messages and process those before the command can be given to the hardware to
use X+1 instead of X trails.
When a control plane is involved instead of NMS, the control plane has to set up
the additional trail, verify that this trail is set up correctly (check for
signal fail including trace identifier), then command one end to transmit over
X+1 trails and quickly inform the other end that it should command the receiving
endpoint to read from X+1 trails. This all might be in the 100ms range but most
likely will also be in the seconds range (depending on network size and load).
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
You always need NMS or ASON/GMPLS to be present to setup the additional
connection. If an endpoint doesn't support LCAS, its function needs to be
performed by NMS or ASON/GMPLS (with degraded performance).
>
> The major difference between both procedures is that GMPLS gives an
There is no difference, as the two can not be compared.
> 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
Methods are LCAS and non-LCAS...
> specific applicability scope, the GMPLS one is more adapted for dynamic
> environments that do not use "provisioning" of the resources ...
In either case there is "provisioning" of the resources. The hardware in both
endpoints must be told to use X+1 instead of X trails.
> 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).
There is a large difference between "zero errors" and "a few ms (most likely
seconds) of no transmission".
>
> 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.
I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS
provisioning is non-time critical, whereas the non-LCAS provisioning is time
critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not mandatory,
the investments in NMS and ASON/GMPLS to limit the traffic interruption have to
be made. As such, your draft should focus on the means to limit the traffic
interruption when LCAS is not present. This may imply kind of third party
signalling information to be carried through the public switched transport
network; i.e. for the case the virtual concatenated endpoints are outside of the
PSTN, the user needs to have the capability to synchronize its endpoints.
Regards,
Maarten
>
> 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:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard