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

Hi Tom...apologies for late response.  Your are essentially correct, and it is one of the key difference between the co-cs and co-ps modes that makes this so.  In the co-cs mode based on regular time-slices of resource one simply has to fill the configured duration (==bits) with bits....all 1s from PDH/TTL logic history....note we do NOT have to form labelled traffic units here.  This is quite unlike the co-ps mode based on irregular time slices of resource....here we don't have an a priori fixed resource slot and we have to create fully formed and labelled pkts.  Now all the issues I and Andy Reid follow from this.

regards, Neil

> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com] 
> Sent: 08 December 2010 17:03
> To: Harrison,N,Neil,DKQ7 R; mpls-tp@ietf.org
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
> 
> ----- Original Message -----
> From: <neil.2.harrison@bt.com>
> To: <nurit.sprecher@nsn.com>om>; <mpls-tp@ietf.org>
> Cc: <peng.zhao@nsn.com>
> Sent: Wednesday, December 08, 2010 9:37 AM
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
> 
> 
> 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.
> 
> <tp>
> 
> Neil
> 
> I notice that the recently liaised G.tpoam defines AIS as
> 
> "When the server layer trail termination sink asserts signal 
> fail, it notifies the server/MT_A_Sk function that raises the 
> aAIS consequent action.  "
> 
> Perhaps we should note that in a packet layer network, there 
> is no signal and so
> 
> signal fail can never be asserted so AIS is a null condition. 
>  In which case, G.tpoam is spot on.
> 
> Tom Petch
> 
> </tp>
> regards, Neil
> 
> ________________________________
> From: mpls-tp-bounces@ietf.org 
> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 08 December 2010 02:06
> To: mpls-tp@ietf.org
> 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
> 
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> 
> > _______________________________________________
> > mpls-tp mailing list
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> 
> 