rfc2114.txt

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

Network Working Group                                          S. Chiang
Request for Comments: 2114                                        J. Lee
Category: Informational                              Cisco Systems, Inc.
Obsoletes: 2106                                                H. Yasuda
                                               Mitsubishi Electric Corp.
                                                           February 1997


               Data Link Switching Client Access Protocol

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo describes the Data Link Switching Client Access Protocol
   that is used between workstations and routers to transport SNA/
   NetBIOS traffic over TCP sessions. Any questions or comments should
   be sent to [e-mail].

Table of Contents

   1.  Introduction ............................................   2
   2.  Overview ................................................   2
   2.1  DCAP Client/Server Model ...............................   2
   2.2  Dynamic Address Resolution .............................   3
   2.3  TCP Connection .........................................   4
   2.4  Multicast and Unicast (UDP) ............................   4
   3.  DCAP Format .............................................   6
   3.1  General Frame Format ...................................   6
   3.2  Header Format ..........................................   6
   3.3  DCAP Messages ..........................................   7
   3.4  DCAP Data formats ......................................   8
   3.4.1  CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames ..   8
   3.4.2  START_DL, DL_STARTED, and START_DL_FAILED Frames .....   9
   3.4.3  HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames .........  13
   3.4.4  XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME,
          FCM_FRAME, and DGRM_FRAME ............................  14
   3.4.5  DATA_FRAME ...........................................  15
   3.4.6  CAP_XCHANGE Frame ....................................  16
   3.4.7  CLOSE_PEER_REQ Frames ................................  19
   3.4.8  CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames 20
   4.  Protocol Flow Diagram ...................................  20
   5.  Acknowledgments .........................................  22
   6.  References ..............................................  22



Chiang, et. al.              Informational                      [Page 1]

RFC 2114                          DCAP                     February 1997


1.  Introduction

   Since the Data Link Switching Protocol, RFC 1795, was published, some
   software vendors have begun implementing DLSw on workstations. The
   implementation of DLSw on a large number of workstations raises
   several important issues that must be addressed. Scalability is the
   major concern. For example, the number of TCP sessions to the DLSw
   router increases in direct proportion to the number of workstations
   added. Another concern is efficiency. Since DLSw is a switch-to-
   switch protocol, it is not efficient when implemented on
   workstations.

   DCAP addresses the above issues. It introduces a hierarchical
   structure to resolve the scalability problems. All workstations are
   clients to the router (server) rather than peers to the router. This
   creates a client/server model. It also provides a more efficient
   protocol between the workstation (client) and the router (server).

2.  Overview

2.1.  DCAP Client/Server Model

      +-----------+              +-----------+       +---------+
      | Mainframe |              | IP Router +- ppp -+ DLSw    |
      +--+--------+              +-----+-----+       | Work    |
         |                             |             | Station |
         |                             |             +---------+
      +--+--+      +-------------+     |
      | FEP +- TR -+ DLSw Router +-- IP Backbone
      +-----+      +-------------+     |
                                       |
                                       |
                                 +-----------+       +---------+
                                 | IP Router +- ppp -+ DLSw    |
                                 +-----+-----+       | Work    |
                                                     | Station |
                                                     +---------+

                           |         DLSw Session          |
                           +-------------------------------+
  Figure 2-1. Running DLSw on a large number of workstations creates a
                         scalability problem.

   Figure 2-1 shows a typical DLSw implementation on a workstation. The
   workstations are connected to the central site DLSw router over the
   IP network.  As the network grows, scalability will become an issue
   as the number of TCP sessions increases due to the growing number of
   workstations.



Chiang, et. al.              Informational                      [Page 2]

RFC 2114                          DCAP                     February 1997


  +-----------+                                        +--------+
  | Mainframe |                                        | DCAP   |
  +--+--------+                                  +-----+ Client |
     |                                           |     +--------+
     |                                          ppp
     |                                           |
  +--+--+      +--------+                 +------+------+
  | FEP +- TR -+  DLSw  +-- IP Backbone --+ DLSw Router |
  +-----+      | Router |                 | DCAP Server |
               +--------+                 +------+------+
                                                 |
                                                ppp
                                                 |     +--------+
                                                 +-----+ DCAP   |
                                                       | Client |
                                                       +--------+

                    |     DLSw Session     |  | DCAP Session |
                    +----------------------+  +--------------+
     Figure 2-2. DLSw Client Access Protocol solves the scalability
                                problem.

   In a large network, DCAP addresses the scalability problem by
   significantly reducing the number of peers that connect to the
   central site router. The workstations (DCAP clients) and the router
   (DCAP server) behave in a Client/Server relationship. Workstations
   are attached to a DCAP server. A DCAP server has a single peer
   connection to the central site router.

2.2.  Dynamic Address Resolution

   In a DLSw network, each workstation needs a MAC address to
   communicate with a FEP attached to a LAN. When DLSw is implemented on
   a workstation, it does not always have a MAC address defined. For
   example, when a workstation connects to a router through a modem via
   PPP, it only consists of an IP address. In this case, the user must
   define a virtual MAC address. This is administratively intensive
   since each workstation must have an unique MAC address.

   DCAP uses the Dynamic Address Resolution protocol to solve this
   problem. The Dynamic Address Resolution protocol permits the server
   to dynamically assign a MAC address to a client without complex
   configuration.

   For a client to initiate a session to a server, the workstation sends
   a direct request to the server. The request contains the destination
   MAC address and the destination SAP. The workstation can either
   specify its own MAC address, or request the server to assign one to



Chiang, et. al.              Informational                      [Page 3]

RFC 2114                          DCAP                     February 1997


   it. The server's IP address must be pre-configured on the
   workstation. If IP addresses are configured for multiple servers at a
   workstation, the request can be sent to these servers and the first
   one to respond will be used.

   For a server to initiate a session to a client, the server sends a
   directed request to the workstation. The workstation must pre-
   register its MAC address at the server. This can be done either by
   configuration on the server or registration at the server (both MAC
   addresses and IP addresses will be registered).

2.3.  TCP Connection

   The transport used between the client and the server is TCP. A TCP
   session must be established between the client and the server before
   a frame can be sent. The default parameters associated with the TCP
   connections between the client and the server are as follows:

   Socket Family     AF_INET        (Internet protocols)
   Socket Type       SOCK_STREAM    (stream socket)
   Port Number       1973

   There is only one TCP connection between the client and the server.
   It is used for both read and write operations.

   A race condition occurs when both client and server try to establish
   the TCP session with each other at the same time. The TCP session of
   the initiator with the lower IP address will be used. The other TCP
   session will be closed.

2.4   Multicast and Unicast (UDP)

   Multicast and unicast with UDP support are optional. In the reset of
   this session, when multicast and unicast are referenced, UDP is used.
   Two multicast addresses are reserved for DCAP. The server should
   listen for 224.0.1.49 and the client should listen for 224.0.1.50.
   Not all DCAP frames can be sent via multicast or unicast. The
   DATA_FRAME can be sent via either multicast or unicast. The
   CAN_U_REACH frame can be sent via multicast only and the I_CAN_REACH
   frame can be sent via unicast only. All other DCAP frames can only be
   sent via TCP sessions.

   When the multicast and unicast support is implemented, the client
   does not have to configure the server's IP address. When the client
   attempts to establish a session to the host, instead of establishing
   a TCP session with the pre-configured server, the client can
   multicast the CAN_U_REACH frame to the 224.0.1.49 group address. When
   the server receives this multicast frame, it will locate the



Chiang, et. al.              Informational                      [Page 4]

RFC 2114                          DCAP                     February 1997


   destination as specified in the frame. If the destination is
   reachable by this server, it will send back an I_CAN_REACH frame to
   the sender via unicast.  The client can initiate a TCP connection to
   the server and establish a DCAP session. If the I_CAN_REACH frame is
   received from multiple servers, the first one who returns the
   I_CAN_REACH frame will be used.

   When the host initiates a session to the client, the client does not
   have to pre-register its MAC address at the server. When the server
   attempts to reach an unknown client, it will multicast the
   CAN_U_REACH frame to the 224.0.10.50 group address. The client whose
   MAC address matches the destination address in the CAN_U_REACH frame
   will reply with the I_CAN_REACH frame via unicast. Once the server
   receives the I_CAN_REACH frame, it can establish a DCAP session with
   that client.

   For NetBIOS traffic, NAME_QUERY and ADD_NAME_QUERY can be
   encapsulated in the DATA_FRAME and sent out via multicast.
   NAME_RECOGNIZED and ADD_NAME_RESPONSE can be encapsulated in the
   DATA_FRAME but sent out via unicast. No other NetBIOS frames can be
   encapsulated in the DATA_FRAME to be sent out via either multicast or
   unicast.

   When a client tries to locate a name or check for duplicate name on
   the network, it can multicast a NAME_QUERY or ADD_NAME_QUERY frame
   encapsulated in the DATA_FRAME. When a server receives these frames,
   NetBIOS NAME_QUERY or ADD_NAME_QUERY frames will be forwarded to LAN.
   If the NAME_RECOGNIZED or ADD_NAME_RESPONSE frame is received from
   LAN, they will be encapsulated in the DATA_FRAME and sent to the
   client via unicast.

   When a server receives a NetBIOS NAME_QUERY or ADD_NAME_QUERY from
   LAN, the server will encapsulate it in the DATA_FRAME and send it to
   all clients via multicast. When a client receives the frame and
   determines that the name specified in the DATA_FRAME matches its own
   name, a NAME_RECOGNIZED or ADD_NAME_RESPONSE frame will be
   encapsulated in the DATA_FRAME and sent back to the server via
   unicast.













Chiang, et. al.              Informational                      [Page 5]

RFC 2114                          DCAP                     February 1997


3.  DCAP Format

3.1.  General Frame Format

   The General format of the DCAP frame is as follows:

                  +-------------+-----------+-----------+
                  | DCAP Header | DCAP Data | User Data |
                  +-------------+-----------+-----------+
                     Figure 3-1. DCAP Frame Format

   The DCAP protocol is contained in the DCAP header, which is common to
   all frames passed between the DCAP client and the server. This header
   is 4 bytes long. The next section will explain the details.

   The next part is the DCAP Data. The structure and the size are based
   on the type of messages carried in the DCAP frame. The DCAP data is
   used to process the frame, but it is optional.

   The third part of the frame is the user data, which is sent by the
   local system to the remote system. The size of this block is variable
   and is included in the frame only when there is data to be sent to
   the remote system.