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

["BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>]

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] <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