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

[George Swallow <[e-mail]>]

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