Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactiveCV/CC

From: "Cecil Byles" <[email-masked]>
Date: Fri, 16 Apr 2010 12:36:40 +0200

Hi,
Maybe I am miss-understanding the value of the CCM/CV/CC timers, but defect event like AIS that are greater than or equal to 10 seconds is deem unavailable time and thus the customer has loss service. Hence what is the value of having timers greater than 10 seconds by which time the customer service is already down and enabling protection switching 35s later is not great considering auto protection in the transport world is less than 50ms (typical aps is about 10ms). Thus the number of CCM/BFD/cc/CV to tunnels/services is surely a network design and planning activity based on the limitation of equipment use by the service/transport operator and not defined by standards. 

Regards Cecil 

________________________________

From: [email-masked] <[email-masked]> 
To: 'Thomas D. Nadeau' <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Wed Apr 14 19:43:52 2010
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactiveCV/CC 

Tom,
 
The default values are designed to meet the basic requirements for fault management, performance monitoring and protection switching.
 
What you are referring to is addition of MPLS-TP OAM to existing equipment that is not capable to support those default values. 
For such case we have to understand what the capabilities of such equipment are and which applications are to be supported.
 
Let's analyse:
 
1) fault management application can be supported when CC/CV and AIS OAM is added to the existing equipment. Typically such equipment can not meet (as you indicate) the default (fault management) rate for a large number of terminating PWs and LSPs in that equipment. E.g. OAM can be supported by system processor only, and e.g. 100 or 500 OAM messages per second can be generated for the complete system. If 1000 PW/LSP MEPs are present in the equipment, it will be possible in this example to generate 1 CC/CV OAM message per 10 seconds or per 2 seconds.
AIS generation and insertion will most likely also take some of the processor's OAM generation capability, so that CC/CV/AIS OAM can be generated for fewer PWs/LSPs, or less often generated.
 
In Ethernet OAM we have introduced the following rates for such existing equipment cases:
- 1 CCM message per 10 seconds
- 1 CCM message per minute
- 1 CCM message per 10 minutes.
 
And for AIS message we have introduced as second value - 1 per minute (default is 1 per second).
 
Fault management is possible with those CCM and AIS rates, but the performance will not meet the typical fault management performance. I.e. it takes much longer to detect a defect and generate the alarm, and with the 1 per minute AIS there will be a loss of continuity (LOC) alarm for about 1 minute before the LOC failure is suppressed.
 
MPLS-TP CC/CV and AIS OAM can copy these values. This would result in one common approach in packet transport networks, independent of the packet technology (ethernet of mpls-tp).

2) the basic performance monitoring application could be supported with less accuracy when CC/CV without LM is added to existing equipment. Performance monitoring conssits of two components: (i) detection of signal fail condition in a second and (ii) detection of signal degrade (packet loss). Only the first part could be supported with less accuracy then normal; i.e. defect detection takes more then 1-second and this will delay the detection of a severely errored second. If a customer runs CC/CV/LM OAM with default rate, then there will be a difference in the number of SESs and a difference in the number of UASs detected by the customer and network.
 
3) the basic protection switching application could be supported with longer detection times and thus switching will occur much later then by default.
 
I had a discussion with George this afternoon to see how the switching time could be reduced by using an LDI indication in AIS messages. We concluded that if AIS is generated within 1 second after the signal fail defect detection, then AIS message with LDI set can be used by protection switch located in the equipment with the low rate CC/CV OAM as signal fail indication and start the protection protocol. This can reduce the switching time from e.g. 3.5 seconds to less then 1 second, or from 35 second (3.5 x 10 seconds) to less then 1 second. Of course if the AIS insertion has to be done in a node with slow rate OAM, then AIS insertion is most likely done within 1-minute and it may not be of any help to reduce protection switching time.
 
Note that in the above numbers I have not taken into account possible further delays due to slow rate APS message generation. 1:1 SNC protection requires the use of APS OAM to synchronise both endpoints (necessary to retore the traffic flow).
 
In Ethernet OAM we also have introduced a CCM rate of 100 CCM messages per second (10 ms periodicity).  Loss of CC detection will now take 35 ms (instead of 11 ms). A little bit slower. 
 
Would the above values be sufficient to support the addition of some subset of MPLS-TP OAM to existing equipment?
 
---------
 
To minimize the OAM message generation demand in equipment (especially important for existing equipment) it would be important to minimise the number of pro-active OAM messages to be generated per PW/LSP MEP. It would be best to put the following OAM functions in one OAM message:
- CC
- CV
- LM (forward, backward)
- DM
- RDI.
 
If we would put those 5 OAM functions in 5 different OAM messages we will increase the minimal OAM processing capability in every equipment, or have more equipment that can not support the default application values.
 
Regards,
Maarten

________________________________

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: woensdag 14 april 2010 18:17
To: Maarten Vissers; 'Greg Mirsky'; 'D'Alessandro Alessandro Gerardo'
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

[snipped rest of message as the list is rejecting long posts]

    I think its important to hear from operators who might want to deploy this technology as to what their preferred defaults would be.  My concern with regard to these defaults is also that some lower-end equipment may not be able to support them at a high enough volume. That is, your statement is only concerned with the defaults for ONE MPLS-TP service instance, but there may be 100s or 1000s (or more) potentially serviced by the device in question. If it cannot support even the default values, then they are of no value.

    --Tom

On 4/12/10 3:03 PM, "Maarten Vissers" <[email-masked]> wrote:

	One question related to some of the writing. SLAs are associated with the transport service instances. Transport path instances don't have a SLA. Section instances don't have a SLA either.
	
	It is much simpler to have the following default values:
	
	- 1 per second if fault management is to be supported without performance monitoring/protection switching
	- 10 per second if fault management and performance monitoring is to be supported without protection swtiching
	- 300 per second if fault management, performance monitoring and protection swithcing are to be supported.
	
	The request to set up a PW or a LSP will be indicating which applications have to be supported, and this determines the required rate. 
	If the PW MEP or LSP MEP can not support the required rate, the application can not be supported and another PW/LSP MEP set has to be used instead.
	
	Regards,
	Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 16 Apr 2010 14:51:55 +0200

Cecil,
 
The receipt of AIS will suppress the LOC alarm, which is a primary alarm
that requires maintenance attention. 
 
AIS detection will however not stop the "trail signal fail" condition, and
it is this TSF that contributes to the error performance monitoring and
available/unavailable time determination. See
<http://www.maartenvissers.nl/mplstp/fm-pm-g806-g7710.pdf>
http://www.maartenvissers.nl/mplstp/fm-pm-g806-g7710.pdf for an overview of
the fault management and performance monitoring functional architectures in
G.806 http://www.itu.int/rec/T-REC-G.806/en and G.7710
<http://www.itu.int/rec/T-REC-G.7710/en>
http://www.itu.int/rec/T-REC-G.7710/en. 
 
The processing of loss of continuity (LOC) and AIS defects is as follows
(based on Figures 6-1/G.806, 7/G.7710, 23/G.7710):
 
        LOC defect (dLOC)    AIS defect (dAIS)
         |            |        |    
         V            V        V
TSF consequent      LOC fault cause (cLOC)
action (aTSF)       "if dLOC and (not dAIS)"
 |       |                     |
 V       V                     V
prot  near-end defect     LOC failure (fLOC)
swtch  second (pN_DS)      "if cLOC persists for 
trggr     |               2.5 +/- 0.5 seconds"
          |                       |
          V                       V
      near-end severy     severity assignment (SEV)
      errored second             |
        (NSES(t))                V
          |              alarm reporting control (ARC)
          V                  |     |     |     |
      after 10 seconds:      V     V     V     V
         UAT                UNA   REP   CPL   AST

The default values of CCM/CC/CV/LM presented will guarantee that the typical
transport fault management, performance monitoring and protection switching
performance values are met.
 
The issue brought on to the table is how much of the fault management,
performance monitoring and protection switching can be supported for the
case we add OAM and protection switching support on to existing equipment
that was not designed to support MPLS-TP OAM.
 
It might be that it is possible to support enough of it to continue to use
this equipment after a software upgrade that adds a lower-performance subset
of the MPLS-TP OAM and protection swithcing fucntionality. The alternative
is to replace the equipment by new equipment that is designed to support the
full blown MPLS-TP OAM and protection switching.
 
The OAM framework should however describe the specific applications behind
such requirement, so that a proper analysis can be performed to judge if the
additional OAM and protection switching complexity is acceptable.
 
Regards,
Maarten

  _____  

From: Cecil Byles [mailto:[email-masked]] 
Sent: vrijdag 16 april 2010 12:37
To: [email-masked]; [email-masked]
Cc: [email-masked]; Ibrahim Djafer
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for
proactiveCV/CC

Hi,
Maybe I am miss-understanding the value of the CCM/CV/CC timers, but defect
event like AIS that are greater than or equal to 10 seconds is deem
unavailable time and thus the customer has loss service. Hence what is the
value of having timers greater than 10 seconds by which time the customer
service is already down and enabling protection switching 35s later is not
great considering auto protection in the transport world is less than 50ms
(typical aps is about 10ms). Thus the number of CCM/BFD/cc/CV to
tunnels/services is surely a network design and planning activity based on
the limitation of equipment use by the service/transport operator and not
defined by standards. 

Regards Cecil 

  _____  

Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for
proactiveCV/CC 

Tom,
 
The default values are designed to meet the basic requirements for fault
management, performance monitoring and protection switching.
 
What you are referring to is addition of MPLS-TP OAM to existing equipment
that is not capable to support those default values. 
For such case we have to understand what the capabilities of such equipment
are and which applications are to be supported.
 
Let's analyse:
 
1) fault management application can be supported when CC/CV and AIS OAM is
added to the existing equipment. Typically such equipment can not meet (as
you indicate) the default (fault management) rate for a large number of
terminating PWs and LSPs in that equipment. E.g. OAM can be supported by
system processor only, and e.g. 100 or 500 OAM messages per second can be
generated for the complete system. If 1000 PW/LSP MEPs are present in the
equipment, it will be possible in this example to generate 1 CC/CV OAM
message per 10 seconds or per 2 seconds.
AIS generation and insertion will most likely also take some of the
processor's OAM generation capability, so that CC/CV/AIS OAM can be
generated for fewer PWs/LSPs, or less often generated.
 
In Ethernet OAM we have introduced the following rates for such existing
equipment cases:
- 1 CCM message per 10 seconds
- 1 CCM message per minute
- 1 CCM message per 10 minutes.
 
And for AIS message we have introduced as second value - 1 per minute
(default is 1 per second).
 
Fault management is possible with those CCM and AIS rates, but the
performance will not meet the typical fault management performance. I.e. it
takes much longer to detect a defect and generate the alarm, and with the 1
per minute AIS there will be a loss of continuity (LOC) alarm for about 1
minute before the LOC failure is suppressed.
 
MPLS-TP CC/CV and AIS OAM can copy these values. This would result in one
common approach in packet transport networks, independent of the packet
technology (ethernet of mpls-tp).

2) the basic performance monitoring application could be supported with less
accuracy when CC/CV without LM is added to existing equipment. Performance
monitoring conssits of two components: (i) detection of signal fail
condition in a second and (ii) detection of signal degrade (packet loss).
Only the first part could be supported with less accuracy then normal; i.e.
defect detection takes more then 1-second and this will delay the detection
of a severely errored second. If a customer runs CC/CV/LM OAM with default
rate, then there will be a difference in the number of SESs and a difference
in the number of UASs detected by the customer and network.
 
3) the basic protection switching application could be supported with longer
detection times and thus switching will occur much later then by default.
 
I had a discussion with George this afternoon to see how the switching time
could be reduced by using an LDI indication in AIS messages. We concluded
that if AIS is generated within 1 second after the signal fail defect
detection, then AIS message with LDI set can be used by protection switch
located in the equipment with the low rate CC/CV OAM as signal fail
indication and start the protection protocol. This can reduce the switching
time from e.g. 3.5 seconds to less then 1 second, or from 35 second (3.5 x
10 seconds) to less then 1 second. Of course if the AIS insertion has to be
done in a node with slow rate OAM, then AIS insertion is most likely done
within 1-minute and it may not be of any help to reduce protection switching
time.
 
Note that in the above numbers I have not taken into account possible
further delays due to slow rate APS message generation. 1:1 SNC protection
requires the use of APS OAM to synchronise both endpoints (necessary to
retore the traffic flow).
 
In Ethernet OAM we also have introduced a CCM rate of 100 CCM messages per
second (10 ms periodicity).  Loss of CC detection will now take 35 ms
(instead of 11 ms). A little bit slower. 
 
Would the above values be sufficient to support the addition of some subset
of MPLS-TP OAM to existing equipment?
 
---------
 
To minimize the OAM message generation demand in equipment (especially
important for existing equipment) it would be important to minimise the
number of pro-active OAM messages to be generated per PW/LSP MEP. It would
be best to put the following OAM functions in one OAM message:
- CC
- CV
- LM (forward, backward)
- DM
- RDI.
 
If we would put those 5 OAM functions in 5 different OAM messages we will
increase the minimal OAM processing capability in every equipment, or have
more equipment that can not support the default application values.
 
Regards,
Maarten

  _____  

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: woensdag 14 april 2010 18:17
To: Maarten Vissers; 'Greg Mirsky'; 'D'Alessandro Alessandro Gerardo'
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive
CV/CC

    I think its important to hear from operators who might want to deploy
this technology as to what their preferred defaults would be.  My concern
with regard to these defaults is also that some lower-end equipment may not
be able to support them at a high enough volume. That is, your statement is
only concerned with the defaults for ONE MPLS-TP service instance, but there
may be 100s or 1000s (or more) potentially serviced by the device in
question. If it cannot support even the default values, then they are of no
value.

    --Tom

One question related to some of the writing. SLAs are associated with the
transport service instances. Transport path instances don't have a SLA.
Section instances don't have a SLA either.

- 1 per second if fault management is to be supported without performance
monitoring/protection switching
- 10 per second if fault management and performance monitoring is to be
supported without protection swtiching
- 300 per second if fault management, performance monitoring and protection
swithcing are to be supported.

The request to set up a PW or a LSP will be indicating which applications
have to be supported, and this determines the required rate. 
If the PW MEP or LSP MEP can not support the required rate, the application
can not be supported and another PW/LSP MEP set has to be used instead.

Regards,
Maarten

---

From: "Cecil Byles" <[email-masked]>
Date: Mon, 19 Apr 2010 14:08:10 +0200

Thanks for this as it re-confirms my understanding.
 
Regards

From: Maarten Vissers [mailto:[email-masked]] 
Sent: 16 April 2010 13:52
To: Cecil Byles; [email-masked]
Cc: [email-masked]; Ibrahim Djafer
Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for
proactiveCV/CC

Cecil,

AIS detection will however not stop the "trail signal fail" condition,
and it is this TSF that contributes to the error performance monitoring
and available/unavailable time determination. See
http://www.maartenvissers.nl/mplstp/fm-pm-g806-g7710.pdf
<http://www.maartenvissers.nl/mplstp/fm-pm-g806-g7710.pdf>  for an
overview of the fault management and performance monitoring functional
architectures in G.806 http://www.itu.int/rec/T-REC-G.806/en and G.7710
http://www.itu.int/rec/T-REC-G.7710/en
<http://www.itu.int/rec/T-REC-G.7710/en> . 

The default values of CCM/CC/CV/LM presented will guarantee that the
typical transport fault management, performance monitoring and
protection switching performance values are met.
 
The issue brought on to the table is how much of the fault management,
performance monitoring and protection switching can be supported for the
case we add OAM and protection switching support on to existing
equipment that was not designed to support MPLS-TP OAM.
 
It might be that it is possible to support enough of it to continue to
use this equipment after a software upgrade that adds a
lower-performance subset of the MPLS-TP OAM and protection swithcing
fucntionality. The alternative is to replace the equipment by new
equipment that is designed to support the full blown MPLS-TP OAM and
protection switching.
 
The OAM framework should however describe the specific applications
behind such requirement, so that a proper analysis can be performed to
judge if the additional OAM and protection switching complexity is
acceptable.
 
Regards,
Maarten

Hi,
Maybe I am miss-understanding the value of the CCM/CV/CC timers, but
defect event like AIS that are greater than or equal to 10 seconds is
deem unavailable time and thus the customer has loss service. Hence what
is the value of having timers greater than 10 seconds by which time the
customer service is already down and enabling protection switching 35s
later is not great considering auto protection in the transport world is
less than 50ms (typical aps is about 10ms). Thus the number of
CCM/BFD/cc/CV to tunnels/services is surely a network design and
planning activity based on the limitation of equipment use by the
service/transport operator and not defined by standards. 

Regards Cecil 

Tom,

What you are referring to is addition of MPLS-TP OAM to existing
equipment that is not capable to support those default values. 
For such case we have to understand what the capabilities of such
equipment are and which applications are to be supported.
 
Let's analyse:
 
1) fault management application can be supported when CC/CV and AIS OAM
is added to the existing equipment. Typically such equipment can not
meet (as you indicate) the default (fault management) rate for a large
number of terminating PWs and LSPs in that equipment. E.g. OAM can be
supported by system processor only, and e.g. 100 or 500 OAM messages per
second can be generated for the complete system. If 1000 PW/LSP MEPs are
present in the equipment, it will be possible in this example to
generate 1 CC/CV OAM message per 10 seconds or per 2 seconds.
AIS generation and insertion will most likely also take some of the
processor's OAM generation capability, so that CC/CV/AIS OAM can be
generated for fewer PWs/LSPs, or less often generated.

 
Fault management is possible with those CCM and AIS rates, but the
performance will not meet the typical fault management performance. I.e.
it takes much longer to detect a defect and generate the alarm, and with
the 1 per minute AIS there will be a loss of continuity (LOC) alarm for
about 1 minute before the LOC failure is suppressed.
 
MPLS-TP CC/CV and AIS OAM can copy these values. This would result in
one common approach in packet transport networks, independent of the
packet technology (ethernet of mpls-tp).

2) the basic performance monitoring application could be supported with
less accuracy when CC/CV without LM is added to existing equipment.
Performance monitoring conssits of two components: (i) detection of
signal fail condition in a second and (ii) detection of signal degrade
(packet loss). Only the first part could be supported with less accuracy
then normal; i.e. defect detection takes more then 1-second and this
will delay the detection of a severely errored second. If a customer
runs CC/CV/LM OAM with default rate, then there will be a difference in
the number of SESs and a difference in the number of UASs detected by
the customer and network.
 
3) the basic protection switching application could be supported with
longer detection times and thus switching will occur much later then by
default.
 
I had a discussion with George this afternoon to see how the switching
time could be reduced by using an LDI indication in AIS messages. We
concluded that if AIS is generated within 1 second after the signal fail
defect detection, then AIS message with LDI set can be used by
protection switch located in the equipment with the low rate CC/CV OAM
as signal fail indication and start the protection protocol. This can
reduce the switching time from e.g. 3.5 seconds to less then 1 second,
or from 35 second (3.5 x 10 seconds) to less then 1 second. Of course if
the AIS insertion has to be done in a node with slow rate OAM, then AIS
insertion is most likely done within 1-minute and it may not be of any
help to reduce protection switching time.
 
Note that in the above numbers I have not taken into account possible
further delays due to slow rate APS message generation. 1:1 SNC
protection requires the use of APS OAM to synchronise both endpoints
(necessary to retore the traffic flow).
 
In Ethernet OAM we also have introduced a CCM rate of 100 CCM messages
per second (10 ms periodicity).  Loss of CC detection will now take 35
ms (instead of 11 ms). A little bit slower. 
 
Would the above values be sufficient to support the addition of some
subset of MPLS-TP OAM to existing equipment?
 
---------
 
To minimize the OAM message generation demand in equipment (especially
important for existing equipment) it would be important to minimise the
number of pro-active OAM messages to be generated per PW/LSP MEP. It
would be best to put the following OAM functions in one OAM message:
- CC
- CV
- LM (forward, backward)
- DM
- RDI.
 
If we would put those 5 OAM functions in 5 different OAM messages we
will increase the minimal OAM processing capability in every equipment,
or have more equipment that can not support the default application
values.
 
Regards,
Maarten

    I think its important to hear from operators who might want to
deploy this technology as to what their preferred defaults would be.  My
concern with regard to these defaults is also that some lower-end
equipment may not be able to support them at a high enough volume. That
is, your statement is only concerned with the defaults for ONE MPLS-TP
service instance, but there may be 100s or 1000s (or more) potentially
serviced by the device in question. If it cannot support even the
default values, then they are of no value.

    --Tom

On 4/12/10 3:03 PM, "Maarten Vissers" <[email-masked]>
wrote:

	One question related to some of the writing. SLAs are associated
with the transport service instances. Transport path instances don't
have a SLA. Section instances don't have a SLA either.

	- 1 per second if fault management is to be supported without
performance monitoring/protection switching
	- 10 per second if fault management and performance monitoring
is to be supported without protection swtiching
	- 300 per second if fault management, performance monitoring and
protection swithcing are to be supported.
	
	The request to set up a PW or a LSP will be indicating which
applications have to be supported, and this determines the required
rate. 
	If the PW MEP or LSP MEP can not support the required rate, the
application can not be supported and another PW/LSP MEP set has to be
used instead.
	
	Regards,
	Maarten