rfc1294.txt

RFC 的详细文档！

RFC 1294             Multiprotocol over Frame Relay         January 1992


   Because of the inefficiencies of broadcasting in a Frame Relay
   environment, a new address resolution variation was developed.  It is
   called Inverse ARP [11] and describes a method for resolving a
   protocol address when the hardware address is already known.  In
   Frame Relay's case, the known hardware address is the DLCI.  Using
   Inverse ARP for Frame Relay follows the same pattern as ARP and RARP
   use.  That is the source hardware address is inserted at the
   receiving station.

   In our example, station A may use Inverse ARP to discover the
   protocol address of the station associated with its DLCI 50.  The
   Inverse ARP request would be as follows:

         InARP Request from A (DLCI 50)
         ar$op   8       (InARP request)
         ar$sha  unknown
         ar$spa  pA
         ar$tha  0x0C21  (DLCI 50)
         ar$tpa  unknown

   When Station B receives this packet, it will modify the source
   hardware address with the Q.922 address from the Frame Relay header.
   This way, the InARP request from A will become:

         ar$op   8       (InARP request)
         ar$sha  0x1061
         ar$spa  pA
         ar$tha  0x0C21
         ar$tpa  unknown.

   Station B will format an Inverse ARP response and send it to station
   A as it would for any ARP message.

11.  IP over Frame Relay

   Internet Protocol [9] (IP) datagrams sent over a Frame Relay network
   conform to the encapsulation described previously.  Within this
   context, IP could be encapsulated in two different ways.













Bradley, Brown, Malis                                          [Page 22]

RFC 1294             Multiprotocol over Frame Relay         January 1992


         1.  NLPID value indicating IP

         +-----------------------+-----------------------+
         | Q.922 Address                                 |
         +-----------------------+-----------------------+
         | Control (UI)  0x03    | NLPID = 0xCC          |
         +-----------------------+-----------------------+
         | IP Packet             .                       |
         |                       .                       |
         |                       .                       |
         +-----------------------+-----------------------+

         2.  NLPID value indicating SNAP

         +-----------------------+-----------------------+
         | Q.922 Address                                 |
         +-----------------------+-----------------------+
         | Control (UI)  0x03    |     pad(s)  0x00      |
         +-----------------------+-----------------------+
         |  NLPID = 0x80         |                       |  SNAP Header
         +-----------------------+  OUI = 0x00-00-00     +  Indicating
         |                                               |  IP
         +-----------------------+-----------------------+
         |  PID = 0x0800                                 |
         +-----------------------+-----------------------+
         |                   IP packet                   |
         |                       .                       |
         |                       .                       |
         |                       .                       |
         +-----------------------+-----------------------+

   Although both of these encapsulations are supported under the given
   definitions, it is advantageous to select only one method as the
   appropriate mechanism for encapsulating IP data.  Therefore, IP data
   shall be encapsulated using the NLPID value of 0xCC indicating IP as
   shown in option 1 above.  This (option 1) is more efficient in
   transmission (48 fewer bits), and is consistent with the
   encapsulation of IP in X.25.

12.  Other Protocols over Frame Relay

   As with IP encapsulation, there are alternate ways to transmit
   various protocols within the scope of this definition.  To eliminate
   the conflicts, the SNAP encapsulation is only used if no NLPID value
   is defined for the given protocol.

   As an example of how this works, ISO CLNP has a NLPID defined (0x81).
   Therefore, the NLPID field will indicate ISO CLNP and the data packet



Bradley, Brown, Malis                                          [Page 23]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   will follow immediately.  The frame would be as follows:

         +----------------------+----------------------+
         |               Q.922 Address                 |
         +----------------------+----------------------+
         | Control     (0x03)   | NLPID  - 0x81 (CLNP) |
         +---------------------------------------------+
         | CLNP packet                                 |
         |                   .                         |
         |                   .                         |
         +---------------------------------------------+

13.  Bridging in a Frame Relay network

   A Frame Relay interface acting as a bridge must be able to flood,
   forward, and filter packets.

   Flooding is performed by sending the packet to all possible
   destinations.  In the Frame Relay environment this means sending the
   packet through each relevant DLC.

   To forward a packet, a bridge must be able to associate a destination
   MAC address with a DLC.  It is unreasonable and perhaps impossible to
   require bridges to statically configure an association of every
   possible destination MAC address with a DLC.  Therefore, Frame Relay
   bridges must provide enough information to allow a Frame Relay
   interface to dynamically learn about foreign destinations beyond the
   set of Frame Relay stations.

   To accomplish dynamic learning, a bridged packet shall conform to the
   encapsulation described within section 7.  In this way, the receiving
   Frame Relay interface will know to look into the bridged packet and
   learn the association between foreign destination and Frame Relay
   station.

14. For Future Study

   It may be desirable for the two ends of a connection to have the
   capability to negotiate end-to-end configuration and service
   parameters.  The actual protocol and parameters to be negotiated will
   be a topic of future RFCs.

15.  Backward Compatibility

   This section is included in this RFC for completeness only.  It is
   not intended to suggest additional requirements.

   Some existing Frame Relay stations use the NLPID value of 0xCE to



Bradley, Brown, Malis                                          [Page 24]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   indicate an escape to Ethernet Packet Types as defined in the latest
   version of the Assigned Numbers (RFC-1060) [7].  In this case, the
   frame will have the following format:

         +-----------------------------+
         | Q.922 Address               |
         +--                         --+
         |                             |
         +-----------------------------+
         | Control (UI = 0x03)         |
         +-----------------------------+
         | Optional Pad(s)   (0x00)    |
         +-----------------------------+
         | NLPID    (0xCE)             |
         +-----------------------------+
         | Ethertype                   |
         +-                           -+
         |                             |
         +-----------------------------+
         |             .               |
         |             .               |
         |           Data              |
         |             .               |
         |             .               |
         +-----------------------------+
         |    Frame Check Sequence     |
         +--           .             --+
         |       (two octets)          |
         +-----------------------------+

   The Ethertype field is a 16-bit value used to identify a protocol
   type for the following PDU.

   In order to be fully interoperable with stations that use this
   encoding, Frame Relay stations may recognize the NLPID value of 0xCE
   and interpret the following two byte Ethertype.  It is never
   necessary to generate this encapsulation format only to properly
   interpret it's meaning.

   For example, IP encapsulated with this NLPID value will have the
   following format:










Bradley, Brown, Malis                                          [Page 25]

RFC 1294             Multiprotocol over Frame Relay         January 1992


         +-----------------------+-----------------------+
         |Q.922 Address                                  |
         +-----------------------+-----------------------+
         |Control (UI)  0x03     | NLPID    0xCE         |
         +-----------------------+-----------------------+
         |Ethertype [7]                         0x0800   |
         +-----------------------+-----------------------+
         |  IP Packet                                    |
         |                       .                       |
         |                       .                       |
         +-----------------------+-----------------------+

16.  Appendix

   List of Known NLPIDs

      0x00    Null Network Layer or Inactive Set
              (not used with Frame Relay)
      0x80    SNAP
      0x81    ISO CLNP
      0x82    ISO ESIS
      0x83    ISO ISIS
      0xCC    Internet IP
      0xCE    EtherType - unofficial temporary use

   List of PIDs of OUI 00-80-C2

      with preserved FCS   w/o preserved FCS    Media
      ------------------   -----------------    --------------
      0x00-01              0x00-07              802.3/Ethernet
      0x00-02              0x00-08              802.4
      0x00-03              0x00-09              802.5
      0x00-04              0x00-0A              FDDI
      0x00-05              0x00-0B              802.6
      0x00-0D                                   Fragments
      0x00-0E                                   BPDUs

17.  References

   [1]  International Telegraph and Telephone Consultative Committee,
        "ISDN Data Link Layer Specification for Frame Mode Bearer
        Services", CCITT Recommendation Q.922,  19 April 1991 .

   [2]  American National Standard For Telecommunications - Integrated
        Services Digital Network - Core Aspects of Frame Protocol for
        Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 June
        1991.




Bradley, Brown, Malis                                          [Page 26]

RFC 1294             Multiprotocol over Frame Relay         January 1992


   [3]  Information technology - Telecommunications and Information
        Exchange between systems - Protocol Identification in the
        Network Layer, ISO/IEC  TR 9577: 1990 (E)  1990-10-15.

   [4]  Baker, Fred, "Point to Point Protocol Extensions for Bridging",
        Point to Point Working Group, RFC-1220, April 1991.

   [5]  International Standard, Information Processing Systems - Local
        Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE
        Std 802.2-1989, 1989-12-31.

   [6]  Plummer, David C., An Ethernet Address Resolution Protocol",
        RFC-826, November 1982.

   [7]  Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI,
        March 1990.

   [8]  Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
        Protocol", RFC-903, Stanford University, June 1984.

   [9]  Postel, J. and Reynolds, J., "A Standard for the Transmission of
        IP Datagrams over IEEE 802 Networks", RFC-1042, ISI, February
        1988.

   [10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
        Overview and architecture", IEEE Standards 802-1990.

   [11] Bradley, T., and C. Brown, "Inverse Address Resolution
        Protocol", RFC-1293, Wellfleet Communications, Inc., January
        1992.

18.  Security Considerations

        Security issues are not addressed in this memo.

19.  Authors' Addresses

           Terry Bradley
           Wellfleet Communications, Inc.
           15 Crosby Drive
           Bedford, MA  01730

           Phone:  [phone]

           Email:  [e-mail]






Bradley, Brown, Malis                                          [Page 27]

RFC 1294             Multiprotocol over Frame Relay         January 1992


           Caralyn Brown
           Wellfleet Communications, Inc.
           15 Crosby Drive
           Bedford, MA  01730

           Phone:  [phone]

           Email:  [e-mail]


           Andrew G. Malis
           BBN Communications
           150 CambridgePark Drive
           Cambridge, MA  02140

           Phone:  [phone]

           Email: [e-mail]

































Bradley, Brown, Malis                                          [Page 28]