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

[<[e-mail]>]

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]<mailto:[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