RE: FCEncap Last Call Comment 39

["Murali Rajagopal" <muralir@cox.net>]

Mallikarjun:

There are two concepts here mixed up. Synchronization and Stale Frames. They
could be related. I think you email queries seems to be focussing on the
later. The FC Encap is a (and should be left at that) mechnsim to simply
"encapsulate and transport" frames. Any other requirements should be made
part of the protocol documents.

Hope that helps.

-Murali

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ralph Weber
Sent: Monday, April 01, 2002 7:55 PM
To: Mallikarjun C.
Cc: IPS Reflector
Subject: Re: FCEncap Last Call Comment 39


Mallikarjun,

Because FCIP is in one form or another (and there are at
least two forms) a connection between two FC Switches and
because FC Switches exchange Class F frames frequently,
it is not possible to "bar" Unsynchronized operation
using exactly those words.

The requirement stated in FC-BB-2 is that the receiver
shall discard all non Class F frames received while in
the Unsynchronized state (or words that have the same
effect). This is equivalent to assuming that R_A_TOV
is not met for non Class F frames whenever it cannot
be proved that R_A_TOV has been met.

I believe that this is sufficient to allow to to sleep
tonight.

Thanks.

Ralph...

"Mallikarjun C." wrote:

> Ralph,
>
> Thanks for the clarification, I didn't know about Class F
> frames.
>
> Now that I am aware of Class F frames, I am interested in knowing
> if the authors considered barring Unsynchronized operation with the
> exception of Class F frames (or perhaps "in all cases where the R_A_TOV
> expectaction is not imposed by FC-FS").
>
> I guess it still bothers me that the wording is not restrictive enough to
> rule out surprise class 2/3 frames that should have long gone....