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

[[e-mail]]

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
> 
> From: [e-mail] [mailto:[e-mail]] On 
Behalf Of 
> Vijayanand C - ERS, HCL Tech
> Sent: vrijdag 18 juni 2010 8:29
> To: MPLS TP
> Subject: [mpls-tp] LDI generation during slow CC

> Hello all,
> In draft-ietf-mpls-tp-fault, section 2.3 says that when CC is slow 
> LDI enables faster switchover
> 
> “In more general MPLS environments the CC function may
>    be running at a much slower rate.  In this environment, LDI enables
>    faster switch-over upon a failure occurring along the LSP.”
> 
> 
> It is not clear in the spec how LDI will be generated when CC is 
> slow and has not detected failure.
> Is it implicit that the LSPs own detection mechanism ( refresh 
> timeout, path tear etc..) will trigger the LDI ?
> Can anyone clarify this ?
> 
> 
> Regards
> Vijay
> 
> 
> 
> DISCLAIMER:
> 
-----------------------------------------------------------------------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are confidential 
> and intended for the named recipient(s) only. 
> It shall not attach any liability on the originator or HCL or its 
> affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not necessarily 
> reflect the opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of 
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have 
> received this email in error please delete it and notify the sender 
> immediately. Before opening any mail and 
> attachments please check them for viruses and defect.
> 
> 
-----------------------------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp



--------------------------------------------------------
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.