Re: [mpls-tp] Alarm Reporting (aka AIS)

[<[e-mail]>]

Nurit....perhaps you don't read my posts or those of Andy Reid?  We have some considerable expertise/experience in this whole area.  Let me have one more go at repeating the salient points:

AIS comes from the regular time-slice (TDM) co-cs world of PDH.  However, it also requires a permanent binding of a client to a server.  In this mode of network one MUST fill the time-slices (==resource) with something on failure.  AIS happens be a binary all 1s signal because that is just how the original TTL logic failed in the early PDH mux equipment (floated to +5V).

The moment you remove either of the above conditions (ie regular time-slice or permanent client/server binding) then AIS is not only a waste of time but its something else to configure (esp identifying who to send it to...also see below) and go wrong.

AIS is most obviously wrong for the cl-ps mode.....here we don't have a parent connection of child traffic units...the traffic units themselves MUST fully self-formed/sustaining.  AIS would be plain daft here.  It's why IETF have never seen the need for it in IP and IEEE had the good sense to throw it out of Ethernet OAM in 802.1ag....ITU OTOH foolishly kept it in Y.731....but this was largely to satisfy the TCM stuff (which is also a waste of time/money but that is for a somewhat different reason).

I used to think AIS might be useful for the co-ps mode (though it still requires the assumption of permanent client/server binding AND it now requires explicit labelling of every AIS packet => hint not a good idea for reasons that should become clear shortly), but many years ago Andy/I/others discussed this topic in some detail and we reached a unanimous conclusion that AIS is technically completely unnecessary.  Moreover, one is far better off without it for many reasons consequential reasons, eg having to label each traffic unit, something else to go wrong, etc.  All one needs technically in the co-ps mode is the OAM pair CV and BDI functions (however one does these)...this is quite simple to prove.  And this is 'per se'......that is, I am not even considering all the horrors that accompany the TCM ideas.....which BTW is perhaps the self-fulfilling reason to require AIS here (the notification arguments don't hold water as I noted).

BTW - You are starting to discover below why one needs a permanent client/server binding to make AIS viable (even in the co-cs mode), ie one needs a clear knowledge of who to send it to and also require that they 'don't go away'.  If not clear think of the PSTN and some SDH VC4 supporting a large number of 64k link connections with live calls between a pair of PSTN nodes.  Suppose the SDH VC4 path fails.....one can now send AIS towards the 64k access points of the 64k PSTN paths that are affected.  But since users won't be able to communicate anyway they will clear down, ie they will signal path tear-down...one can think of this as the users providing their own 'CV detection' OAM of the DP....sending AIS towards won't help them make that decision!  So after this which access points of the 64k layer network will one send the SDH VC4 AIS to?   Would you send to all the possible access points that might use that failed SDH VC4 path in the future, eg every single PSTN access point in the world?

We should not have AIS in the co-ps mode and we should not have TCM in any mode.....and using TCM as the reason to require AIS (which IMO is the case) is literally quite barking mad.  I hope you can see this now.

regards, Neil

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 08 December 2010 02:06
To: [e-mail]
Cc: Zhao, Peng (NSN - CN/Shanghai)
Subject: [mpls-tp] Alarm Reporting (aka AIS)

Hi,
I have a question about the functionality of Alarm Reporting....
Assuming that there is a failure at a server layer somewhere across the network....and the MEP of the server layer identifies it and needs to ensure that Alarm Reporting is sent to all of the MEPs of the client services that transmit over the failed server...but it may be that some of the client services do not have MEPs....how does the node detecting the server failure knows which client services have MEPs and an Alarm Reporting message needs to be sent to their MEPs and which do not have MEPs and an Alarm Reporting message must not be sent for these client services....(as we would not like to flood the network with unnecessary traffic)....
I hope someone can clarify it to me.
Best regards,
Nurit