📄 rfc2114.txt
字号:
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 dcap@cisco.com.
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -