Virtual concatenation alarms
Ev Tate
Concatenation. There seem to me to be two types of faults that result
from VCAT, that don't arise for contiguously-concatenated SDH/SONET
paths.
1. Problems with the VCAT-specific signaling in an individual path,
which result in dropping that path out of the VCG. For example,
sequence number mismatch.
2. Problems reassembling a signal from constituent members, which
means that no data can be extracted from the VCG. There could be many
causes of this, such as LCAS protocol problems (group ID mismatch), or
excess differential delay, or a "path down" situation when LCAS is not
in use (if LCAS were in use, this wouldn't prevent reassmbly).
I haven't found anything in G.707 or the LCAS spec that makes it clear
how these faults should be notified. I wonder if there is some
consensus or advice on how best to handle them, or some standard I
have missed.
For the individual path issues in (1), should the notification be
associated with the path termination object, or with the VCAT
(fragmentation / adaptation) object?
For the reassembly issues in (2), is there some standard set of fault
notifications that should be used with VCAT objects?
Thanks,
Ev Tate
Bert Klaps
et...@mailinator.com (Ev Tate) wrote in message news:<95138c62.04071...@posting.google.com>...
> I am trying to implement an alarm notification mechanism for Virtual
> Concatenation. There seem to me to be two types of faults that result
> from VCAT, that don't arise for contiguously-concatenated SDH/SONET
> paths.
>
> 1. Problems with the VCAT-specific signaling in an individual path,
> which result in dropping that path out of the VCG. For example,
> sequence number mismatch.
>
> 2. Problems reassembling a signal from constituent members, which
> means that no data can be extracted from the VCG. There could be many
> causes of this, such as LCAS protocol problems (group ID mismatch), or
> excess differential delay, or a "path down" situation when LCAS is not
> in use (if LCAS were in use, this wouldn't prevent reassmbly).
>
> I haven't found anything in G.707 or the LCAS spec that makes it clear
> how these faults should be notified. I wonder if there is some
> consensus or advice on how best to handle them, or some standard I
> have missed.
You seem to have missed G.783 (02/04) on SDH equipment functions
which for the vcat functions refers back to G.806 (02/04).
The G.707 and G.7042 recommendations deal with signal structures
and protocols. For the behaviour of equipment including defect
reporting G.783 is applicable.
> For the individual path issues in (1), should the notification be
> associated with the path termination object, or with the VCAT
> (fragmentation / adaptation) object?
>
> For the reassembly issues in (2), is there some standard set of fault
> notifications that should be used with VCAT objects?
Yes, see the equipment function standards.
There is for example partial and total loss of capacity and protocol
failure at both the source and sink end.
At the sink there is also loss of multiframe, SQ mismatch, member
not deskewable, loss of alignment,...
G.806 defines which are for the vcg and which for the members.
The defect definition can also be different for LCAS enabled
or disabled...
Regards,
Bert
Ev Tate
> Hi,
> You seem to have missed G.783 (02/04) on SDH equipment functions
> which for the vcat functions refers back to G.806 (02/04).
>
> The G.707 and G.7042 recommendations deal with signal structures
> and protocols. For the behaviour of equipment including defect
> reporting G.783 is applicable.
Bert,
You're right, I did indeed miss these two (G.783 and G.806). It looks
like they should answer all my questions. Thanks for the pointer.
Ev Tate
Ev Tate
new VCAT / LCAS material is extremely helpful. Thanks again.
I have a simple followup question about fault notification to
management, i.e. alarms. Look at the sink direction (the more
interesting one for alarms). LCAS-enabled VCAT is modeled as a trail
termination function (e.g. Sn-X-L_TT_Sk) and an adaptation function
(Sn-X-L_A_Sk). The adaptation function produces alarms for specific
group faults, such as loss of alignment, total / partial loss of
capacity, LCAS protocol error, plus the member alarms. The trail
termination function produces one general alarm, server signal fail,
which means that it has no valid data to present to its client.
It appears that it's customary not to bother reporting the "secondary"
SSF alarm. That is, whether to report SSF is provisionable, and
usually set to false. So, the operator would not typically see the
SSF alarm ("the VCG is broken"), but would just see the more specific
adaptation alarm (*why* the VCG is broken). Is this right?
Ev Tate
Huub van Helvoort
You wrote:
> This was great; it's been a long time since I looked at G.806, and the
> new VCAT / LCAS material is extremely helpful. Thanks again.
>
> I have a simple followup question about fault notification to
> management, i.e. alarms. Look at the sink direction (the more
> interesting one for alarms). LCAS-enabled VCAT is modeled as a trail
> termination function (e.g. Sn-X-L_TT_Sk) and an adaptation function
> (Sn-X-L_A_Sk).
Actually the Sn-X-L_TT_Sk is the contiguous concatenated signal
trail termination and the Sn-X-L/client_A_Sk is the adaptation
function where the de-mapping of the client signal takes place.
The LCAS enabled VCAT adaptation is: Sn/Sn-X-L_A_Sk.
This is the one you refer to.
> The adaptation function produces alarms for specific
> group faults, such as loss of alignment, total / partial loss of
> capacity, LCAS protocol error, plus the member alarms.
correct.
> The trail
> termination function produces one general alarm, server signal fail,
> which means that it has no valid data to present to its client.
Indeed, and shoud be interpreted as a signal faster than the AIS
that has the same purpose: Alarm Inhibit Signal.
> It appears that it's customary not to bother reporting the "secondary"
> SSF alarm. That is, whether to report SSF is provisionable, and
> usually set to false. So, the operator would not typically see the
> SSF alarm ("the VCG is broken"), but would just see the more specific
> adaptation alarm (*why* the VCG is broken). Is this right?
Yes, SSF means Server Signal Fail, and normally the probable cause
is alarmed in the server layer itself which provides a better fault
localisation than SSF.
Regards, Huub.
--
reply to hhelvooort with 2 'o's
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...
Ev Tate
I do have another question. Take the case where (a) LCAS is NOT
active and (b) one or more members has a TSF defect. There will be an
alarm (presumably) for the member identifying its specific defect.
The VCG is broken, so the adaptation layer will pass an SSF indication
up to the termination layer. But I don't see that there is an alarm
(management indication) generated at the adaptation layer. The
sections on "defect correlation" for source and sink don't seem to
cover this case – LOA is the only apparent non-LCAS VCG alarm, and
that doesn't seem appropriate here.
Is this covered somewhere else? Or do you want to see the SSF in this
case?
Ev Tate
Huub van Helvoort
You asked:
> I do have another question. Take the case where (a) LCAS is NOT
> active and (b) one or more members has a TSF defect. There will be an
> alarm (presumably) for the member identifying its specific defect.
> The VCG is broken, so the adaptation layer will pass an SSF indication
> up to the termination layer. But I don't see that there is an alarm
> (management indication) generated at the adaptation layer. The
> sections on "defect correlation" for source and sink don't seem to
> cover this case – LOA is the only apparent non-LCAS VCG alarm, and
> that doesn't seem appropriate here.
There are also LOM and SQM but all have the restriction that
TSF shall not be present at the same time (See G.783).
> Is this covered somewhere else? Or do you want to see the SSF in this
> case?
The alarm on the specific member trail should be sufficient
for fault localisation. The alarm could of course mention that
this alarm is releated to the VCG.
Cheers, Huub.
nipp...@gmail.com
I AM WORKING ON FIBCOM MUX. I WANT TO SEE SEQUENCE MISMATCH ALARM.CAN U PLS GUIDE. I WANT TO SEE THEM IN VC12 VCG.I AM USING A DXC FOR CROSSCONNECTION,ANY LEAD WILL BE APPRECIATED.
Huub van Helvoort
You wrote:
> I AM WORKING ON FIBCOM MUX. I WANT TO SEE SEQUENCE MISMATCH ALARM.CAN
> U PLS GUIDE. I WANT TO SEE THEM IN VC12 VCG.I AM USING A DXC FOR
> CROSSCONNECTION,ANY LEAD WILL BE APPRECIATED.
VC-12(1) connected to port P in node A and port Q in node Z.
And also
VC-12(2) connected to port R in node A and port S in node Z.
Then in the DXC swap the two VC-12 such that:
VC-12(1) connected to port P in node A and port S in node Z.
And
VC-12(2) connected to port R in node A and port Q in node Z.
Make sure that TTI mismatch consequent actions are disabled.
This should raise the Seq. Mism. alarm.
Regards, Huub.
BTW: note that on usenet writing in upper case is regarded
as shouting..