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

[Alexander Vainshtein <[e-mail]>]

Maarten,
One brief comment that you probably have heard quite a few times from me.

You have said in your response to Andy Reid:
The adaptation sink functions in the transport network technologies not only "can know" this information, they actually "do know" this information.
The problem with MPLS-TP is that, as long as its data plane is aligned with that of MPLS (and it is!) its analog of the "adaptation sink function", namely the ILM entry with the "Pop and Loop" action on a specific label do not have this information. I.e., when MPLS pops a label, it can handle both labeled and unlabeled packets that result from this action. When the resulting packet is labeled, handling of the next label does not depend on the previous one.
And of course handling unlabeled packets (IP as an immediate client of an MPLS-TP LSP) is just as possible and, IMHO, just as relevant...

After writing this, I think (and I apologize that I've only noticed it that late), that IP as an MPLS-TP client that does not have any AIS is a great counter-example to AIS into the clients...

Regards,
     Sasha

From: [e-mail] [mailto:[e-mail]] On Behalf Of Maarten Vissers
Sent: Thursday, December 09, 2010 10:47 AM
To: [e-mail]; [e-mail]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Andy,

In addition to my response yesterday, see below for some further responses...

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 8 December 2010 13:49
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.

[maarten] The adaptation sink functions in the transport network technologies not only "can know" this information, they actually "do know" this information.

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.

[maarten] Please understand that AIS is not carried per timeslot. AIS is carried per client signal, and those client signals are carried in one or more timeslots using justification (either AMP or GMP). This implies in PDH and OTN that the timeslots carry bits with values of 1 (client signal bits with AIS) and 0 (stuff bits). In SDH with its synchronous clocks, timeslot can carry just a stream of 1's because the justification process is overruled; i.e. justification control bits (H1H2, V1V2) carry a special pattern.

[maarten] Please understand that the 'destination of each timeslot' is not preconfigured. What is configured is the mapping of a client signal to one or more timeslots and the TP ID; i.e. the mapping of a client signal to specific bits of the resource and the identifier associated with those bits. In OTN this mapping and identifier information is carried inside the HO OPU overhead, specifically in the MSI bytes. If the OTN would not have been a transport network technology, the mapping and identifier information in the MSI bytes could have been used by the adaptation sink function instead of the preconfigured information.
The mapping and identifier information carried in the MSI bytes is lost whenever there is a HO ODU failure.

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.

[maarten] The MSI bytes in the HO OPU carry the mapping information of client signal bits onto resource bits and the identifier values. The VLAN ID and LSP/PW Label bits carry the mapping information of client signal bits onto resource bits and the identifier value. There is no functional difference as far as I can see. The same type of information is present in both cases. Only the encoding is different; e.g. the identifiers are: TP ID <=> VLAN ID <=> LSP Label <=> PW Label.

[maarten] Please note that there are two types of 'forwarding information' encoded in VLAN frames and there is one type of 'forwarding information' encoded in a LSP or PW packet.

1)      The 12-bit VLAN ID, the 20-bit LSP Label and the 20-bit PW Label fields carry their connection identifiers within the scope of their server trail.

2)      The MAC DA field carries information which may be associated with one or more external (VLAN Access Port) or internal (VLAN MEP or MIP) egress port(s) of the VLAN.
In transport networks the first type of information is preconfigured in the adaptation source and sink functions, and there is a mapping between this information and the connection points and flow points.

[maarten] The second type of information is used in RMP and MP2MP VLANs to optimize the forwarding of frames to the relevant subset of output ports of the RMP/MP2MP VLAN. This information is not stored/preconfigured in ETHx/ETH-m_A functions.

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.

[maarten] TDM adaptation functions do not send AIS to every possible Tributary Port (TP) that could exist on the adaptation function. I.e. the ODUkP/ODUj-21_A_Sk function only sends ODU-AIS for the active TPs, and it does **not** send 80 ODU0-AIS, 40 ODU1-AIS, 10 ODU2-AIS, 10 ODU2e-AIS, 3 ODU3-AIS and 80 ODUflex-AIS signals for the possible TPs on an ODU4P/ODUj-21_A_Sk function.

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.

[maarten] Existing MPLS switches were not designed to support Transport Profile features in general. A subset of existing MPLS switches will be able to support all TP features by means of a new software release, other existing MPLS switches will only be able to support a subset of TP features with a software update, or will be able to support all TP features but without meeting the required performance (e..g can do CC/CV but only for 100 LSPs and only 1 CC/CV per LSP per second). T-MPLS switches were designed to support Transport Profile features, and will be able to support generation and insertion of AIS packets to each configured LSP/PW passing through the input port to a switch.

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.

[maarten] All transport network technology adaptation functions have this as a default capability. This capability is one of the transport network characteristics.

[maarten] As indicated in my response yesterday, packet adaptation functions have been equipped with an AIS insertion enable/disable capability to support operators that do not want to use AIS. Operators that do use AIS will set the AIS insertion to enabled as a client connection independent default for the adaptation function. I.e. there is no specific control required during connection set up as such in those networks. It is only required to configure the matrix connection, and this automatically instantiates the CP/FP and CSP (client specific process) for this connection in the adaptation functions on the node's input and output ports.

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.

[maarten] I hope I have clarified that AIS is an integral (and not 'an additional') capability in transport network technology adaptation sink functions. The set up of LSP and PW matrix connections by e.g. NMS will identify input and output ports and the label values on those ports for this connection. This information is used within the MPLS-TP switch to configure the adaptation functions on the input and output ports.  It could be that some existing MPLS switches can not be upgraded to support this equipment internal configuration... this equipment will in that case not be able to support the full set of TP features, and it will be an operators choice to deploy it within a -TP network or to not deploy it within a -TP network. Existing T-MPLS switches will be able to support the full set of -TP features, including this AIS generation/insertion.

Regards,
Maarten

Hope this clarifies.

Andy