[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Hi all, from my somewhat application biased notion of LCAS and its relation
to GMPLS/G.ASON.
I thought I would get two major features from LCAS:
(1) Hitless (for packet data services) changes in bandwidth by coordinating
between the end systems the exact time (virtual frame) when the new
component comes on line. (or old component stops being used). I've kinda
viewed LCAS as a path layer service (this may not be theoretically correct)
but I've got to use some mechanism to set up need component paths, then use
LCAS to bring them into use without say loosing an Ethernet or IP packet in
the process. Similarly on reduction in bandwidth, LCAS allows me to
hitlessly take a component out of service. Then I use some other process two
actually remove the component path from the network and free up the network
resources.
(2) Graceful degradation in the presence of failure (especially with
diversely routed components).
Here LCAS is use by the end systems (virtual concatenation capable systems)
to coordinate which components are still functional and coordinate there use
after a failure.
Eric, Maarten? I really thought LCAS and GMPLS/G.ASON like connection
establishment were quite complementary with no real overlap, e.g., I'd still
might want bandwidth modify at the GMPLS level so I don't have to keep track
of all the components individually (application 1.) and this is somewhat
different than what you'd want to do for application (2).
Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Technology Director, Ciena Corporation
-----Original Message-----
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: Friday, November 16, 2001 9:39 AM
To: 'Maarten Vissers'
Cc: ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
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 ?
>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.
GMPLS plays a role for all the cases that you described: to setup a
connection, to maintain a connection, to modify a connection, to release a
connection, etc.
LCAS makes a lot of sense for a static network where provisioning occurs
through a Network Management System.
A distributed control plane (like GMPLS) with LCAS doesn't make any sense.
LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the
beginning to allow LSP (bandwidth) modification.
Do you mean that your implementation of GMPLS will not support any
bandwidth/LSP modification ?
Kind regards,
Eric
-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Friday, November 16, 2001 5:30 PM
To: Dimitri Papadimitriou
Cc: ccamp; q11/15; t1x1.5
Subject: 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>