Subject: [mpls-tp] draft-ietf-mpls-tp-oam-framework-05#section-5.3

From: [email-masked]
Date: Tue, 9 Mar 2010 19:56:57 +0800

Hi editors and all,

I have one question on the Alarm Reporting in section 5.3 of 
"draft-ietf-mpls-tp-oam-framework-05".

since AIS messages are issued  by the client layer adaptation function, in 
a layer network, e.g, MPLS-TP network, there may be many adaption 
functions in every layer.

and this kind of propogation may cost a long time to reach a MEP of the 
outerest client path.

based on the former discriptions, there may be such a possible situation 
shown below:

 given the figure 3 in draft-ietf-mpls-tp-oam-framework-05 and a fault is 
defected by a MEP on Sec12,  the MEP of MS-PW1Z in LSR Z may receive a AIS 
message after it has reported a dLOC defect alarm, and also may has 
switched to a backup PW or has implemented other processes.

will this situation happen?

BR.

Xuehui

Best Regards.
===========================================
祝您新春愉快，工作顺利，身体健康，阖家欢乐！

---

From: David Allan I <[email-masked]>
Date: Tue, 9 Mar 2010 11:22:04 -0500

Hi Dai:

To clarify your question, are you are suggesting AIS may not reach a MEP prior to CC/CV in the given sub-layer timing out? Primarily due to stacking of sub-layers imposing a S/W propagation delay.

If so that is a possibility. It could be accomodated by a hold off in issuing an alarm to give alarm management to take effect. Alternately the alarm could be asserted, and de-asserted shortly afterwards. Certainly faster than human intervention time...

It is also possible that a protection switch may occur before AIS ripples upwards, and if the higher layers CV rates are slower than the failed layer, AIS will eventually reach the top layer MIP but the loss of connectivity associated with the AIS will not be detected before the connectivity is restored. Eventually the layer detection time will likely be slower than the AIS propagation time....All that will happen is for a brief period of time, alarms were suppressed, but no other action taken...

IF I have understood your query correctly, I do not think there is a problem

cheers
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 09, 2010 6:57 AM
To: [email-masked]; Annamaria Fulignoli; [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] draft-ietf-mpls-tp-oam-framework-05#section-5.3

Hi editors and all,

I have one question on the Alarm Reporting in section 5.3 of "draft-ietf-mpls-tp-oam-framework-05".

since AIS messages are issued  by the client layer adaptation function, in a layer network, e.g, MPLS-TP network, there may be many adaption functions in every layer.

and this kind of propogation may cost a long time to reach a MEP of the outerest client path.

based on the former discriptions, there may be such a possible situation shown below:

 given the figure 3 in draft-ietf-mpls-tp-oam-framework-05 and a fault is defected by a MEP on Sec12,  the MEP of MS-PW1Z in LSR Z may receive a AIS message after it has reported a dLOC defect alarm, and also may has switched to a backup PW or has implemented other processes.

BR.

Xuehui

Best Regards.

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 09 Mar 2010 18:01:09 +0100

Hello Dave and Dai,

See my comments in-line [hvh]

> To clarify your question, are you are suggesting AIS may not reach a MEP 
> prior to CC/CV in the given sub-layer timing out? Primarily due to 
> stacking of sub-layers imposing a S/W propagation delay.

[hvh] Please note that CC/CV is used for actions in the dataplane,
AIS is for actions towards the management plane, they should
be independent.

> If so that is a possibility. It could be accomodated by a hold off in 
> issuing an alarm to give alarm management to take effect. Alternately 
> the alarm could be asserted, and de-asserted shortly afterwards. 
> Certainly faster than human intervention time...

[hvh] in transport networks alarm reporting is filtered, normally
2.5 seconds (+/- 0.5) for raising alarms and 10 seconds (+/- 0.5)
for clearing alarms.
This hysteresis avoids intermittent alarms to appear on the GUI.

> It is also possible that a protection switch may occur before AIS 
> ripples upwards, and if the higher layers CV rates are slower than the 
> failed layer, 

[hvh] protection switching should be based on CC/CV defects
and *not* based on AIS.

> AIS will eventually reach the top layer MIP but the loss 
> of connectivity associated with the AIS will not be detected before the 
> connectivity is restored. 

[hvh] this should be: AIS is associated with Loss of Connectivity (LoC).
The LoC will exist until the fault is repaired, it will continue to be
reported by the MEP that detects it.
MEPs in client layers will not report LoC because AIS will prevent that.
If the LoC is detected on a protected entity the AIS that is inserted
as a consequent action will not appear in the client layer because
the protection switch is located after the insertion point.

> Eventually the layer detection time will 
> likely be slower than the AIS propagation time....All that will happen 
> is for a brief period of time, alarms were suppressed, but no other 
> action taken...

[hvh] as mentioned above this will not happen due to the 2.5 sec.
filtering.

> IF I have understood your query correctly, I do not think there is a problem

[hvh] I agree.

regards, Huub.

> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of [email-masked]
> *Sent:* Tuesday, March 09, 2010 6:57 AM
> *To:* [email-masked]; Annamaria Fulignoli; 
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* [mpls-tp] draft-ietf-mpls-tp-oam-framework-05#section-5.3
> 
> 
> Hi editors and all,
> 
> since AIS messages are issued  by the client layer adaptation function, 
> in a layer network, e.g, MPLS-TP network, there may be many adaption 
>  given the figure 3 in draft-ietf-mpls-tp-oam-framework-05 and a fault 
> is defected by a MEP on Sec12,  the MEP of MS-PW1Z in LSR Z may receive 
> a AIS message after it has reported a dLOC defect alarm, and also may 
> has switched to a backup PW or has implemented other processes.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

-- 
================================================================
                  http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 10 Mar 2010 08:53:57 +0100

The fault management processing consists of a number of steps (refer to
G.806
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.806-200901-I!!PDF-E
&type=items and G.7710
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.7710-200707-I!!PDF-
E&type=items); 
1) the occurrence of a fault
2) the detection of anomalies (due to the fault)
3) the detection of defects as result of persistent anomalies (detection
times in order of microseconds to seconds dependending on defect type)
4) the control of consequent actions on the basis of detected defects and
the correlation of defects into a fault cause
5) the declaration of a failure after persistent presence of a fault cause
for 2.5 +/- 0.5 seconds
6) the assignment of a severity to the failure
7) the additional of alarm reporting control information
8) etc as per clause 7/G.7710.
 
When a fault occurs and one or more defects are detected as a result of the
fault, then an associated fault cause must persist continuously for 2.5+/-0.
5 seconds to become a failure. Failures can be reported as alarms.
 
The requirement for AIS reception by a MEP Sink function is that such AIS
message must be received within 2 seconds after the detection of a defect. 
This has been translated into a requirement to generate the first AIS OAM
message within 1 second of detection of a defect and to generate follow up
AIS messages every 1 second.

AIS OAM is used to suppress continuity and alignment fault causes. The
associated continuity and alignment defects are detected when the connection
is interrupted. Such interruption of a connection may be detected by
multiple Termination Sink functions and Adaptation Sink functions within MEP
Sink compound functions. 

Example: a fiber break in an OTM-n.m signal - carrying a number of e.g.
tandem connection monitored MS-PW signals with Ethernet clients inside a LO
ODU - will be detected by the following functions:
A) OTSn_TT_Sk fucntion in an optical amplifier (OA) device detects OTS-LOS
defect and OTS/OMS_A_Sk function inserts OMS-FDI OAM
B) OMSn_TT_Sk fucntion in a ROADM detects OMS-LOS defect and OMS/OCH_A_Sk
function inserts OCH-FDI OAM
C) OCH_TT_Sk function in an 3R Regenerator device detects OCH-LOS and
OCH-FDI defects, OCH/OTU_A_Sk function detects OTU-LOF and OTU-LOM defects
and OCH/OTU_A_Sk function activates OTU-SSF
D) OTU_TT_Sk fucntion in the 3R Regenerator device detects OTU-SSF condition
and suppresses its defects, OTU/ODU_A_Sk function inserts HO ODU-AIS within
2 HO ODU frame periods
E) HO ODU_TT_Sk function in an ODU XC device detects HO ODU-AIS defect and
suppresses its fault causes, HO ODU/LO ODU_A_Sk fucntion detects e.g. LO
ODU-LOF and -LOM defects and inserts LO ODU-AIS within 2 LO ODU frame
periods
F) LO ODU_TT_Sk function in another ODU XC device will detect ODU-AIS defect
and suppresses its fault causes, LO ODU/MPLS_A_Sk function detect GFP LFD
defect and ODU/MPLS_A_Sk function inserts PST LSP-AIS
G) PST LSP_TT_Sk function in a MPLS-TP S-PE device will detect LSP-LOC
defect and LSP-AIS defect, PST LSP/PW_A_Sk function will insert PW-AIS
within 1 second
H) PW_TT_Sk function in a MPLS-TP T-PE device will detect PW-LOC defect and
PW-AIS defect, PW/ETH_A_Sk function will insert ETH-AIS within 1 second
G) ETH_TT_Sk function in an Ethernet Network Termination Unit device will
detect ETH-LOC and ETH-AIS, ETH/Client_A_Sk fucntion will insert Client-AIS,
e.g. 2 Mbit/s AIS within 250 microsecond
I) etc.

When the fault (fiber break) occurs, the OA, ROADM, 3R Regen, ODU XC #1, ODU
XC #2, MPLS-TP S-PE, MPLS-TP T-PE, Etherent NTU and client devices will all
detect in about the same time their defect conditions. All those devices
will also insert FDI or AIS within one second after their defect detection.
This implies that approximately within 1 second after the fault occurred the
OA, ROADM, 3R Regen, ODU XC1, ODUXC2, S-PE, T-PE and NTU are sending
FDI/AIS. Such FDI/AIS OAM signals are received within milliseconds by the
next fucntion and will then suppress the fault causes declared in those
functions. Only the OTS-LOS fault cause will not be suppressed.

For the case there is somewhere in the path a protection switch function, e.
g. between 
- ODU XC1 and ODU XC2, then within 60 (i.e. 10 plus 50) milliseconds the LO
ODU connection is restored and the normal LO ODU signal with PW/ETH/Client
signals is forwarded again after 60 ms of traffic interrruption; the defects
detected downstream of this LO ODU protection switch selector will be
cleared and PW, ETH and client AIS insertions stopped. The defects detected
upstream and associated FDI/AIS insertion will continue to exist; it will
only clear and stop after the fault is repaired. But the inserted LO ODU AIS
signal does not pass through the protection switch selector anylonger.

- MPLS-TP S-PE and MPLS-TP T-PE, then within 60 ms (i.e. 10 plus 50)
milliseconds the MS-PW connection is restored and the normal MS-PW signal
with ETH/Client signals is forwarded again after 60 ms of traffic
interrruption; the defects detected downstream of this PW protection switch
selector will be cleared and ETH and client AIS insertions stopped. The
defects detected upstream and associated FDI/AIS insertion will continue to
exist; it will only clear and stop after the fault is repaired. But the
inserted AIS signal does not pass through the PW protection switch selector
anylonger.

There is as such no problem to expect.
Please note that this behaviour is present in transport networks for more
then 30 years.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: dinsdag 9 maart 2010 17:22
To: [email-masked]; [email-masked]; Annamaria Fulignoli;
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] draft-ietf-mpls-tp-oam-framework-05#section-5.3

Hi Dai:
 
To clarify your question, are you are suggesting AIS may not reach a MEP
prior to CC/CV in the given sub-layer timing out? Primarily due to stacking
of sub-layers imposing a S/W propagation delay.
 
If so that is a possibility. It could be accomodated by a hold off in
issuing an alarm to give alarm management to take effect. Alternately the
alarm could be asserted, and de-asserted shortly afterwards. Certainly
faster than human intervention time...
 
It is also possible that a protection switch may occur before AIS ripples
upwards, and if the higher layers CV rates are slower than the failed layer,
AIS will eventually reach the top layer MIP but the loss of connectivity
associated with the AIS will not be detected before the connectivity is
restored. Eventually the layer detection time will likely be slower than the
AIS propagation time....All that will happen is for a brief period of time,
alarms were suppressed, but no other action taken...

cheers
D

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, March 09, 2010 6:57 AM
To: [email-masked]; Annamaria Fulignoli; martin.vigoureux@alcatel-lucent.
com
Cc: [email-masked]
Subject: [mpls-tp] draft-ietf-mpls-tp-oam-framework-05#section-5.3

Hi editors and all, 

since AIS messages are issued  by the client layer adaptation function, in a
layer network, e.g, MPLS-TP network, there may be many adaption functions in
every layer. 

 given the figure 3 in draft-ietf-mpls-tp-oam-framework-05 and a fault is
defected by a MEP on Sec12,  the MEP of MS-PW1Z in LSR Z may receive a AIS
message after it has reported a dLOC defect alarm, and also may has switched
to a backup PW or has implemented other processes. 

BR. 

Xuehui 

Best Regards.