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

[Maarten Vissers <[e-mail]>]

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



----------------------------------------------------------------------------
-------------------------------------------