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

[Maarten Vissers <[e-mail]>]

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