Re: [mpls-tp] LDI generation during slow CC

[[e-mail]]

George:
  firstly, Thanks for your reply!
  I agree with you opinion. Sending AIS should be nothing to do with 
whether the server MEP is using faster or slower procedure. 
  Actually, I just have some doubts of the necessity of generating AIS in 
server MEP when it is using the slower procedure because the out fast 
protection switch has finished before it receives the AIS. And I am not 
sure if the out fast protection can always assure the faster switch before 
it receives the AIS. So, I made this question and hoped for the further 
explanation.


                      xia.liang
                     best regard




George Swallow <[e-mail]>  2010-06-21 22:35:55:

> Xia -
> 
> If you are running CC at a high rate, then the normal AIS processing
> occurs.   Even if a server MEP is using the slower procedures, it 
> must send the AIS three times (the draft says send (1 time) and then
> retransmit twice (2 times)) space at 1 second intervals before 
> reverting to a slower rate.  This is to make sure that the same 
> level of effort as Y.1731 offers is made to suppress the alarm 
> before the 2 second hold-off expires.
> 
> ...George
> 
> 
> On 6/18/10 10:16 PM, "[e-mail]" <[e-mail]> 
wrote:

> 
> Hi, Maarten. 
> Thanks for your explanations in details. But I still have some 
> questions that wish you can clarify. Please see inline...
> 
> 
> 
> [e-mail] 写于 2010-06-18 17:55:57:
> 
> > Vijay, 
> > 
> > The current draft draft-ietf-mpls-tp-fault-01 does include an MPLS-
> > TP LDI OAM frame. This LDI frame must be removed from the MPLS-TP 
> > OAM set as it will unnecessary complicate MPLS-TP. I have discussed 
> > this with George Swallow some weeks ago and we agreed that for this 
> > undocumented application the AIS OAM frame could be extended with a 
> > "protection possible/not-possible" flag bit. 
> > 
> > To understand the need for such protection possible/not-possible 
> > flag bit it is required that the application is described first. 
> > After a description of the application, we will be able to identify 
> > if the proposed solution can work, or if it is incomplete and not 
> > worth adding. 
> > 
> > The application is the following: 
> > 
> > 1) A Transport Service (TS) or a Transport Path (TP) layer 
> > connection is protected multiple times, e.g. 2 times. There is an 
> > inner TS [or TP] protection span and there is an outer TS [or TP] 
> > protection span (see figure below) 
> > 
> >  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP 
> > --------------- Wi.MEP -- iPROT --------- Wo.MEP -- oPROT ------- MEP 
> >                        \ 
> > \-- Pi.MEP ---------------- Pi.MEP --/    /
> >                         \-- Po.MEP 
> > 
> 
----------------------------------------------------------------------------------------------
> > Po.MEP --/ 
> > 
> > 2) The outer protection is in some older equipment which is unable 
> > to support fast MPLS-TP CC/CV OAM generation and reception; e.g. 
> > this equipment is able to generate and receive CC/CV type OAM at 
> > once per 10 seconds. 
> > 
> 
> xia: If the outer protection is in newer equipment, and the inner 
> protection is in some older equipment. So the outer protection 
> support more fast MPLS-TP CC/CV OAM generation than inner 
> protection. In this application, does that mean that the outer 
> protection finishes the protction switch fast before it receives the
> AIS from Wi.MEP? Do you agree with my understanding or you have 
> another explanation? If my understanding is right, what is the 
> reaction when the Wo.MEP receive the slow AIS from Wi.MEP? 
> 
> > 3) The inner protection is in newer equipment which is able to 
> > support fast CC/CV OAM generation and reception; e.g. once per 3.3 ms. 

> > 
> > 4) when there is a fault in the inner working connection, then the 
> > Wi.MEP function will detect Loss of Continuity defect (dLOC) in 
> > about 10 ms and this dLOC will trigger the insertion of AIS OAM 
> > within 1 second after detection of dLOC. Because the Wi.MEP function
> > is part of a TS [or TP] SNC/S protection scheme, the protection 
> > engine is able to set the ProtPossible parameter in the Wi.MEP 
> > function to "1". When an AIS packet is generated, the ProtPossible 
> > flag is set to "1". Then this AIS packet is received by the Wo.MEP 
> > function in the older node, then the TS [or TP] SNC/S protection 
> > process will inspect the AIS frame and checks the ProtPossible flag;
> > if set to 1 it will don't take any action. 
> > 
> > 
> > AIS(ProtPossible=1) 
> > 
> > dLOC  |-----------------------------> 
> >  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX-----
> > Wi.MEP -- iPROT --------- Wo.MEP -- oPROT ------- MEP 
> >                        \ 
> > \-- Pi.MEP --------------- Pi.MEP --/    /
> >                         \-- Po.MEP 
> > 
> 
----------------------------------------------------------------------------------------------
> > Po.MEP --/ 
> > 
> > 5) when there was already a fault in the inner protection connection
> > (see figure below), then the inner protection engine would have set 
> > the ProtPossible parameter in the Wi.MEP to "0". As soon as the 
> > working connection fails, the Wi.MEP function will detect dLOC and 
> > will insert within 1 second an AIS packet of which the ProtPossible 
> > flag is set to "0". The Wo.EMP function in the older node will again
> > inspect the AIS packet for the ProtPossible flag value and will now 
> > trigger its own protection switching action (ProtPossible=0 
> > indicates that inner protection can not restore the connection). 
> > 
> > 
> > AIS(ProtPossible=0) 
> > 
> > dLOC  |-----------------------------> 
> >  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX-----
> > Wi.MEP -- iPROT --------- Wo.MEP -- oPROT ------- MEP 
> >                        \ 
> > \-- Pi.MEP ---XX--------- Pi.MEP --/   / 
> >                         \-- Po.MEP 
> > 
> 
----------------------------------------------------------------------------------------------
> > Po.MEP --/ 
> > 
> > 6) important to notice is that the ProtPossible parameter in a MEP 
> > has to be set to "0" under all conditions that disable the inner 
> > protection swithcing process to restore the traffic; this includes a
> > signal fail condition in either working or protection connection, a 
> > lockout of protection command and a forced switch command. 
> > 
> > 7) when the fault occurs at an intermediate node before the node 
> > with the inner protection switching function, this inner node will 
> > have set the ProtPossible parameter to the default value "0" 
> > (protection not possible). 
> 
> xia: In this situation, if the intermediate node is not between the 
> two Wi.MEP. The Wi.MEP will not detect the dLOC and will not send 
> AIS to the Wo.MEP. What do you mean "the inner node will have set 
> the ProtPossible parameter..."? Or it's just my understanding 
> question. Can you clarify to me? 
> 
> > 
> > 8) Note that TS [or TP] SNC/S protection switching is normally not 
> > using AIS defect as a trigger condition for protection switching. 
> > Reason is that AIS insertion is slow compared CC/CV and consequently
> > dLOC is detected much faster (ie. 10 ms) then dAIS (1 second). 
> > 
> > 9) older equipment which is required to provide some restricted form
> > of protection switching can be upgraded such that it can detect 
> > incoming AIS packets. Those incoming AIS packets will cause the 
> > detection of an AIS defect (dAIS) and of a LDI defect (dLDI); dLDI 
> > is true if the AIS packets have their ProtPossible flag set to "0" 
> > and dLDI is false is there is no AIS incoming  or if there is AIS 
> > incoming and the ProtPossible flag is set to "1". 
> > 
> > 10) newer equipment does not have to detect the LDI defect (dLDI). 
> 
> xia: Why? Does newer equipment need not dLDI to trigger its 
> protection? I think it is still possible, e.g. when outer newer 
> equipment has more slow CC/CV period than inner newer equipment. 
> 
> > 
> > 11) note that AIS packets are inserted at the ingress ports, before 
> > the switch fabric with the protection switch process. AIS insertion 
> > in e.g. working input port is not stopped when the protection switch
> > selects the traffic from the protection input port. But as traffic 
> > is not longer selected from the working input port, the AIS packets 
> > generated on this working input port will not longer be forwarded to
> > the output port. 
> > 
> > 12) the above does not address the presence and configuration of the
> > Hold off timers. Hold-off timers are required in nested protection 
> > switching cases as an inner fault will always trigger the signal 
> > fail detection at inner and outer protection switching levels. The 
> > detection of dLDI should also overrule the hold off timer in the 
> > outer protection process. 
> > 
> > 13) There are more conditions (than the once mentioned in the above 
> > consideration/description) that are to be considered before we know 
> > if this slow CC/CV OAM work around will function as required... one 
> > of those conditions is if there is another MEG level between with 
> > its own MEPs between the inner and outer protection switching 
> > levels.If it would be a requirement to support this slow CC/CV work 
> > around also in case of such intermediate MEG level, then complexity 
> > of this work around will be much higher... and msot likely it will 
> > become too complex... 
> > 
> > Regards, 
> > Maarten 
> > 

> 
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.