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

[Maarten Vissers <[e-mail]>]

Deborah, 

IEEE did not include AIS in 802.1ag because 802.1Q mandates the use of spanning tree protocols, which will cause that the all VLANs passing through the failed server trail are taken away from this trail; i.e. all ETH flow points on the adaptation Sink function are removed, and there is no longer a connection on which ETH AIS can be inserted.

The same situation exists in SDH and OTN networks that operate with an ASON control plane which controls restoration of the VCn and ODUk connections. If a server trail fails, control plane will remove the VCn or ODUk configuration from the adaptation sink function, and AIS insertion is stopped, or not started (if control plane is very fast). In an OTN in which all ODUk connections are restorable by ASON within 2 seconds, it is not necessary to support ODU AIS. Each ODUk connection will be restored before the continuity failures would be declared.

Regards,
Maarten

Op 8 dec. 2010 om 16:47 heeft "BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]> het volgende geschreven:

> Agree with Neil and Andy – we discussed this at great length during Y1731 development (and in IEEE which did not include it). If AIS is supported for MPLS-TP, it should be optional and the document should contain similar warnings on its use as in Y1731. Its use is for very constrained (1:1 client/server) architectures (where the operator has total visibility/control of the e-2-e transport/equipment to ensure it is constrained and they no future plans for introducing more flexible packet transport for the client transport anywhere along the e-2-e path). If one has a mixture of transport alternatives in their network, one will have to evaluate each MEP’s application before putting into service and while in-service (possible on small networks, impossible for large networks). The danger is, if wrongly configured, one could have an AIS indication to a customer while the customer is still receiving traffic. So the customer will be able to claim service unavailability. This is not the SDH/PDH AIS use/mechanism (as Andy and Neil say). And other mechanisms exist which are much more reliable.
> 
>  
> 
> Deborah
> 
>  
> 
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Wednesday, December 08, 2010 7:49 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
> 
>  
> 
> Nurit,
> 
>  
> 
> I know Neil has replied. I will try and say the same thing in my own words.
> 
>  
> 
> The server does not and must not know the nature of the client traffic. If it does, this creates a dependency between the server layer functionality and its clients which mean that either (1) all future clients must conform to the same dependency or (2) the server needs to be changed to accommodate new clients. Personally, I prefer to take independency as defining of client/server.
> 
>  
> 
> The server can and should know about failures which interrupt or otherwise affect the transport of the client information across the server network (a MEP which is part of the termination function). So the server can pass up to the client layer an alarm condition, however, the server cannot know how to forward on this information to downstream nodes in the client layer. This is a truism arising out of the independency between client and server.
> 
>  
> 
> However, as Maarten correctly pointed out, an adaptation function can know this information. The adaptation is not part of the server layer and can be specific to each client. It is the client layer's "stub" to interface to the server layer.
> 
>  
> 
> Within the TDM world, the destination of each timeslot is *preconfigured* as an inherent part of the connection set up process and the forwarding of each timeslot is predetermined by this preconfiguration. As such, each timeslot does not carry any forwarding information. This means that the adaptation function can fill each timeslot with the alarm condition (AIS) without any knowledge of downstream forwarding - the adaptation function has no dependency on any forwarding information. This makes the implementation of AIS in TDM simple and highly reliable.
> 
>  
> 
> However, as Neil points out, this is not the case with packets. With packets, forwarding information is carried in the header of each packet with downstream forwarding is fundamentally based on this information. This information is lost whenever there is a server layer failure.  **Therefore the adaptation function cannot insert the alarm condition without itself having a prior knowledge of this forwarding information.** This is fundamentally different to the TDM case and arises from the very definition of packets.
> 
>  
> 
> So how can this be achieved. There are three alternatives, none attractive. Nor do I believe there is total clarity between two of these, what is actually proposed for MPLS-TP.
> 
>  
> 
> 1) The direct analogy with TDM would be for the adaptation function to systematically send an AIS packet to every possible label value. Given the size of the MPLS label space, this is not remotely practical.
> 
>  
> 
> 2) Implement the AIS as an integral and required part of each and every packet forwarding engine. As the forwarding engine is configured with the forwarding information as part of any connection set process (signalled or NMS), this requires no more configuration than the TDM case. However, there are two immediate drawbacks to this. First, as I'm aware the current installed based of MPLS switches are neither designed nor configured to automatically add an AIS packet flow to each configured LSP passing through an input port to the switch. Moreover, it requires that the forwarding semantics carry input (server sink) port information.
> 
>  
> 
> 3) Implement the AIS as an additional capability within the adaptation function. However, this now needs to be configured with the correct forwarding information (ie a set of active label values). If the AIS is not an integral part of the connection set up process, this configuration information will need to be separately calculated and configured (for example by snooping) which means that the tie back of this information to the connection set up information can itself now be error/fault prone. Moreover, errors in the configuration data are unlikely to become apparent until there is a server layer failure and the AIS insertion is exercised. This means that inevitably, at the time of a failure downstream cannot have full confidence in the AIS information. Moreover, some adaptation may not be configured at all, and so a client path failure with a lack of AIS will be an especially untrustworthy condition. This is fundamentally different to the highly reliable AIS of the TDM world.
> 
>  
> 
> In practice, I'm sure we are talking about the third of these, which as I point out, from the practical operational point of view, is fundamentally different to TDM AIS as it is trustworthy in the same way. Sometimes, especially when talking with Maarten, I think he is referring to the second of these (and I may be wrong), which while operationally more reliable, I don't think is realistic.
> 
>  
> 
> Hope this clarifies.
> 
>  
> 
> Andy
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Andy Reid 
> Chief Network Services Strategist 
> BT Innovate 
>                                                                                            
> Office: [phone] 
> Mobile: [phone] 
> Fax :       [phone] 
> Email:  [e-mail] 
> WWW:    http://www.bt.com/
> 
> This email contains BT information, which may be privileged or confidential. 
> It's meant only for the individual(s) or entity named above. If you're not the intended 
> recipient, note that disclosing, copying, distributing or using this information 
> is prohibited. If you've received this email in error, please let me know immediately 
> on the email address above. Thank you. 
> We monitor our email system, and may record your emails.
> 
> British Telecommunications plc 
> Registered office: 81 Newgate Street London EC1A 7AJ 
> Registered in England no: 1800000
> 
>  
> 
>  
> 
> 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
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp