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

From: Charles Monia <[email-masked]>
Date: Wed, 23 May 2001 15:53:28 -0700

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: [email-masked]
voice: (408) 519-3986
fax:   (408) 435-8385

---

From: [email-masked]
Date: Fri, 25 May 2001 17:42:53 -0400

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:[email-masked]]
> Sent:	Wednesday, May 23, 2001 6:53 PM
> To:	Ips (E-mail)
> Subject:	Common Encapsulation:  Stale Frame Detection in an IP fabric
> 
> Hi:
>

---

From: Charles Monia <[email-masked]>
Date: Fri, 25 May 2001 18:49:06 -0700

Hi David:

How do you see clock synchronization happening? Does the FCIP end point use
an SNTP handshake?

Charles
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 2:43 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Common Encapsulation: Stale Frame Detection in 
> an IP fabric
> 
>

---

From: [email-masked]
Date: Wed, 30 May 2001 21:37:07 -0400

Something like that.  If the two endpoints can
agree on a common timebase and control their
relative drift, that's good enough to detect
stale FC frames even if the timebase doesn't correspond
to a wall clock.  I'm wondering about situations
in which an FCIP box is deployed into a situation
where there isn't a good SNTP source available.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> Sent:	Friday, May 25, 2001 9:49 PM
> To:	[email-masked]
> Subject:	RE: Common Encapsulation:  Stale Frame Detection in an IP
> fabric
> 
> Hi David:
>