Re: Common Encapsulation: Stale Frame Detection in an IP fabric

[Ralph Weber <ralphoweber@compuserve.com>]

Charles,

Sorry to take so long responding, only now am I catching
up on the complex issues.

First, I would have to answer "yes" to the following
question from David Black:

  "Is there any interest in just synchronizing the
  timestamps between the two ends of an FCIP link
  without requiring interaction with an external
  time source?"

Such a capability would be very useful to FCIP implementations
where the IP Network lacks an SNTP server.

David raises the further question:

  "A possible downside is that an implementation
  that can support multiple FCIP links may need
  to maintain a separate time offset (from its
  internal time source) for each FCIP link."

I see this "downside" as a fact of life requirement
since the FCIP device has no way of knowing if the
time offset is identical for two links.  At a minimum
the FCIP device would have to interrogate each link
to verify its time offset.  Having gone to that much
trouble, I see no reason why the discovered values
would not be maintained separately.

>From my perspective, the downside issues for David's
proposal are as follows:

  1) The common encapsulation draft will need to
     recognize the two mechanisms for handling
     time.  Since a common flag bit has already
     been proposed for "time valid" the simplest
     method for recognizing both time mechanisms
     would be to have one "valid flag" bit for
     each.

  2) It seems likely that an efficient implementation
     of David's proposal would not use the SNTP time
     format.  This possibility would have to be dealt
     with in the common encapsulation draft.

  3) The mechanism non-SNTP-server mechanism for
     determining the offset time would have to be
     specified somewhere.  Past implementations
     have used FC frames for this purpose, and
     that suggests that the mechanism would not
     be specified in the common encapsulation draft.

     However, I can imagine trying to shoe-horn
     such a capability in to common encapsulation
     header.  I think it is a bad idea since a
     possible result is common encapsulation
     headers that do not encapsulate FC frames.
     But maybe I have missed something here.

Despite these downside issue, I still think a one-link
end-to-end time stamp is a good idea.  Anybody else agree?


Turning to Charles' 23 May proposal I think it is
generally complete and could be added to the common
encapsulation draft without too much trouble.  My
concerns are as follows:

 11) I am not certain exactly what parts of the
     proposal are intended to go in the common
     encapsulation draft or where they are
     intended to go.

 12) I do not understand the purpose of the text
     near the end of the proposal, beginning with
     "Setting the enforcement time limit."  It seems
     to me that the encapsulation element should be
     told exactly one upper limit value for the
     IP Network transit time of an encapsulated frame.
     This time limit should be provided by the
     'Fibre Channel' component of which the
     encapsulation element is a part.  For example,
     an FC Switch would set a time limit based on
     its determination of how R_A_TOV is to be
     divided for a given FC Fabric routing.
     I believe the discussion of E_D_TOV and
     R_A_TOV should not be included in the
     common encapsulation draft.

 13) I believe that the following needs to be reworded:

     "d)  If the incoming frame has a non-zero time stamp,
     the receiving node shall compute the time in flight
     and compare it against the limit specified for the IP
     fabric."

     I think it would be better to drop the "IP fabric"
     since that term is specific to only one of the
     users of the common encapsulation.  I also would
     prefer not to have "receiving node" in the wording
     because that concept has no definition in the
     common encapsulation draft.  I would suggest:

     "d)  If an encapsulation header contains a non zero
     value in the Time Stamp [integer] field, the time
     in flight SHALL be computed by subtracting the
     reference time from the Time Stamp [integer] and
     Time Stamp [fraction] fields."

Quite probably similar wording changes are needed elsewhere
in the proposal.

Thanks.

Ralph...


On 23 May 2001 Charles Monia wrote:

>
> Hi:
>
> This note is a strawman proposal for detecting stale FC frames using the
> features present in the common encapsulation specification.
>
> The spec includes provisions for time tagging a frame in order to detect
> frames that have exceeded the lifetime guarantees expected of a Fibre
> Channel fabric (R_A_TOV).
>
> A fibre channel fabric must guarantee that the maximum time in flight for
> any frame will not exceed the limit specified by the R_A_TOV parameter. In
> FC fabrics, R_A_TOV is defined by the fabric and supplied to the N_PORT in
> the fabric login 'accept' response.  The default value is 10 seconds.
> Failure to meet this guarantee may result in stale frames associated with
> defunct transactions.  These frames, if received outside the R_A_TOV window,
> could cause failures and data corruption.
>
> In a closed FC fabric, the R_A_TOV limit is guaranteed by switch element
> design and control of the fabric topology.  There is no enforcement
> mechanism. In contrast, such control may not be possible in an IP fabric.
> In most cases, the IP network will, almost certainly, consist of
> heterogeneous components and the user cannot be assumed to have full control
> over the infrastructure and its topology.  For that reason some explicit way
> to enforce the flight time guarantee must be provided. The FC frame
> encapsulation format provides the means for this enforcement at the edges of
> the IP network by allocating space for a time stamp which is applied when
> the frame is injected into the IP network and may be checked by the
> receiving node.
>
> The following is a proposal for managing time base synchronization at the
> TCP end nodes.
>
> The protocol for synchronizing an end node time base is SNTP. In order to
> insure that all nodes are time-aligned, they should obtain the address of a
> reference SNTP server via a hard-wired address or by querying an appropriate
> repository via SLP or some other protocol.  If multiple SNTP server
> addresses are provided, the servers must be synchronized. Alternatively, a
> multicast group address may be used in support of operation in Anycast mode.
> Implementation of Anycast mode is as specified in RFC 2030, including the
> precautions defined in that document.  Multicast mode should not be used.
>
> An SNTP server may use any one of the time reference sources listed in RFC
> 2030. The resolution of the time reference MUST be 125 milliseconds or
> better.
>
> If support for stale frame detection by a node is optional,  a node that
> does not enforce the flight time limit shall set the time stamp field in the
> encapsulation header of an outgoing frame to 0,0 and shall ignore the
> contents of the timestamp for incoming frames.  A node that supports stale
> frame detection shall implement the time stamp with a precision of 0.125
> seconds or better.
>
> With regard to the time base, the node is in either the synchronized or
> unsychronized state.  When in the unsynhronized state, the node shall
>
> a)  Set the time stamp field to 0,0 for all outgoing frames
> b)  Ignore the time stamp field for all incoming frames.
>
> When in the synchronized state, the node shall:
>
> a)  Set the time stamp field for each outgoing frame in accordance with the
> node's internal time base
> b)  Check the time stamp field of each incoming frame.
> c)  If the incoming frame has a time stamp of 0,0, the receiving node shall
> not test the frame to determine if it is stale.
> d)  If the incoming frame has a non-zero time stamp, the receiving node
> shall compute the time in flight and compare it against the limit specified
> for the IP fabric.
> e)  If the result in step (d) exceeds the enforcement time limit, the frame
> shall be discarded.  Otherwise, the frame shall be accepted.
>
> A node enters the synchronized state upon receiving a successful response to
> an SNTP query.
>
> A node shall enter the unsynchronized state:
>
> a)  Upon power up and before the succesful completion of an SNTP query
> b)  When an unsuccesful SNTP query occurs.
>
> Setting the enforcement time limit.
>
> In general,
>
> 2* E_D_TOV < Stale Frame time limit < R_A_TOV
>
> Where E_D_TOV is the FC time limit between expected events such as the
> arrival of two successive frames in a sequence.
>
> A rule of thumb for the stale frame time limit is  .5 * R_A_TOV.
>
> Charles
>
> Charles Monia
> Senior Technology Consultant
> Nishan Systems
> email: cmonia@nishansystems.com
> voice: (408) 519-3986
> fax:   (408) 435-8385