Subject: (ION) Fwd: RFC 2583 on Guidelines for NHC Developers

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 14 May 1999 19:33:14 -0400

Congrats to Rich and Linda on their new RFC!!!

Andy

--------

>To: IETF-Announce: ;
>Subject: RFC 2583 on Guidelines for NHC Developers
>Cc: [email-masked]
>Date: Wed, 12 May 1999 09:15:30 -0700
>From: RFC Editor <[email-masked]>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 2583: 
>
>        Title:	    Guidelines for Next Hop Client (NHC) Developers   
>	Author(s):  R. Carlson, L. Winkler
>        Status:     Informational
>	Date:       May 1999
>        Mailbox:    [email-masked], [email-masked]
>        Pages:      9
>        Characters: 21338
>        Updates/Obsoletes/See Also: None 
>        I-D Tag:    draft-carlson-nhrp-03.txt
>
>        URL:        ftp://ftp.isi.edu/in-notes/rfc2583.txt
>
>This document provides guidelines for developers of the Next Hop
>Resolution Protocol Clients (NHC).  It assumes that the clients are
>directly connected to an ATM based NBMA network.  The same principles
>will apply to clients connected to other types of NBMA networks.  The
>intent is to define the interaction between the NHC code and the
>TCP/IP protocol stack of the local host operating system.  The NHC is
>capable of sending NHRP requests to a Next Hop Resolution Protocol
>Server (NHS) to resolve both inter and intra LIS addresses.  The NHS
>reply may be positive (ACK) indicating a short-cut path is available
>or negative (NAK) indicating that a shortcut is not available and the
>routed path must be used.  The NHC must cache (maintain state) for
>both the ACK and NAK replies in order to use the correct shortcut or
>routed path.  The NAK reply must be cached to avoid making repeated
>requests to the NHS when the routed path is being used.
>
>This document is a product of the Internetworking Over NBMA Working
>Group of the IETF.
>
>This memo provides information for the Internet community.  It does
>not specify an Internet standard of any kind.  Distribution of this
>memo is unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to [email-masked].  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to [email-masked].
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to [email-masked] with the message body 
>help: ways_to_get_rfcs.  For example:
>
>        To: [email-masked]
>        Subject: getting rfcs
>
>        help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to [email-masked].  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.echo 
>Submissions for Requests for Comments should be sent to
>[email-masked].  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>Joyce K. Reynolds and Alegre Ramos
>USC/Information Sciences Institute
>
>...
>
>Below is the data which will enable a MIME compliant Mail Reader 
>implementation to automatically retrieve the ASCII version
>of the RFCs.
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>RETRIEVE: rfc
>DOC-ID: rfc2583
>
><ftp://ftp.isi.edu/in-notes/rfc2583.txt>

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.