Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 May 2009 12:50:16 +0200

Ben,

ITU-T's transport network standards have a consistent Fault Management
behaviour. This behaviour includes alarm suppression using AIS/FDI
replacement signal insertion at link connection endpoints when such link
connection experiences a signal fail type defect condition.

This behaviour is consistently present in PDH, ATM, SDH, OTN and Ethernet
transport network recommendations.

If the operator community agrees with your company's proposal that alarm
suppression and insertion of an AIS/FDI like replacement signal is not
longer required, I would expect that such requirement is not limited to the
MPLS-TP part of the transport network, but also applies to the other
transport networks, e.g. SDH, OTN and Ethernet. I expect that there is a
requirement to continue to have consistent and technology agnostic fault
management behaviour. But it might be that fault management requirements for
MPLS-TP are very different from the fault management requirements for the
other transport technologies. Unless this is explicitly stated, I have to
assume that consistent and technology agnostic fault management behaviour is
the requirement.

As an example (note that this is **not** a proposal to change!!) of the
suggestion that alarm suppression would not be necessary in transport
networks, it is possible to analyse what this would have meant if this
requirement would not have been present when we designed SDH: if this alarm
suppression would not have been a requirement in SDH, then SDH AIS signals
would have been replaced by SDH open connection indication signals; e.g.
AU-AIS would have been replaced by VC-UNEQ, TU-AIS would have been replaced
by VC-UNEQ, VC-AIS would have been replaced by VC-UNEQ and MS-AIS would have
been replaced by MS-UNEQ. A signal fail condition in e.g. the physical media
layer connection would be reported as STM-LOS by the Physical Media layer
termination function (OSn_TT), and as MS-UNEQ by the MSn termination
function, VC-4 UNEQ by the set of VC-4 termiantion functions of which the
VC-4 connections are carried by the STM-N and LOVC UNEQ by the set of LOVC
termination functions of which the LOVC connections are carried by the STM-N
(via the VC4s).
The reporting of such UNEQ fault causes/failures can alternatively be
realised by means of a modified set of the Defect Correlation
specifications. Instead that e.g. AU-AIS suppresses the VC-UNEQ fault cause,
it could become one of the trigger conditions of VC-UNEQ fault cause; i.e.
cUNEQ <-- dUNEQ or dAIS or CI_SSF (instead of cUNEQ <-- dUNEQ and (not dAIS)
and (not CI_SSF)).

Hope this clarifies the rationale behind my post.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: donderdag 30 april 2009 9:08
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Eh?

Tom & Nurit (and I) agree that SPs should speak for themselves on what their
requirements are for MPLS-TP.

I am supporting PDH, Ethernet and ATM services over my MPLS network today
and my MPLS network does not perform AIS insertion at all so I do not see
how a lack of AIS in MPLS (or MPLS-TP) impacts those standards.

Maybe the issue is between an understanding of the theoretical and of the
practical. As stated, in practice I am supporting the network types above
without problems even though the MPLS network supporting them does not
support AIS.
 
Let's not confuse things and let's not scare monger huge changes that IMO do
not exist.

Ben

On 30/04/2009 05:26, "Maarten Vissers" <[email-masked]> wrote:

> We are discussing a change of a general fault management principle. 
> This change will impact the following recommendations: G.806 
> (generic), G.7710 (generic), G.705 (PDH), G.783/G.784 (SDH), 
> G.798/G.874 (OTN),
> G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and 
> G.8121/G.8112/G.8151 (MPLS-TP). This proposed change has implications 
> beyond the scope of MPLS-TP and should be addressed in Q.9/15, Q.10/15,
Q.11/15 and Q.14/15.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: woensdag 29 april 2009 19:57
> To: ext Thomas Nadeau
> Cc: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated
> bidirectionaltransportpathrequirements)
> 
> I agree!
> 
> -----Original Message-----
> From: ext Thomas Nadeau [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2009 1:01 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
> transportpathrequirements)
> 
> 
> It would be best is these "Tier-1 SPs" would comment directly on the 
> list or contribute to the requirements draft.
> 
> --Tom
> 
> 
> On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon)
> wrote:
> 
>> Neil,
>> Thanks for the very good explanation. It really helps me to 
>> understand better the context of the long discussion.
>> Personally I got many feedbacks from Tier-1 SPs that they would like 
>> to have the capability to suppress alarms in a packet transport 
>> environment. Their requirement was that if a server layer (e.g. MPLS- 
>> TP
>> link) fails, there is a way to notify the client layer (e.g. LSPs) in 
>> order to be able to suppress alarms at the client layer that may 
>> result from the fault at the server layer (e.g. MPLS-TP link).
>> Isn't it a logical and reasonable requirement in a transport profile?
>> Also I saw general requirements for inter-layer fault correlation. So 
>> can I understand from your mail that you are not happy from such a 
>> requirement as well?
>> Best regards,
>> Nurit
>> 
>> 
>> 
>> -----Original Message-----
>> From: ext [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, April 28, 2009 11:07 AM
>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
>> [email-masked]; [email-masked]; 
>> [email-masked]
>> Cc: [email-masked]
>> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional
>> transportpathrequirements)
>> 
>> Nurit,
>> 
>> I believe the reason we need this discussion is that there is an 
>> unstated assumption here that the client/server relationship is fixed.
>> However, if the client can dynamically change its routing in response 
>> to link failures in its topology (because some server layer network 
>> has failed....which may or may not belong to the same operating party 
>> as the
>> client) then there is no fixed client/server relationship.
>> 
>> Refer to my post earlier today and consider what this means in the 
>> case of a cl-ps IP client layer network or a some SVC-based 
>> co-ps/co-cs mode client layer network.  The key point here is the 
>> *routing process* in the client is independent of the server layer 
>> network....so there is not a fixed client/server relationship.  
>> Further, there is also no requirement for the server to keep track of 
>> where its client traffic routings are at any epoch.....indeed why 
>> should it in the general case where these are independent layer 
>> networks?
>> 
>> So the only OAM requirement that is critical is that the OAM of the 
>> client and server layer networks are independent.  It is thus not 
>> sensible to make client layer alarm supression a 'requirement'
>> here...in
>> fact if this is in the OAM requirements then it is technically wrong 
>> and should be removed IMO.
>> 
>> regards, Neil
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN 
>>> - IL/Hod HaSharon)
>>> Sent: 28 April 2009 08:46
>>> To: ext BUSI ITALO; [email-masked]; Adrian Farrel
>>> Cc: [email-masked]
>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
>>> transportpathrequirements)
>>> 
>>> If we agree that the requirement is included, so why do we keep with 
>>> the endless discussions on this requirement?
>>> 
>>> -----Original Message-----
>>> From: ext BUSI ITALO [mailto:[email-masked]]
>>> Sent: Tuesday, April 28, 2009 10:44 AM
>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
>>> Adrian Farrel
>>> Cc: [email-masked]
>>> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional 
>>> transport
>>> pathrequirements)
>>> 
>>> I think that the requirements are defined in section 2.2.8 of
>>> draft-ietf-mpls-tp-oam-requirements-01
>>> 
>>> Italo
>>> 
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN 
>>>> - IL/Hod HaSharon)
>>>> Sent: Tuesday, April 28, 2009 6:56 AM
>>>> To: [email-masked]; Adrian Farrel
>>>> Cc: [email-masked]
>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
>>>> transport pathrequirements)
>>>> 
>>>> Huub,
>>>> I think that the requirement is to provide a mechanism to suppress 
>>>> alarms in the networks, to ensure that alarms that may be
>>> generated by
>>>> client layers as a result of a failure condition in the server 
>>>> layer may be suppressed.
>>>> Every thing else is a solution, etc.
>>>> I propose to phrase the requirement appropriately and conclude the 
>>>> discussion on this in the context of the requirements (until we are 
>>>> getting to the solution phase).
>>>> This requirement is included in the OAM requirement draft.
>>>> Best regards,
>>>> NUrit
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of ext Huub van Helvoort
>>>> Sent: Tuesday, April 28, 2009 12:27 AM
>>>> To: Adrian Farrel
>>>> Cc: [email-masked]
>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated
>>> bidirectional transport
>>>> path requirements)
>>>> 
>>>> Hi Adrian,
>>>> 
>>>> You wrote:
>>>> 
>>>>> Isn't the solution here the same as the one I proposed for "TCM"?
>>>> 
>>>> Indeed, and that we do not have to around in circles about TCM.
>>>> 
>>>> How about:
>>>> the requirement is that a server layer shall inform its clients 
>>>> that it has detected a service interuption, this to ensure that the 
>>>> clients can inhibit (unnecessary) alarms.
>>>> 
>>>> Cheers, Huub.
>>>> 
>>>> --
>>>> ================================================================
>>>>                   http://www.van-helvoort.eu/ 
>>>> ================================================================
>>>> Always remember that you are unique...just like everyone else...
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>> 
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>> 
>> _______________________________________________
>> mpls-tp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: George Newsome <[email-masked]>
Date: Mon, 04 May 2009 09:29:00 -0400

> connection experiences a signal fail type defect condition.
Maarten,

You continue to confuse the behaviour (alarm suppression) with the 
mechanism we used in TDM systems (AIS/FDI replacement signal insertion).
The behaviour can be achieved (as Andy has shown) without the complexity 
of the replacement signal insertion.

It seems to me that this is one of the few cases when we can have our 
cake and eat it too, so I don't understand the hangup with the mechanism.

Lets stick with specifying the behaviour, and loose our hangups with the 
mechanism.

Regards,

	George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 05 May 2009 08:47:43 +0100

Maarten,

You state:

On 04/05/2009 11:50, "Maarten Vissers" <[email-masked]> wrote:

> longer required,

My company's position is irrelevant to this particular thread.

> I would expect that such requirement is not limited to the
> transport networks, e.g. SDH, OTN and Ethernet.

That is an assumption you have made.

>> beyond the scope of MPLS-TP and should be addressed in Q.9/15, Q.10/15,

That is an assumption which you stated as a fact. My earlier mail in this
thread was to refute that "fact".

Reality is that BT and many other operators have been successfully
supporting PDH, Ethernet and ATM services over their MPLS networks for some
time.

MPLS networks do not perform AIS insertion at all.  I am not aware of any
suggestion to update the Recommendations you list above as a result.

There are standards (and I believe deployments) to support PDH services over
IP. IP networks do not perform AIS insertion at all.  I am not aware of any
suggestion to update the Recommendations you list above as a result.

IEEE are the design authority for Ethernet and they saw no need to include
AIS in 802.1ag. There are standards (I am not sure of their deployment
status) to support PDH services over Ethernet. There is equipment (I am not
sure of the standardisation status) that supports ATM over Ethernet. I am
not aware of any suggestion to update the Recommendations you list above as
a result.

Therefore I must conclude that it is possible to successfully support fault
management in PDH, Ethernet and ATM client networks supported by a server
network that does not support AIS insertion.

Therefore I consider your statement that the Recommendations you list above
must be updated to be alarmist and misleading.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 11:50:47 +0200

Ben,

I am not talking about transport of 
- PDH signals over MPLS(-TP), or 
- Ethernet VLAN signals over MPLS(-TP), or 
- ATM signals over MPLS(-TP). 
It is obvious that the transport of such signals over MPLS(-TP) is not
impacted by the presence of alarm suppression tools within MPLS(-TP) layers.

I am talking about the behaviour of fault management within the MPLS-TP
layers of a transport network versus the behaviour of fault management
inside e.g. the SDH VC-n or OTN ODUk layers of a transport network. 

I am as such talking about the maintenance signal, consequent action and
defect correlation specifications in termination sink and adaptation sink
functions; i.e. in MPLS-TP termination and adaptation sink functions versus
SDH VC-n and OTN ODUk termination and adaptation sink functions.

All transport network technologies specified so far (PDH, SDH, ATM, OTN,
Ethernet) have consistent maintenance signal, consequent action and defect
correlation specifications in their termination sink and adaptation sink
functions, which result in a common alarm reporting behaviour.

As far as I understand your company's proposal, MPLS-TP termination sink and
adaptation sink functions will not be aligned with those common maintenance
signal, consequent action and defect correlation specifications. MPLS-TP in
your company's proposal should not support an alarm suppressing maintenance
signal (like AIS/FDI), and will as such not be able to suppress e.g. loss of
CC fault causes/failures that are due to server layer faults. 

It has been stated by your colleagues that such suppression of consequential
loss of CC fault causes/failures is not necessary in MPLS-TP layers. If it
is not necessary in the MPLS-TP layers of a transport network, it will not
be necessary in the e.g. SDH VC-n, OTN ODUk or Ethernet ETH layers of a
transport network. And it is most likely just a matter of time before there
is a proposal to align the fault management behaviour in e.g. the OTN ODUk
and Ethernet ETH layers with the behaviour in MPLS-TP layers.

As an OTN example, every interruption of an ODUk connection (also those
caused by server layer faults) should -  according to the proposed new
behaviour - be reported as a "Loss of ODUk" (i.e. ODUk open connection)
alarm.

I hope this explains the issue that I try to address.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 9:48
To: Maarten Vissers; [email-masked]
Subject: Updating ITU-T fault management specs (was Re: [mpls-tp] AIS/FDI)

Maarten,

You state:

On 04/05/2009 11:50, "Maarten Vissers" <[email-masked]> wrote:

> replacement signal insertion at link connection endpoints when such 
> link connection experiences a signal fail type defect condition.
> 
> This behaviour is consistently present in PDH, ATM, SDH, OTN and 
> Ethernet transport network recommendations.
> 
> If the operator community agrees with your company's proposal that 
> alarm suppression and insertion of an AIS/FDI like replacement signal 
> is not longer required,

> I would expect that such requirement is not limited to the MPLS-TP 
> part of the transport network, but also applies to the other transport 
> networks, e.g. SDH, OTN and Ethernet.

Ben

---

From: George Newsome <[email-masked]>
Date: Tue, 05 May 2009 10:34:27 -0400

Maarten Vissers wrote:
>...................
Ah... I see your difficulty.

In your mind, all this processing occurs in a termination function, so 
the TTF NEEDS an input signal that is part of the signal being terminated.

In my mind, the entity doing most of the processing is the ELEMENT 
management function, so no maintenance signal is required as long as 
there is sufficient information available to the EMF.

I now understand why you are confusing the maintenance signal, with what 
the EMF needs to do to satisfy the requirements.

Hopefully, this insight will help you separate the requirements (which 
we agree with) from implementations.

Regards,
	George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 05 May 2009 16:47:54 +0100

George,

I have the same understanding as you here.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 19:29:39 +0200

George,

A network element (equipment) consists of Atomic Functions (AF) connected to
interface ports and connected to the Equipment Management Function (EMF).
The latter via the Management Points over which Management Information
(MI_XXX) is exchanged between AF and EMF. 

The EMF within a network element receives all its fault management
information via the Management Points connected to the atomic functions.
Refer to the fault management specifications in G.7710 for the details.

In our existing recommendations there is no alarm suppression information
available to the EMF within a network element. Alarm suppression information
is only available in the atomic functions.

It is always possible to re-invent the wheel... Please describe how you
think alarm suppression can be supported in the EMF in network elements
instead of in atomic functions in network elements.

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 16:34
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Maarten Vissers wrote:
> Ben,
> 
>...................
> 
> I am talking about the behaviour of fault management within the 
> MPLS-TP layers of a transport network versus the behaviour of fault 
> management inside e.g. the SDH VC-n or OTN ODUk layers of a transport
network.
>
> I am as such talking about the maintenance signal, consequent action 
> and defect correlation specifications in termination sink and 
> adaptation sink functions; i.e. in MPLS-TP termination and adaptation 
> sink functions versus SDH VC-n and OTN ODUk termination and adaptation
sink functions.

In your mind, all this processing occurs in a termination function, so the
TTF NEEDS an input signal that is part of the signal being terminated.

In my mind, the entity doing most of the processing is the ELEMENT
management function, so no maintenance signal is required as long as there
is sufficient information available to the EMF.

I now understand why you are confusing the maintenance signal, with what the
EMF needs to do to satisfy the requirements.

Hopefully, this insight will help you separate the requirements (which we
agree with) from implementations.

Regards,
	George

> Ethernet) have consistent maintenance signal, consequent action and 
> defect correlation specifications in their termination sink and 
> adaptation sink functions, which result in a common alarm reporting
behaviour.
> 
> As far as I understand your company's proposal, MPLS-TP termination 
> sink and adaptation sink functions will not be aligned with those 
> common maintenance signal, consequent action and defect correlation 
> specifications. MPLS-TP in your company's proposal should not support 
> an alarm suppressing maintenance signal (like AIS/FDI), and will as 
> such not be able to suppress e.g. loss of CC fault causes/failures that
are due to server layer faults.
> 
> It has been stated by your colleagues that such suppression of 
> consequential loss of CC fault causes/failures is not necessary in 
> MPLS-TP layers. If it is not necessary in the MPLS-TP layers of a 
> transport network, it will not be necessary in the e.g. SDH VC-n, OTN 
> ODUk or Ethernet ETH layers of a transport network. And it is most 
> likely just a matter of time before there is a proposal to align the 
> fault management behaviour in e.g. the OTN ODUk and Ethernet ETH layers
with the behaviour in MPLS-TP layers.
> 
> As an OTN example, every interruption of an ODUk connection (also 
> those caused by server layer faults) should -  according to the 
> proposed new behaviour - be reported as a "Loss of ODUk" (i.e. ODUk 
> open connection) alarm.
> 
>> ITU-T's transport network standards have a consistent Fault 
>> Management behaviour. This behaviour includes alarm suppression using 
>> AIS/FDI replacement signal insertion at link connection endpoints 
>> when such link connection experiences a signal fail type defect
condition.
>> part of the transport network, but also applies to the other 
>>> G.8121/G.8112/G.8151 (MPLS-TP). This proposed change has 
>>> implications beyond the scope of MPLS-TP and should be addressed in 
>>> Q.9/15, Q.10/15,
>>> Q.11/15 and Q.14/15.
> 
> That is an assumption which you stated as a fact. My earlier mail in 
> this thread was to refute that "fact".
> 
> supporting PDH, Ethernet and ATM services over their MPLS networks for 
> some time.
> 
> MPLS networks do not perform AIS insertion at all.  I am not aware of 
> any suggestion to update the Recommendations you list above as a result.
> 
> There are standards (and I believe deployments) to support PDH 
> services over IP. IP networks do not perform AIS insertion at all.  I 
> am not aware of any suggestion to update the Recommendations you list
above as a result.
> 
> IEEE are the design authority for Ethernet and they saw no need to 
> include AIS in 802.1ag. There are standards (I am not sure of their 
> deployment
> status) to support PDH services over Ethernet. There is equipment (I 
> am not sure of the standardisation status) that supports ATM over 
> Ethernet. I am not aware of any suggestion to update the 
> Recommendations you list above as a result.
> 
> Therefore I must conclude that it is possible to successfully support 
> fault management in PDH, Ethernet and ATM client networks supported by 
> a server network that does not support AIS insertion.
> 
> Therefore I consider your statement that the Recommendations you list 
> above must be updated to be alarmist and misleading.
> 
> Ben
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 5 May 2009 10:36:54 -0700

Hi Maarten,

Isn't it possible for Management system to send the fault information out of band using the NMS/OSS?

-Shahram  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, May 05, 2009 10:30 AM
To: 'George Newsome'
Cc: [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re: AIS/FDI)

George,

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 16:34
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

network.
sink functions.

Regards,
	George

behaviour.
condition.
above as a result.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 20:24:06 +0200

Shahram,

The failures (fXXX) that are declared in a network element are passed to the
NMS via the Management Communication Network (MCN) as described in G.7710.

Besides reporting such failures to NMS, those failures may also activate the
audible and visible indicators (i.e. bells, lamps) in a station independent
of the NMS (i.e. directly under control of the network element's EMF,
specifically clause 7.1.3.4.1/G.7710.

Please have a look at figure 5/G.7710 which illustrates the EMF within its
network element (i.e. connected to transport plane atomic functions,
equipment control functions and message communication function (MCF)).
http://www.itu.int/rec/T-REC-G.7710/en

Figure 7/G.7710 illustrates the fault management processing inside the EMF.
The station alarms (audible/visible indicators) are controlled via the STA
function, network element alarms are controlled via the NEA function and the
Unit alarms via the UNA function. Failures first get a pre-defined Severity
assigned, and then based on this severity the appropriate alarms are
activated.

The alarm suppression must be performed in the network element itself to
prevent that those local station alarms are activated.

Furthermore, alarms are activated between 2 to 3 seconds after detection of
the defect.

A fault in the core of a network will typically result in the interruption
of many services. As a consequence, many T-PE and S-PE nodes that are
scattered aroundin the network will be detect one or more loss of CC
failures. NMS has no chance to provide alarm suppression. That's why all
transport network technologies so far has an alarm suppression maintenance
signal (AIS/FDI) included. AIS/FDI is a low complexity solution to implement
alarm suppression.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 19:37
To: Maarten Vissers; 'George Newsome'
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Hi Maarten,

Isn't it possible for Management system to send the fault information out of
band using the NMS/OSS?

-Shahram  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Tuesday, May 05, 2009 10:30 AM
To: 'George Newsome'
Cc: [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

George,

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]]
Sent: dinsdag 5 mei 2009 16:34
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

network.
sink functions.

Regards,
	George

behaviour.
condition.
above as a result.

---

From: George Newsome <[email-masked]>
Date: Wed, 06 May 2009 14:30:25 -0400

> is only available in the atomic functions.
This all describes what we have done in the past. However, the three 
modes are different and mode appropriate mechanisms must be chosen for each.

It is a pity that you do not seem to be able to look beyond what we have 
done. You must look at what might be, and not be locked into what is. I 
had hoped that my earlier post may have made it easier for you to be 
able to do that.

Looking at how we have partitioned functions has created a rigid 
structure that was very useful for the technologies that we applied it 
to, but is clearly getting in the way.

> instead of in atomic functions in network elements.
This is not a matter of building a better mouse-trap, but a matter of 
treating the co-cs mode slightly differently. Your insistence that 
everything happens in an atomic function is an insistence that all the 
information of importance is carried in the stream, and that is simply 
not the case. I don't really understand this question because an EMF is 
an abstraction that can process anything that we choose, and is not 
limited to what we happen to have have chosen.

Regards,

	George

---

From: <[email-masked]>
Date: Wed, 6 May 2009 19:41:43 +0100

+1 regards Neil 

> [mailto:[email-masked]] On Behalf Of George Newsome
> Sent: 06 May 2009 19:30
> To: Maarten Vissers
> Cc: [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 06 May 2009 23:43:23 +0200

George,

The management of "transport entities" is the same in all technologies,
irrespective of the "forwarding and filtering mode (co-cs, co-ps, cl-ps)"
that is deployed within a "transport entity". 

This understanding is underlying the common definition of atomic functions
and equipment management function in the different technologies (PDH, SDH,
ATM, OTN, Ethernet and T-MPLS (soon MPLS-TP)).

E.g. a "transport entity" can be 
A) disconnected, 
B) misconnected, 
C) interrupted at a server layer,
D) experience some degradation  of the traffic units during the transfer
through the "transport entity"; i.e.:
   D1) value change, 
   D2) order change, 
   D3) timing change,
   D4) delivery of some traffic units to the wrong subset of output ports of
the "transport entity".

CO-CS type "transport entities" (e.g. PDH 2 Mbit/s, SDH VC-n, OTN ODUk)
experience A, B, C, D1 and D3.
CO-PS type "transport entities" (e.g. ATM VC, ATM VP, p2p and p2mp Ethernet
VLAN, MPLS-TP LSP) experience A, B, C, D1, D2, D3.
CL-PS type "transport entities" (e.g. rmp and mp2mp Ethernet VLAN)
experience A, B, C, D1, D2, D3, D4.

The OAM defined for the CO-CS type "transport entities" checks for A, B, C
and D1 type faults.
The OAM defined for the CO-PS type "transport entities" checks for A, B, C,
D1 and D3 type faults.
The OAM defined for the CL-PS type "transport entities" checks for A, B, C,
D1, D3 and D4 type faults.

The checking for fault types A, B, C, D1 and D3 can be performed via
pro-active and on-demand type OAM.
The checking for fault type D4 can only be performed via on-demand type OAM
(i.e. ETH LTM/LTR).

There is no OAM defined to check for fault type D2.

I expect that once the "transport entity" concept has been consistently
introduced into G.800 you will be able to understand the very strong
commonality between the three types of "transport entities" within the
transport network. I agree that you can't get this understanding from the
initial version of G.800.

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: woensdag 6 mei 2009 20:30
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Maarten Vissers wrote:
> George,
> 
> A network element (equipment) consists of Atomic Functions (AF) 
> connected to interface ports and connected to the Equipment Management
Function (EMF).
> In our existing recommendations there is no alarm suppression 
> information available to the EMF within a network element. Alarm 
> suppression information is only available in the atomic functions.
>
This all describes what we have done in the past. However, the three modes
are different and mode appropriate mechanisms must be chosen for each.

It is a pity that you do not seem to be able to look beyond what we have
done. You must look at what might be, and not be locked into what is. I had
hoped that my earlier post may have made it easier for you to be able to do
that.

Looking at how we have partitioned functions has created a rigid structure
that was very useful for the technologies that we applied it to, but is
clearly getting in the way.

> It is always possible to re-invent the wheel... Please describe how 
> you think alarm suppression can be supported in the EMF in network 
> elements instead of in atomic functions in network elements.
>
This is not a matter of building a better mouse-trap, but a matter of
treating the co-cs mode slightly differently. Your insistence that
everything happens in an atomic function is an insistence that all the
information of importance is carried in the stream, and that is simply not
the case. I don't really understand this question because an EMF is an
abstraction that can process anything that we choose, and is not limited to
what we happen to have have chosen.

Regards,

	George

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 6 May 2009 14:52:39 -0700

Hi Maarten,

Could you please clarify, which of the following cases are you advocating that must use AIS ans should be specified in MPLS-TP:

1) A server layer for MPLS-TP (Such as SDH) fails and injects AIS in to MPLS-TP layer
2) An MPLs-TP Trail fails and injects AIS into its clients

Regards,
Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 11:24 AM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re: AIS/FDI)

Shahram,

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 19:37
To: Maarten Vissers; 'George Newsome'
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Hi Maarten,

-Shahram  

-----Original Message-----

George,

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]]
Sent: dinsdag 5 mei 2009 16:34
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

network.
sink functions.

Regards,
	George

behaviour.
condition.
above as a result.

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 6 May 2009 15:22:21 -0700

Hi,

I have the following questions/comments regarding the requirement draft.

Requirements 5 says MPLS-TP must be co-ps with TE capability. Does this mean it MMUST use TE (I hope so)?

   5   MPLS-TP MUST be a connection-oriented packet switching technology
       with traffic engineering capabilities that allow deterministic
       control of the use of network resources.

I also have concern regarding restoration for MPLS-TP restoration as stated in the following requirement:

   55  MPLS-TP MUST provide protection and restoration mechanisms.

Does restoration means backup path is not created in advance and is calculated on the fly? If so it doesn't seem such characterstic is acceptable for a transport network. 

-Shahram

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 May 2009 00:07:41 +0100

Hi Shahram,

>       control of the use of network resources.

The requirements document specifies the requirements for the development of 
protocols for use in MPLS-TP networks (please see the Abstract and 
Introduction).

Your question is therefore a bit off target.

Nothing in this document says what you must deploy (or even implement). It 
says that the protocol solutions developed must be for a connection-oriented 
packet switching technology that has TE capabilities.

Sounds like you want to deploy TE. Sounds like the protocols developed to 
meet requirement 5 will give you what you need.

> Does restoration means backup path is not created in advance and is
> calculated on the fly? If so it doesn't seem such characterstic is
> acceptable for a transport network.

Consider "1+1 forever" protection.
The working fails and the backup is used. And the working is rerouted 
dynamically to restore the desired protection level.
Sounds like a useful transport feature to me.

Cheers,
Adrian

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 6 May 2009 16:14:42 -0700

Hi Adrian,

Thanks. Are you saying that restoration is like 1+1? but in 1+1 you send to both working and protection path and the receiver chooses the bets signal. Could you please define restoration?

Thanks,
Shahram 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 4:08 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP requirements

Hi Shahram,

Cheers,
Adrian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 07 May 2009 00:24:17 +0100

Shahram,

See RFC4427, e.g.

  "LSP/span restoration denotes the paradigm whereby some restoration
   resources may be pre-computed, signaled, and selected a priori, but
   not cross-connected to restore a working LSP/span.  The complete
   establishment of the restoration LSP/span occurs only after a failure
   of the working LSP/span, and requires some additional signaling."

Restoration is deployed in existing transport networks today.

Ben

On 07/05/2009 00:14, "Shahram Davari" <[email-masked]> wrote:

> Hi Adrian,
> 
> Thanks. Are you saying that restoration is like 1+1? but in 1+1 you send to
> both working and protection path and the receiver chooses the bets signal.
> Could you please define restoration?
> 
> Thanks,
> Shahram 
>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 6 May 2009 17:34:11 -0700

Hi Ben,

What is a restoration? Can you give an example? Is it like 1:1 or N:1 protection swithing or is it like FRR? Does it require merging at a node down stream of the fault?

Also the text you quoted says "resources may be pre-computed", not must be pre-computed. Isn't that an issue for MPLS-TP?

-Shahram 

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 4:24 PM
To: Shahram Davari; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP requirements

Shahram,

See RFC4427, e.g.

Ben

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 7 May 2009 08:00:18 +0200

Shahram,

> 1) A server layer for MPLS-TP (Such as SDH) fails and injects AIS in to
MPLS-TP layer

I am advocating that the Server/MPLS-TP Adaptation Sink function inserts
MPLS-TP AIS into each of the MPLS-TP LSPs that are registered on this
adaptation function.

> 2) An MPLs-TP Trail fails and injects AIS into its clients 

If the client is not MPLS-TP (e.g. if the client is PDH, SDH VC-n, ATM VC,
ATM VP, Ethernet VLAN), then the MPLS-TP/Client Adaptation Sink function is
required by the existing PDH, SDH, ATM and Ethernet recommendations to
insert the client specific AIS.

If the client is MPLS-TP, then I am advocating that the MPLS-TP/Client
Adaptation Sink function inserts MPLS-TP LSP-AIS into each of the MPLS-TP
LSPs, or MPLS-TP PW-AIS into each of the MPLS-TP MS-PWs that are registered
on this adaptation function.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: woensdag 6 mei 2009 23:53
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Hi Maarten,

Could you please clarify, which of the following cases are you advocating
that must use AIS ans should be specified in MPLS-TP:

1) A server layer for MPLS-TP (Such as SDH) fails and injects AIS in to
MPLS-TP layer
2) An MPLs-TP Trail fails and injects AIS into its clients

Regards,
Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, May 05, 2009 11:24 AM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Shahram,

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: dinsdag 5 mei 2009 19:37
To: Maarten Vissers; 'George Newsome'
Cc: [email-masked]
Subject: RE: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

Hi Maarten,

-Shahram  

-----Original Message-----

George,

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]]
Sent: dinsdag 5 mei 2009 16:34
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was Re:
AIS/FDI)

network.
sink functions.

Regards,
	George

behaviour.
condition.
above as a result.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 May 2009 10:56:12 +0100

Hi Shahram,

Restoration is an ITU-T term also used in RFC 4427. As it says at the top of 
the MPLS-TP requirements I-D...
   The recovery requirements in this document use the recovery
   terminology defined in RFC 4427 [RFC4427], this is applied to both
   control plane and management plane based operations of MPLS-TP
   transport paths.

Restoration is the process of recovering a path by (usually) signaling a new 
path. Restoration is usually end-to-end.

I'm certainly not saying that restoration is like 1+1 protection. Very 
different in deed.

I do recommend that you read RFC 4427 to get an idea of the terminology and 
function.

> Also the text you quoted says "resources may be pre-computed", not must
> be pre-computed. Isn't that an issue for MPLS-TP?

I don't see why it would be. All depends on how you choose to operate your 
network.
What issue do you see?

Cheers,
Adrian

----- Original Message ----- 
From: "Shahram Davari" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 07, 2009 1:34 AM
Subject: RE: [mpls-tp] MPLS-TP requirements

Hi Ben,

What is a restoration? Can you give an example? Is it like 1:1 or N:1 
protection swithing or is it like FRR? Does it require merging at a node 
down stream of the fault?

Also the text you quoted says "resources may be pre-computed", not must be 
pre-computed. Isn't that an issue for MPLS-TP?

-Shahram

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, May 06, 2009 4:24 PM
To: Shahram Davari; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP requirements

Shahram,

See RFC4427, e.g.

Ben

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 7 May 2009 07:57:57 -0500

Maarten,

I agree with your description of the common nature of the co-cs, co-ps
and cl-ps type "transport entities" from a transport network
perspective. From NM perspective, this common nature enables the
management of the underlying existing technology specific transport
network (PDH, SDH, ATM, OTN, & Ethernet) and future MPLS-TP by a common
NM approach.  

Regards,
Kam 

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Maarten Vissers
> Sent: Wednesday, May 06, 2009 5:43 PM
> To: 'George Newsome'
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Updating ITU-T fault management specs (was
> Re:AIS/FDI)
> 
> George,
> 
>    D4) delivery of some traffic units to the wrong subset of output
ports
> of
> The checking for fault type D4 can only be performed via on-demand
type
> OAM
modes
> had
> hoped that my earlier post may have made it easier for you to be able
to
> do
structure
> information of importance is carried in the stream, and that is simply
not
> abstraction that can process anything that we choose, and is not
limited
> to

---

From: George Newsome <[email-masked]>
Date: Thu, 07 May 2009 09:42:25 -0400

> network (PDH, SDH, ATM, OTN, & Ethernet) and future MPLS-TP by a common
Hi Kam,

Did you really mean that, or did you make a typo? At least your text is 
clearer than Maarten's, which made no sense to me at all.

But I think that you meant: "co-cs, co-ps and cl-ps type "transport 
entities" from a NETWORK MANAGEMENT perspective."

As you well know, the whole point of the management info model is to 
unify the management view of underlying differences, and we have been 
quite successful in doing that. Do not confuse this common operations 
view with underlying identity in the transport plane.

If this is not a typo, can you clarify exactly what you do mean?

Thanks,

	George

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 7 May 2009 12:51:00 -0500

George,

It is not a typo. "From a transport network perspective" is regarding
common definition of atomic functions and common list of things (A, B,
C, and D in Maarten's description) that can happens to a transport
entity. Such commonalities will enable us to define an uniform
management info model more easily.

Regards,
Kam

> Sent: Thursday, May 07, 2009 9:42 AM
> To: Lam, Hing-Kam (Kam)
> Cc: Maarten Vissers; [email-masked]
> >> and equipment management function in the different technologies
(PDH,
> > SDH,
> >> The OAM defined for the CO-CS type "transport entities" checks for
A,
> > B, C
> >> and D1 type faults.
> >> The OAM defined for the CO-PS type "transport entities" checks for
A,
> > B, C,
> >> D1 and D3 type faults.
> >> The OAM defined for the CL-PS type "transport entities" checks for
A,
> > B, C,
> >> transport network. I agree that you can't get this understanding
from
> > the
Re:
> >> done. You must look at what might be, and not be locked into what
is.
> > I
> >> that was very useful for the technologies that we applied it to,
but
> > is