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

[Black_David@emc.com]

Question for Charles and the WG:

This proposal is based on synchronizing each node
to the same wall clock reference (i.e., SNTP server).
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?

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.

NOTE: This is a question and not to be taken
as a suggestion from a co-chair.

Thanks,
--David

> -----Original Message-----
> From:	Charles Monia [SMTP:cmonia@NishanSystems.com]
> Sent:	Wednesday, May 23, 2001 6:53 PM
> To:	Ips (E-mail)
> Subject:	Common Encapsulation:  Stale Frame Detection in an IP fabric
> 
> 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