[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Zhi,
I read here the fourth sentence of the Annex:
"The scheme allows hit-less addition and removal of
bandwidth under control of a management system."
Then in the LCAS document Section 3.18
"The LCAS assumes that in cases of capacity initiation,
increases or decreases, the construction or destruction
of the end-to-end path is the responsibility of the
Network and Element Management Systems."
So i think these sentences are clear within your documents
- i am not responsible for this - you are the author not
me or probably we have different interpretations of NMS
systems.
- dimitri.
Zhi-Wei Lin wrote:
>
> Hi Eric,
>
> I would like to understand your statement:
>
> "LCAS makes a lot of sense for a static network where provisioning
> occurs through a Network Management System."
>
> Is this your view of LCAS, that it is strictly limited to a static
> network & that it is triggered only by NMS?
>
> Zhi
>
> Mannie, Eric wrote:
>
> > 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>
> >>>>
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