問題描述

OSN3500用EMS4單板配置EPL業務，VCTRUNK分別綁定5個VC12業務到兩根上光纖傳輸。使能LCAS功能后,當發生斷纖時,數據業務中斷150ms左右。客戶咨詢我們的LCAS在這種場景下的保護倒換時間是多少，有沒有標準？

處理過程

1.標準時間計算

VC12的復幀是通過K4字節的b2比特來實現的，32個VC12復幀組成一個虛級聯復幀，而每個VC12復幀由4個VC12構成。故由VC12組成的虛級聯復幀周期為 32*4*0.125ms = 16ms

根據標準描述，MFI的恢復時間可為3~10個虛級聯復幀周期。

VC12的MFI恢復時間即為：

3個MFI恢復復幀周期= 3 * 16ms = 48ms

10個MFI恢復復幀周期= 10 * 16ms = 160ms

2.LCAS保護倒換時間 = 故障檢測時間 + 單板業務恢復時間 + LCAS故障處理時間。

1）故障檢測時間與現網的實際路徑長度相關。

2）單板業務恢復時間在配置VC12的情況下，按照標準定義，恢復時間在48ms~160ms之間。

3）LCAS故障處理時間,EMS4的LCAS任務處理周期為200ms，也就是說LCAS任務最長處理時間是200ms。

4）結合上述計算方式,LCAS倒換時間在200ms左右。

根因

在ITU-T中，LCAS標準中沒有定義LCAS保護的倒換時間，然而LCAS協議本身是基于虛級聯技術，虛級聯技術標準中為了保證業務正確恢復，對業務恢復操作進行了嚴格的規定。

低階MFI恢復時間計算如下：

G.783標準描述：

8.2.5.2 VC-11 VC-12 VC-2 virtual concatenation multiframe alignment

Sink direction The extended overhead multiframe is recovered according to 8.2.3.1. The virtual concatenation frame number is recovered from bits 1-5 of the K4[2] multiframe sequence. The process will be in the out of multiframe (OOM) state when either the extended overhead multiframe alignment process is in the OOM

 state or when an error is encountered in the received and expected frame number from bits 1-5 of the K4[2] sequence. The process enters the IM state when the extended overhead multiframe process is in the IM state and two consecutive error-free frame numbers are recovered. The sequence number is recovered from bits 6-11 of the K4[2] sequence. A new sequence number is accepted if the received sequence has the same value in n consecutive extended overhead multiframes, with 3 ≤?n ≤?10. The accepted sequence number is compared with the expected sequence number for detection of the dSQM defect.

建議與總結

LCAS功能在增刪綁定的場景下，業務無損(前提：實際流量沒有超過刪除綁定或者添加綁定后的帶寬大小)。而對于中斷光纖的場景無法做到無損保護。