[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Hi Dimitri,
OK, so maybe that's where the confusion comes in.
LCAS doesn't say what I think Eric was implying. LCAS, in G.7042, only
describes the protocol for doing this. Your quote from section 3.18 (by
the way which document is this?) also does not imply only NMS or EMS:
they are one trigger for the LCAS to start.
So I guess we do have different interpretation. Do you agree with mine?
Also, which document is it you refer to "within your document"?
Zhi
Dimitri Papadimitriou wrote:
> 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>
>>>>>>
>>>>>>
>>>>>