[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
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>
>>>>