[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
I think two small technical corrections are needed in Maarten's good example below
on the actual timing of the bandwidth change-over. I marked the corrections
with [ssg].
As for the larger issue, the current G.7042 uses the terms NMS and EMS for the
provisioning piece because an ITU-T document can not refer to standards that
are still under development. I think we have all understood that a GMPLS
control plane is equivalent to NMS/EMS provisioning for the purposes of LCAS.
The only thing LCAS requires is that the new member be assigned as part of the
virtually concatenated group before LCAS synchronizes the adding of that
member to the group. LCAS doesn't care how that assignment/provisioning took
place. I think Greg Bernstein summarized rather well.
Regards,
Steve
-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Friday, November 16, 2001 6:36 AM
To: ccamp; q11/15; t1x1.5
Subject: [T1X1.5] 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
[ssg] Of course, the member that had been using CTRL=EOS now goes to
CTRL=NORM.
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
[ssg] Strictly speaking, the bandwidth change does take place at the beginning
of the "next VC-n/ODUk frame." The LCAS messaging is carried in a control
packet that is sent over multiple VC-n/ODUk frames, and this control packet
ends with a CRC for error protection. The bandwidth change takes effect
in the first VC-n/ODUk frame after the frame carrying the end of the control
packet that signalled the changed (i.e., that contained the CTRL=EOS change.)
This allows checking the control packet CRC before making the change. Of
course, the same is true for deleting a member.
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.
>
> --------------------------------------------------------------------------------