rfc1223.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


   assigned to them so that we won't run out when 256 protocols turn up.
   Any interested party could obtain a protocol number or numbers by
   application to NSC.  In this document, protocol types specific to OSI
   LLC1 are assigned.  Specifically, the sixteen bit value 0x0B01 in
   bytes 8 and 9 shall identify LLC1 packets.

True Unit

   This field is used to handle addressing outside of the local domain
   and network.  For compatibility with previous NSC hardware, one may
   not put the destination unit number in the TO Unit field if the
   destination domain or network are not the local ones.  In that case,
   one puts zero in the TO Unit field, and puts the destination Unit
   number into the TRUE unit field.  NSC Link devices will adjust the
   message when it arrives at the destination domain and network so that
   the destination unit number appears in the TO Unit field.

Age Count

   This field serves as a "time to live" in that it prevents datagrams
   from endlessly circulating about in an improperly configured network.
   Each time a message with this format passes through a bridge, the Age
   Count is decremented by one.  When the result is zero, the message is
   discarded by the bridge. Therefore, this byte should be set to 255
   when a message is originated, and ignored when a message is received.

Next Header Offset and Header End Offset

   These fields are used by the hardware to determine if any special
   addressing is present.  No special addressing forms are permitted in
   conjunction with LLC1.  Therefore, these fields shall always be set
   to 16.  Receivers may count on the LLC1 information beginning at
   offset 16 in the message proper.

LLC1 Data

   The LLC1 Information begins at byte 16 of the message, for 3 bytes.
   The contains the LLC1 destination and source SAPs, followed by the
   LLC1 type identifier (usually 03 for unnumbered information.)

Higher Layer Protocol Data

   Higher layer protocol information follows immediately after the LLC1
   header in the message proper, and flows into the associated data.
   For purposes of this document, this is OSI CLNP, but it may be any
   protocol which uses LLC1.





Halpern                                                         [Page 7]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


TO Addresses and Open Driver Architecture

   Since not all 16 bits of the TO address are used for the physical
   delivery of the network message, the remainder are considered
   "logical" in that their meaning is physically determined by host
   computer software or (in cases such as the FIPS data channel) by
   hardware in the host interface.

   Since HYPERchannel is and will be used to support a large variety of
   general and special purpose protocols, it is desirable that several
   independent protocol servers be able to independently share the
   HYPERchannel network interface.  The implementation of many of NSC's
   device drivers as well as those of other parties (such as Cray
   Research) support this service.  Each protocol server that wishes to
   send or receive HYPERchannel network messages logically connects to a
   HYPERchannel device driver by specifying the complete 16 bit TO
   address it will own in the sense that any network message with that
   TO address will be delivered to that protocol server.

   The logical TO field serves a function similar to the TYPE byte in
   the Ethernet message header, but differs from it in that the width of
   the logical TO field varies from host to host, and that no values of
   the logical TO address are reserved for particular protocols.  On the
   other hand, it is possible to have several "identical" protocols
   (such as two independent copies of OSI with different HYPERchannel
   addresses) sharing the same physical HYPERchannel interface.  This
   makes NSC's addressing approach identical to the OSI concept that the
   protocol server to reach is embedded within the address, rather than
   the IP notion of addressing a "host" and identifying a server through
   a message type.

   Since the HYPERchannel header also has a "message type" field, there
   is some ambiguity concerning the respective roles of the message type
   and logical TO fields:

   o   The logical TO field is always used to identify the protocol server
       which will receive the message.  Once a server has specified the
       complete TO address for the messages it wishes to receive, the
       message will not be delivered to a different protocol server
       regardless of the contents of the message type field.

   o   Although the type field cannot change the protocol server at the
       final destination of the message, the type field can be used by
       intermediate processes on the network to process the message
       before it reaches the server destination.   An obvious example
       is the 0xFF00 message loopback type function, where network
       processing to loop back the message results in nondelivery to
       the TO address.  In the future, intermediate nodes may process



Halpern                                                         [Page 8]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


       in transit messages based on the message type only for purposes
       such as security validation, aging of certain datagrams, and
       network management.

Broadcasting

   NSC message forwarding protocols use low level link protocols to
   negotiate transmission of a message to its next destination on the
   network.  Furthermore, NSC network boxes often fan out so that
   several hosts share the same network transmission equipment as in the
   A400 adapter.  Both these characteristics mean that providing a
   genuine broadcast capability is not a trivial task, and in fact no
   NSC technology supports a broadcast capability.

   However, the OSI ES-IS and IS-IS protocols require a broadcast
   capability to operate.  Therefore, in order to support these
   protocols, some form of broadcast emulation must be used.

ES-IS

   The End System to Intermediate System routing protocol is used by end
   systems to decide where to send packets.  In the specified protocol,
   multicast messages are used so that end systems learn about
   intermediate systems, and intermediate systems learn about end
   systems.  End systems normally then transmit any packets, whose
   correct mac destination is unknown, to a random intermediate system
   which then forwards the packet and tells the originator where to send
   future packets.

   There are two situations which are distinct but related for support
   of this protocol over HYPERchannel.  These are distinguished by
   whether or not there are any real intermediate systems on the
   HYPERchannel network.

   ES-IS with Intermediate Systems

      If there are one or more intermediate systems on the HYPERchannel,
      then the behavior is simply to emulate multicast.

      END SYSTEM SUPPORT Each end system is profiled with a list of
      intermediate systems on the HYPERchannel.  It is desirable but not
      necessary that this list be complete, as the future support for
      IS-IS will forward the necessary information to all the
      intermediate systems.  Given the profiled list, whenever the end
      system wishes to originate an ESH packet (End System Hello), it
      will send individual copies to each intermediate system it knows
      about.




Halpern                                                         [Page 9]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


      On most systems, these individual packets should be spaced out in
      time so as not to interfere with the normal transmission of OSI
      and other HYPERchannel messages.  For end systems, an inter-packet
      time of 0.1 seconds is probably appropriate.

      Note that if the End System receives ISH packets (Intermediate
      System Hello) from an IS on HYPERchannel not in its static list,
      it should add that to the list of systems it will send ESH packets
      to.  The address of the new intermediate system should be
      remembered for the holding time in the ISH, just as with the
      normal operation of ES-IS.

      INTERMEDIATE SYSTEMS Intermediate systems on the HYPERchannel
      shall also be profiled with the addresses of all the other
      intermediate systems on the HYPERchannel.  This list is used here
      and in the IS-IS protocol.  For the IS-IS protocol operation, it
      is important that the list be complete.

      The list of intermediate systems is used, with ES-IS, by an
      intermediate system only in that it probably is also an end
      system.  As such, it must send ESH packets to all the other
      intermediate systems.  (The presumption that an IS is also an ES
      is driven by the long term requirements for network management.
      If you have an upper layer stack, such as is required for CMIP,
      you are an end system.)

      Each intermediate system will keep a list of the end systems it
      knows about.  These are the systems it has received ESH packets
      from.  Whenever the IS sends ISH packets,  it sends them
      individually to each ES it has heard from.  In addition, it sends
      the ISH to any end systems which it believes, on the basis of IS-
      IS or other methods, are on the HYPERchannel.

      Note that these packets must also be spread out in time to avoid
      causing congestion.  However, given that the number of these is
      much higher than the number generated by End Systems, the time
      between transmissions should be selected by the IS developer to
      fit the sustainable I/O rates of the system.  Make sure you can
      get at the very least one, and preferably two or three, useful
      packets in between each ISH copy being sent.

   ES-IS without an Intermediate System

      When there is no intermediate system, one or more systems must
      serve as address managers.  These are referred to in draft ISO OSI
      documents as SNARE, for SubNetwork Address Resolution Entities.

      END SYSTEM SUPPORT As in the previous case, each end system must



Halpern                                                        [Page 10]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


      be profiled with a list of intermediate systems.  This list must
      contain all of the systems which will be serving as address
      managers on this network.  The reason for this is that, since the
      address managers are not true intermediate systems, they are not
      running IS-IS and will not be exchanging lists of end systems they
      know about. There may well be several systems for redundancy and
      reliability.

      SNARE The systems selected as address managers must appear, to the
      other end systems, as intermediate systems.  This means that each
      one must send out ISH packets to all the end systems which it
      hears from.  Each of these systems must record all the information
      from the ESH packets they receive.  When a packet for an End
      System is received at a SNARE, it must behave as an IS.
      Specifically, it must forward the packet to the correct
      destination end system, and send a redirect message back to the
      originator, informing the originator of the correct SNPA
      (HYPERchannel address) for the end system.

      Note that these systems are certainly end systems as well, and
      must send ESH packets to all the intermediate systems on the IS
      list, which must be complete.

   ES-IS FORMAT SPECIFICATION

      All ES-IS PDUS shall be formatted as specified in ISO 9542.  They
      are then sent using LLC1 and the encapsulation specified earlier
      in this document for transmitting LLC1 over HYPERchannel.

      RD PDUS When generating Redirect pdus, which contain HYPERchannel
      SNPAs (addresses), the SNPA shall be represented in four bytes.
      This shall be used even on a small HYPERchannel network containing
      only one domain and one network number.

      QC FUNCTION There is no support for the ES-IS query configuration
      capability when using HYPERchannel.  All systems must have at
      least one configured intermediate system, which shall be either a
      true IS or a SNARE.

IS-IS

   The proposed IS-IS protocol for OSI (DP 10589) when run on a LAN
   requires broadcast capability.  Because of the nature of the process
   for nominating the designated IS on a LAN, and other special features
   of this protocol, it is important never to partition the set of
   intermediate systems on a HYPERchannel network.

   The implementation therefore is very simple.  An intermediate system



Halpern                                                        [Page 11]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


   on HYPERchannel runs the IS-IS protocol directly.  However, when it
   goes to send a message, it consults the profiled list of all level 1
   ISs on the HYPERchannel or of all level 2 ISs on the HYPERchannel,
   and then sends individual copies of the message to each destination.
   This multiple transmission should be transparent to the IS-IS
   protocol itself.

   Note that as with ES-IS on an intermediate system, it is important to
   space out the individual message transmissions.  On most networks,
   spacing of 0.1 seconds will work well.

References

+1+       ISO IS 9542 - End system to intermediate system routing
          exchange protocol

+2+       ISO DP 10589 - Intermediate system to Intermediate system
          Infra-Domain routing exchange protocol

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Joel M. Halpern
   Principal Engineer
   Network Systems Corporation MS033
   7600 Boone Avenue North
   Brooklyn Park, AN 55428

   Phone: [phone]

   Email: [e-mail]

















Halpern                                                        [Page 12]