[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS/VCAT
Hi Evelyne, sorry for the delay but Richard Rabbat had been taking the
lead on this draft for most of last year.
See comments on your comments.
Regards
Greg B.
Evelyne Roch wrote:
I read the draft and have the following comments:
1- The draft is missing support for creation and deletion of VCG with
diversely routed signals without LCAS. This is because the procedure
that is used to setup the components does not provide information about
the VCAT layer, i.e. it is missing the total number of components that
are part of the same VCG.
Yes. Both ends need to agree on which components are to be used in the
group at any given time. This requires extra signaling concerning
the structure of the VCAT group. There are a number of ways this could
be done.
In a liaison from ITU-T SG15, Q14/15
https://datatracker.ietf.org/documents/LIAISON/file394.doc, the 2nd
figure of Attachment 2 shows a multi-layer setup of an Ethernet call
over VCAT/LCAS. Although the Ethernet layer is not relevant to the
draft, it should be noted that a portion of the diagram includes an
Aggregate NCC (Network Call Controller) that provides the missing
functionality in the draft to provide the number of components that form
the VCG. This is based on G.8080, in which the VCAT layer has its own
controller. The functions performed by the Aggregate NCC are required
whether or not LCAS is available. They allow both ends of the VCG to
know the overall status of the VCG and the number of components it
contains. It should also be noted that the call and connection states
for each constituent must be kept separately from the state of the VCAT
call.
From an implementation perspective an entity such as the mentioned
Aggregate NCC that "manages the VCGs" is a given. I've got to manage the
settings of that VCAT/LCAS chip at some point (and related logical
entities). Similarly for each cross connect involved. I'm not up to
date on all the call/connection state discussions so I won't comment (yet).
2- The draft is missing support for the creation of the various
components in a separate phase than the creation of the VCAT group. In
general, it should be possible to create, for example, several VC-4
connections and to add them to a VCG at a later point to create, for
example, a VC-4-4v. This can only be achieved if an Aggregate NCC
exists.
Here you are talking about (I think) a nifty application that we had in
an earlier version of the draft. In this case, a number of pipes are set
up between the endpoints far in advanced and could be shared between
multiple VCAT groups. For example a number of GbE customers connect to
an access box that supports VCAT on its line side and the pre-configured
(setup) component signals would be allocated between the VCAT groups
without additional signal setup and tear down across the network. Is
this of interest to folks? Is the saving of the call setup and tear down
that significant?
3- I would prefer to use the call ID to correlate the diversely routed
signals instead of the Association Object. In my opinion, the call id is
a better choice because it is better aligned with the ASON architecture
(G.8080).
Regards,
Evelyne Roch
Metro Ethernet Networks, Nortel
Phone: +1 613 763 6492 (esn 393-6492)
e-mail: eroch@nortel.com
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Thursday, November 30, 2006 6:57 AM
To: ccamp@ops.ietf.org
Subject: LCAS/VCAT
Hi,
In San Diego Richard presented the current status of
draft-ietf-ccamp-gmpls-vcat-lcas-01.txt and suggested that the work is
nearing completion.
A quick show of hands indicated that very few had read the draft. This
may be because it is a very narrow niche that only a few are interested
in (i.e., all of the key people have read it), or may be because more
people need to have a look.
If you are interested in this work, could you please find some time
relatively soon to have a look at the draft and send your comments to
the list.
If you have or are planning an implementation could you drop me a
private
(confidential!) email.
Thanks,
Adrian
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237