[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 think you're a network scientist! I think we need to look at
classifications of what "signalling protocol" refers to. I think from
what Maarten mentioned, it seems like he equates "signaling protocol" to
"control plane signaling protocol". There is probably a need for
differentiating between:
A protocol at the control plane
A protocol at the transport plane
A protocol at the management plane
Clearly GMPLS is a control plane protocol. And I think it's pretty clear
that LCAS is a transport plane protocol and not control plane protocol.
And if you think about it, the exchange of transport layer maintenance
signals (such as AIS, FDI, RDI, etc.) can also be considered a transport
plane signaling protocol, albeit a simple protocol.
But you're right. This is not the point.
Zhi
Mannie, Eric wrote:
> Hello Maarten,
>
>
>>I got the impression that you completely misunderstand the purpose of
>>
> LCAS. LCAS is NOT a signalling protocol.
>
> The LCAS specification defines the "LCAS protocol" (annex A), with time
> sequence diagrams (Appendix I), control packets (section 6.2) with fields,
> etc etc... if this is not a signaling protocol I am not a network scientist
> anymore. Anyway, this is not the point.
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Friday, November 16, 2001 3:36 PM
> To: ccamp; q11/15; t1x1.5
> Subject: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
>
>
> 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>
>>