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

[Charles Monia <cmonia@NishanSystems.com>]

Hi Ralph:

Thanks for the feedback.

I agree with your comments on the straw man. I will prepare an individual
submittal proposing the exact textual changes to the common encapsulation
spec.

Charles

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Tuesday, June 12, 2001 6:23 PM
> To: Ips (E-mail)
> Cc: Charles Monia
> Subject: Re: Common Encapsulation: Stale Frame Detection in 
> an IP fabric
> 
> 
> 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...
>