The IP over ATM Mailing List Archive by date

["Uttam Shikarpur" <uttam@zk3.dec.com>]

>On Thu, 22 Sep 1994, Annie Wang wrote:
> I have implemented the RFC1577 on HPUX.  It is up and running fine.
>
>Great!  Maybe we can get you hooked up to Xerox PARC?
>
>>    Does this means while establishing a PVC, a InARP_REQUEST should be sent
>>    through this PVC to remote before adding a new entry to ATMARP table ?
>
>This is a good question.  I would assume that the entry would need
>to be added to the table first as both ends of the PVC are never set
>up at the same time and there's a chick and egg problem otherwise.


          At the point of establishing this PVC we have no information
          about the end point. InARP is neccessary to establish the IP address
	  of the remote system. Its only after we get a response to an InARP
          do we know its IP address and thus can establish an entry. 

          In the DEC OSF/1 implementation, we do not create an entry
          until we receive a response from the remote end. Once a PVC
          is created we keep trying every 'n' seconds (sending InARPs) till 
	  we get a response. When we get a response
          an entry is created, and the normal aging rules apply.


>    What should be done if there is no InARP_REPLY comming back from remote ?
>    Should the new ATMARP entry be removed and the PVC be closed ??
>
>The PVC section was contributed by the "ad hoc pvc committee" at the
>Amsterdam IETF meeting from July 1993.  It would be helpful if one
>the committee members helps by recollecting from the meeting.  If
>not reply is received, then it is implementation dependent on what
>need be done.  Invalidating the PVC is one option, logging the 
>condition is another, closing the PVC is another.  I'm curious as
>to what other implementations have done here.  Clearly we need to
>augment this item in the rewrite.

	PVCs being permanent in nature always exist. As stated above
	our end system tries to InARP on the PVC till a response
	is received. In the situation where we have established an entry,
	but when we revalidate we get no response, the entry is marked STALE
	till we can successfully InARP on that VC. Since the PVC exists
	and there is an entry, the entry is not deleted but marked STALE.
	If the PVC is specifically deleted, then ofcourse, the entry will
	also be deleted, assuming no other VCs are associated with that entry.
	

> 2. On p.8, it says "It is the responsibility of each IP station supporting 
>    PVCs to revalidate [ATM]ARP table entries as part of the aging process."
> 
>    The question is - should a PVC be closed and the related ATMARP entry
>    be deleted, if the ATMARP detects a PVC being invalided (ie. aged) due to 
>    the remote having no response to the InARP_REQUEST ??

> PS. Currently my implementation is to close the PVC and delete the 
>     related ATMARP entry when a PVC is detected to be aged.  But this
>     seems in conflict with the PVC definition.
>
>But this also seems to be against the notion that PVCs are permanent.
>We probably want to invalidate the PVC from being used for further
>routing considerations (unreachable vs black hole), but if I were
>depending on PVCs being permanently configured, I wouldn't want them
>disappearing on me.
>
>The Bay Area Gigabit testbed was configured using an all PVC mesh.
>We planned on roughly 90 hosts or so in the network.  Hosts come and 
>go on the network following the experimental nature. Imagine a host
>goes away for a little while, comes back up and can't talk to the
>host it was just communicating with because the permanent configuration
>was not permanent.  Deleting the PVCs seems to be not the best
>solution.        
>
>Mark




While on this subject I have a question:


RFC 1577 states:

   In the case of an invalidated entry and
   an open VC, the ATMARP client must revalidate the entry prior to
   transmitting any non address resolution traffic on that VC. In the
   case of a PVC, the client validates the entry by transmitting an
   InARP_REQUEST and updating the entry on receipt of an InARP_REPLY. In
   the case of an SVC, the client validates the entry by transmitting an
   ARP_REQUEST to the ATMARP Server and updating the entry on receipt of
   an ARP_REPLY.

Question:
        If we were doing a file transfer between 2 stations and our
        entry got invalidated, does this mean that we suspend this
        transfer of data, validate the entry and then continue with
        the transfer? Is my reading of this correct?




Thanks!
Uttam Shikarpur