rfc1009.txt

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

         GGP is a "min-hop" algorithm, i.e., its length measure is
         simply the number of network hops between gateway pairs.  It
         implements a distributed shortest-path algorithm, which
         requires global convergence of the routing tables after a
         change in topology or connectivity.  Each gateway sends a GGP



Braden & Postel                                                [Page 22]



RFC 1009 - Requirements for Internet Gateways                  June 1987


         routing update only to its neighbors, but each update includes
         an entry for every known network, where each entry contains the
         hop count from the gateway sending the update.

      2.6.2.  Shortest-Path-First (SPF) Protocols

         SPF [40] is the name for a class of routing algorithms based on
         a shortest-path algorithm of Dijkstra.  The current ARPANET
         routing algorithm is SPF, and the BBN Butterfly gateways also
         use SPF.  Its characteristics are considered superior to
         GGP [58].

         Under SPF, the routing data-base is replicated rather than
         distributed.  Each gateway will have its own copy of the same
         data-base, containing the entire Internet topology and the
         lengths of every path.  Since each gateway has all the routing
         data and runs a shortest-path algorithm locally, there is no
         problem of global convergence of a distributed algorithm, as in
         GGP.  To build this replicated data-base, a gateway sends SPF
         routing updates to ALL other gateways; these updates only list
         the distances to each of the gateway's neighbors, making them
         much smaller than GGP updates.  The algorithm used to
         distribute SPF routing updates involves reliable flooding.

      2.6.3.  Routing Information (RIP)

         RIP is the name often used for a class of routing protocols
         based upon the Xerox PUP and XNS routing protocols.  These are
         relatively simple, and are widely available because they are
         incorporated in the embedded gateway code of Berkeley BSD
         systems.  Because of this simplicity, RIP protocols have come
         the closest of any to being an "Open IGP", i.e., a protocol
         which can be used between different vendors' gateways.
         Unfortunately, there is no standard, and in fact not even a
         good document, for RIP.

         As in GGP, gateways using RIP periodically broadcast their
         routing data-base to their neighbor gateways, and use a
         hop-count as the metric.

         A fixed value of the hop-count (normally 16) is defined to be
         "infinity", i.e., network unreachable.  A RIP implementation
         must include measures to avoid both the slow-convergence
         phenomen called "counting to infinity" and the formation of
         routing loops.  One such measure is a "hold-down" rule.  This
         rule establishes a period of time (typically 60 seconds) during
         which a gateway will ignore new routing information about a
         given network, once the gateway has learned that network is


Braden & Postel                                                [Page 23]



RFC 1009 - Requirements for Internet Gateways                  June 1987


         unreachable (has hop-count "infinity").  The hold-down period
         must be settable in the gateway configuration; if gateways with
         different hold-down periods are using RIP in the same
         Autonomous System, routing loops are a distinct possibility.
         In general, the hold-down period is chosen large enough to
         allow time for unreachable status to propagate to all gateways
         in the AS.

      2.6.4.  Hello

         The "Fuzzball" software for an LSI/11 developed by Dave Mills
         incorporated an IGP called the "Hello" protocol [39].  This IGP
         is mentioned here because the Fuzzballs have been widely used
         in Internet experimentation, and because they have served as a
         testbed for many new routing ideas.

   2.7.  Monitoring Protocols

      See Section 5 of this document.

   2.8.  Internet Group Management Protocol (IGMP)

      An extension to the IP protocol has been defined to provide
      Internet-wide multicasting, i.e., delivery of copies of the same
      IP datagram to a set of Internet hosts [47, 48].  This delivery is
      to be performed by processes known as "multicasting agents", which
      reside either in a host on each net or (preferably) in the
      gateways.

      The set of hosts to which a datagram is delivered is called a
      "host group", and there is a host-agent protocol called IGMP,
      which a host uses to join, leave, or create a group.  Each host
      group is distinguished by a Class D IP address.

      This multicasting mechanism and its IGMP protocol are currently
      experimental; implementation in vendor gateways would be premature
      at this time.  A datagram containing a Class D IP address must be
      dropped, with no ICMP error message.












Braden & Postel                                                [Page 24]



RFC 1009 - Requirements for Internet Gateways                  June 1987


3.  Constituent Network Interface

   This section discusses the rules used for transmission of IP
   datagrams on the most common types of constituent networks.  A
   gateway must be able to send and receive IP datagrams of any size up
   to the MTU of any constituent network to which it is connected.

   3.1.  Public data networks via X.25

      The formats specified for public data networks accessed via X.25
      are described in RFC-877 [8].  Datagrams are transmitted over
      standard level-3 virtual circuits as complete packet sequences.
      Virtual circuits are usually established dynamically as required
      and time-out after a period of no traffic.  Link-level
      retransmission, resequencing and flow control are performed by the
      network for each virtual circuit and by the LAPB link-level
      protocol.  Note that a single X.25 virtual circuit may be used to
      multiplex all IP traffic between a pair of hosts.  However,
      multiple parallel virtual circuits may be used in order to improve
      the utilization of the subscriber access line, in spite of small
      X.25 window sizes; this can result in random resequencing.

      The correspondence between Internet and X.121 addresses is usually
      established by table-lookup.  It is expected that this will be
      replaced by some sort of directory procedure in the future.  The
      table of the hosts on the Public Data Network is in the Assigned
      Numbers [23].

      The normal MTU is 576; however, the two DTE's (hosts or gateways)
      can use X.25 packet size negotiation to increase this value [8].

   3.2.  ARPANET via 1822 LH, DH, or HDH

      The formats specified for ARPANET networks using 1822 access are
      described in BBN Report 1822 [3], which includes the procedures
      for several subscriber access methods.  The Distant Host (DH)
      method is used when the host and IMP (the Defense Communication
      Agency calls it a Packet Switch Node or PSN) are separated by not
      more than about 2000 feet of cable, while the HDLC Distant Host
      (HDH) is used for greater distances where a modem is required.
      Under HDH, retransmission, resequencing and flow control are
      performed by the network and by the HDLC link-level protocol.

      The IP encapsulation format is simply to include the IP datagram
      as the data portion of an 1822 message.  In addition, the
      high-order 8 bits of the Message Id field (also known as the
      "link" field") should be set to 155 [23].  The MTU is 1007 octets.



Braden & Postel                                                [Page 25]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      While the ARPANET 1822 protocols are widely used at present, they
      are expected to be eventually overtaken by the DDN Standard X.25
      protocol (see Section 3.3).  The original IP address mapping
      (RFC-796 [38]) is in the process of being replaced by a new
      interface specification called AHIP-E; see RFC-1005 [61] for the
      proposal.

      Gateways connected to ARPANET or MILNET IMPs using 1822 access
      must incorporate features to avoid host-port blocking (i.e., RFNM
      counting) and to detect and report as ICMP Unreachable messages
      the failure of destination hosts or gateways (i.e., convert the
      1822 error messages to the appropriate ICMP messages).

      In the development of a network interface it will be useful to
      review the IMP end-to-end protocol described in RFC-979 [29].

   3.3.  ARPANET via DDN Standard X.25

      The formats specified for ARPANET networks via X.25 are described
      in the Defense Data Network X.25 Host Interface Specification [6],
      which describes two sets of procedures: the DDN Basic X.25, and
      the DDN Standard X.25.  Only DDN Standard X.25 provides the
      functionality required for interoperability assumptions of the
      Internet protocol.

      The DDN Standard X.25 procedures are similar to the public data
      network X.25 procedures, except in the address mappings.
      Retransmission, resequencing and flow control are performed by the
      network and by the LAPB link-level protocol.  Multiple parallel
      virtual circuits may be used in order to improve the utilization
      of the subscriber access line; this can result in random
      resequencing.

      Gateways connected to ARPANET or MILNET using Standard X.25 access
      must detect and report as ICMP Unreachable messages the failure of
      destination hosts or gateways (i.e., convert the X.25 diagnostic
      codes to the appropriate ICMP messages).

      To achieve compatibility with 1822 interfaces, the effective MTU
      for a Standard X.25 interface is 1007 octets.










Braden & Postel                                                [Page 26]



RFC 1009 - Requirements for Internet Gateways                  June 1987


   3.4.  Ethernet and IEEE 802

      The formats specified for Ethernet networks are described in
      RFC-894 [10].  Datagrams are encapsulated as Ethernet packets with
      48-bit source and destination address fields and a 16-bit type
      field (the type field values are listed in the Assigned
      Numbers [23]).  Address translation between Ethernet addresses and
      Internet addresses is managed by the Address Resolution Protocol,
      which is required in all Ethernet implementations.  There is no
      explicit link-level retransmission, resequencing or flow control,
      although most hardware interfaces will retransmit automatically in
      case of collisions on the cable.

      The IEEE 802 networks use a Link Service Access Point (LSAP) field
      in much the same way the ARPANET uses the "link" field.  Further,
      there is an extension of the LSAP header called the Sub-Network
      Access Protocol (SNAP).

      The 802.2 encapsulation is used on 802.3, 802.4, and 802.5 network
      by using the SNAP with an organization code indicating that the
      following 16 bits specify the Ether-Type code [23].

      Headers:

         ...--------+--------+--------+
          MAC Header|      Length     |                  802.{3/4/5} MAC
         ...--------+--------+--------+

         +--------+--------+--------+
         | DSAP=K1| SSAP=K1| control|                          802.2 SAP
         +--------+--------+--------+

         +--------+--------+--------+--------+--------+
         |protocol id or org code=K2|    Ether-Type   |       802.2 SNAP
         +--------+--------+--------+--------+--------+

      The total length of the SAP Header and the SNAP header is
      8-octets, making the 802.2 protocol overhead come out on a 64-bit
      boundary.

      K1 is 170.  The IEEE likes to talk about things in bit
      transmission order and specifies this value as 01010101.  In
      big-endian order, as used in the Internet specifications, this
      becomes 10101010 binary, or AA hex, or 170 decimal.  K2 is 0
      (zero).

      The use of the IP LSAP (K1 = 6) is reserved for future
      development.


Braden & Postel                                                [Page 27]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      The assigned values for the Ether-Type field are the same for
      either this IEEE 802 encapsulation or the basic Ethernet
      encapsulation [10].

      In either Ethernets or IEEE 802 nets, the IP datagram is the data
      portion of the packet immediately following the Ether-Type.

      The MTU for an Ethernet or its IEEE-standard equivalent (802.3) is
      1500 octets.

   3.5.  Serial-Line Protoc