[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Greg,
Thanks for this summary. I like it.
ASON/GMPLS like connection establishment and LCAS are in my view indeed
complementary, like NMS like connection establishment and LCAS.
Regards,
Maarten
"Bernstein, Greg" wrote:
>
> 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>
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