Cell Relay Archive

[Manish Kumar <manish@npi.stpn.soft.net>]

Patrick Hurley wrote:

> It is my understanding according to I.610 that F4,F5 performance flows
>
> are used to identify performance issues at the VPC/VCC level. I
> downloaded the Word document from ITU.

That's right.
F4 flow - Virtual Path level monitoring.
F5 flow - Virtual Channel level monitoring.
which together address the requirements of ATM layer performance
monitoring of (VP/VC)channels.


> I realize not all manufacturers have implemented all recommendations
> of
> I.610.

Well, this info is new to me and its a pity that many manufacturers are
still lagging behind in its implementation. The I.610 recommendation was
there in the first set of B-ISDN recommendations approved by ITU-T, way
back in 1990. So, it is nothing new. But it was revised somewhere in
1995 - (that is to the best of my recollection).

> Also, I understand that the recommendations can be interpreted
> differently and certain functions are left out when a switch is
> manufactured so it can get to market.

I disagree with the fact that, the recommendation I.610 can be
interpreted differently due to inherent fuzziness or any other reason.
All its clauses are well framed and very clear.  So, this cannot be an
excuse for non-implementation. Of course there are some aspects that
have been merely touched and left for further study (One such thing is
the brevity with which the recommendation talks of non-intrusive
monitoring is mentioned - but even this is standardized now). The second
reason mentioned by you is more acceptable, as VP/VC performance
monitoring is not critical to the deployment of the switch and as the
performance of the various protocol entities in the ATM stack do not
depend on the presence of F4/F5 flows. Hence some folks may have rushed
in the market without F4/F5 support.

The other reasons for non-implementation could be -
1) The non availability of a standard "monitor object" to model F4/F5
functions in the systems information model (MIB). But this is a relevant
excuse only if your switch supports OSS. But, now as I gather this has
also been defined by ITU-T in one of its recommendations.

2) w.r.t. the Functional Model of ATM transport networks - the position
(implementation/ Interpretation) of  F4/F5 flows is still "for futher
study"(as per my last knowledge which is not very old). And frankly
speaking I do not know why? Its finalization should not be difficult.

But, I firmly believe that F4/F5 flow support can be implemented without
these. The availability of these documents only helps.

> I know a particular vendor of
> routers does not have F4,F5 implemented as an example.

That may be possible as - performace monitoring of ATM layer channels
becomes more and more important as you move towards high b/w backbones
switching upto 100s of gigs. Plus interoperability issues dictate the
mandatory implementation of F4/F5 flows (ATM forums - B-ICI specs). In a
small private network one may get away without implementing it. But
then, I do not know what the operator does if a customer starts cribbing
about performance degradation.


> So what are the flavors of actual functions, with regard to OAM F4,F5
> flows, among real ATM devices (routers/switches) today?

In my opinion switches of today should have no problem in supporting the
following F4/F5 functions with complete interoperability and compliance
with the standards laid down (And I know of a couple of manufacturers
who have done so) :
All points are applicable for both F4 and F5 flows -
1) flow activation using activate cell.
2) the support of forward monitoring cell functions.
3) the support of backward reporting cell functions.
4) flow deactivation using deactivate cell (similar to activate cell).
5) support for non - intrusive monitoring.
6) OSS support for F4/F5 functions (standard monitor object defined).

FYI - most of the IC manufacturers for ATM also support F4/F5 functions
in their cell processor chips.

In case - any further clarifications are required you may feel free to
send a personal mail to me or directly to the mailing list).

Regards,
Manish Kumar.

> --
> Patrick Hurley