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

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 8 Dec 2010 03:05:43 +0100

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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 08 Dec 2010 08:16:52 +0100

Nurit,

In MPLS-TP all transport paths are monitored and will have MEPs. 

Regards,

Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 8 December 2010 03:06
To: [email-masked]
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)..

Best regards,

Nurit

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 08:37:14 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 08 December 2010 02:06
To: [email-masked]
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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 8 Dec 2010 12:05:47 +0200

Maarten,
Could you please point to specific statements in the already published, or approved for publication MPLS-TP standards that confirm this statement?

Until now, I have been under the impression (possibly, a wrong one) that setting up MEPs at the end point of the transport entities is at the discretion of the operator.  And, at the very least, that nothing prevents the operator from disabling these MEPs.

BTW, this is one more example of the differences between the SONET/SDH-based traffic networks (where the OAM headers are inherently generated and terminated for each transport entity) and packet-based networks where OAM uses dedicated packets which would not be transmitted until somebody explicitly injects them into the traffic path, and can be silently discarded upon reception if you decided to do that.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Wednesday, December 08, 2010 9:17 AM
To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; [email-masked]
Cc: 'Zhao, Peng (NSN - CN/Shanghai)'
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Nurit,

Regards,
Maarten

Hi,

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 12:48:53 +0000

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: +44 (0)20 8726 3075
Mobile: +44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:  [email-masked]<mailto:[email-masked]>
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

Hi,

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 8 Dec 2010 10:47:37 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, December 08, 2010 7:49 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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 

Office: +44 (0)20 8726 3075 
Mobile: +44 (0)7917 025451 
Fax :       +44 (0)1277 324015 
Email:  [email-masked] <mailto:[email-masked]>  
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. 

	 

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

	Hi,

	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)....

	Best regards,

	Nurit

---

From: George Newsome <[email-masked]>
Date: Wed, 08 Dec 2010 11:04:49 -0500

Deborah,

Your caveat's (particularly "no future plans ........") sound quite 
unsafe to me.

Surely, if AIS is optional and large networks can be operated quite 
happily without it, the prudent thing to do is bite the bullet and live 
without it in all cases?

Regards,

	George

On 12/8/2010 10:47 AM, BRUNGARD, DEBORAH A (ATTLABS) wrote:
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 8 Dec 2010 11:16:34 -0500

Hi George,

As you know:-), not all operators operate the same way. I just don't
want to mis-lead users of our work. I've already had many questions both
internally and externally on digesting the bullet (Y1731 clauses).
Anything that can be added to help clarify will be useful.

Deborah

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: Wednesday, December 08, 2010 11:05 AM
To: BRUNGARD, DEBORAH A (ATTLABS)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Deborah,

Regards,

	George

---

From: "t.petch" <[email-masked]>
Date: Wed, 8 Dec 2010 18:02:53 +0100

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 08 December 2010 02:06
To: [email-masked]
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

--------------------------------------------------------------------------------

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 8 Dec 2010 21:01:07 +0200

Tom,
... snipping to the key statement in your email...
==============================
     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.
==============================
... snipped to the end ...

Support!!!

My 2c,
     Sasha

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 8 Dec 2010 12:05:45 -0800

Concur with Tom and Sasha.
And if there's no signal, then, as I think of it, there's no SD in packet
layer network.

Regards,
Greg

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 08 Dec 2010 21:58:25 +0100

Andy,

Adaptation Sink functions in transport networks have a configured set of connection points or flow points. Timeslots, labels and VIDs are associated with those CPs/FPs. Bits arriving on timeslots that are not associated with any of the configured CPs will be discarded, frames arriving with VIDs that are not associated with any of the configured FPs will be discarded, packets arriving with labels that are not associated with any of the configured CPs will be discarded. This discarding of bits/frames/packets with unexpected identifiers is one of the basic security mechanisms in transport networks, and prevents that unintended traffic can enter a conection.

The information that controls this discarding is reused to controle the generation of AIS. I.e. AIS is generated for each configured and active CP/FP. As a result each adaptation sink function will be able to insert AIS within the set of client connections passing through the function; and it will be able to do so for just those client connections. 

This design is as such the same for circuit and packet transport technologies. I.e. It is not 'fundamentially different to TDM AIS' as you were thinking. AIS insertion in OTN requires dedicated hardware to generate the ODU AIS signal with its frequency +/- 20 ppm tolerance. This is more complex than generating AIS frames or AIS packets. TDM AIS is as such not longer insertion of an all-1s stream.

In packet transport network technologies (ATM, Ethernet, MPLSTP), AIS insertion on each of these configured/active client connections can be enabled/disabled by the operator. Most operators operate with AIS insertion enabled. 

Some operators operate it with AIS insertion disabled. In this latter case the operator has to deploy other alarm suppression methods and has to have a DCN and NMS that can handle the alarm storms; furthermore in multi operator connections alarm suppression information has to be forwarded from the first operator to the second operator via network management or control plane... a complication which is unnecessary when using AIS in the data plane.

M.vr.gr.
Maarten

Op 8 dec. 2010 om 13:48 heeft [email-masked] het volgende geschreven:

> 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 informatie 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.
>  
> Email:  [email-masked] 
> WWW:    http://www.bt.com/
> 
> 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)….
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 08 Dec 2010 22:19:45 +0100

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)" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 08 Dec 2010 22:50:32 +0100

Hi,

In the Stockholm meeting I proposed to change "Signal"
into "Service" and use the same acronyms, but the response
was that delivering packets is not a service.

So how about TL (total loss) and PL (partial loss).

Just my 2 euroc.

Regards, Huub.

==============

> And if there's no signal, then, as I think of it, there's no SD in
> packet layer network.
>
> Regards,
> Greg
>
> On Wed, Dec 8, 2010 at 11:01 AM, Alexander Vainshtein
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Tom,

-- 
*****************************************************************
                          我爱外点一七三一

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 12:06:53 +0000

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

> From: t.petch [mailto:[email-masked]] 
> Sent: 08 December 2010 17:03
> To: Harrison,N,Neil,DKQ7 R; [email-masked]
> 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
> 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
> 
> "When the server layer trail termination sink asserts signal 
> fail, it notifies the server/MT_A_Sk function that raises the 
> aAIS consequent action.  "
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> 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)....