idnits 2.17.1 draft-rfced-info-chiang-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 80 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1996) is 10047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 777, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 780, but no explicit reference was found in the text Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Expires April 1997 INTERNET-DRAFT 4 Network Working Group Steve T. Chiang 5 INTERNET-DRAFT Joseph S. Lee 6 Category: Informational Cisco Systems, Inc. 7 Hideaki Yasuda 8 Mitsubishi Electric Corp. 9 October 1996 11 Data Link Switching Remote Access Protocol 13 15 Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 "working draft" or "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Abstract 40 This memo describes the Data Link Switching Remote Access Protocol 41 that is used between workstations and routers to transport SNA/ 42 NetBIOS traffic over TCP sessions. Any questions or comments 43 should be sent to drap@cisco.com. 45 1. Introduction 47 Since the Data Link Switching Protocol, RFC 1795, was published, 48 some software vendors have begun implementing DLSw on workstations. 49 The implementation of DLSw on a large number of workstations raises 50 several important issues that must be addressed. Scalability is the 51 major concern. For example, the number of TCP sessions to the DLSw 52 router increases in direct proportion to the number of workstations 53 added. Another concern is efficiency. Since DLSw is a 54 switch-to-switch protocol, it is not efficient when implemented on 55 workstations. 57 DRAP addresses the above issues. It introduces a hierarchical 58 structure to resolve the scalability problems. All workstations are 59 clients to the router (server) rather than peers to the router. This 60 creates a client/server model. It also provides a more efficient 61 protocol between the workstation (client) and the router (server). 63 2. Overview 65 2.1. DRAP Client/Server Model 67 +-----------+ +-----------+ +---------+ 68 | Mainframe | | IP Router +- ppp -+ DLSw | 69 +--+--------+ +-----+-----+ | Work | 70 | | | Station | 71 | | +---------+ 72 +--+--+ +-------------+ | 73 | FEP +- TR -+ DLSw Router +-- IP Backbone 74 +-----+ +-------------+ | 75 | 76 | 77 +-----------+ +---------+ 78 | IP Router +- ppp -+ DLSw | 79 +-----+-----+ | Work | 80 | Station | 81 +---------+ 83 | DLSw Session | 84 +-------------------------------+ 85 Figure 2-1. Running DLSw on a large number of workstations creates a 86 scalability problem. 88 Figure 2-1 shows a typical DLSw implementation on a workstation. The 89 workstations are connected to the central site DLSw router over the 90 IP network. As the network grows, scalability will become an issue 91 as the number of TCP sessions increases due to the growing number of 92 workstations. 94 +-----------+ +-------+ 95 +-----------+ | DLSw/DRAP | | DRAP | 96 | Mainframe | | Router +- ppp -+ Client| 97 +--+--------+ +-----+-----+ +-------+ 98 | | 99 | | 100 +--+--+ +-------------+ | 101 | FEP +- TR -+ DLSw Router +-- IP Backbone 102 +-----+ +-------------+ | 103 | 104 | 105 +-----------+ +-------+ 106 | DLSw/DRAP | | DRAP | 107 | Router +- ppp -+ Client| 108 +-----+-----+ +-------+ 110 | DLSw Session | | DRAP Session | 111 +--------------+ +--------------+ 112 Figure 2-2. DLSw Remote Access Protocol solves the scalability problem. 114 In a large network, DRAP addresses the scalability problem by 115 significantly reducing the number of peers that connect to the 116 central site router. The workstations (DRAP client) and the router 117 (DRAP server) behave in a Client/Server relationship. Workstations 118 are attached to a DRAP server. A DRAP server has a single peer 119 connection to the central site router. 121 2.2. Dynamic Address Resolution 123 In a DLSw network, each workstation needs a MAC address to 124 communicate with a FEP attached to a LAN. When DLSw is implemented 125 on a workstation, it does not always have a MAC address defined. For 126 example, when a workstation connects to a router through a modem via 127 PPP, it only consists of an IP address. In this case, the user must 128 define a virtual MAC address. This is administratively intensive 129 since each workstation must have an unique MAC address. 131 DRAP uses the Dynamic Address Resolution protocol to solve this 132 problem. The Dynamic Address Resolution protocol permits the server 133 to dynamically assign a MAC address to a client without complex 134 configuration. 136 For a client to initiate a session to a server, the workstation sends 137 a direct request to the server. The request contains the destination 138 MAC address and the destination SAP. The workstation can either 139 specify its own MAC address, or request the server to assign one to 140 it. The server's IP address must be pre-configured on the 141 workstation. If IP addresses are configured for multiple servers at 142 a workstation, the request can be sent to these servers and the first 143 one to respond will be used. 145 For a server to initiate a session to a client, the server sends a 146 directed request to the workstation. The workstation must 147 pre-register its MAC address at the server. This can be done either 148 by configuration on the server or registration at the server (both 149 MAC addresses and IP addresses will be registered). 151 2.3. TCP Connection 153 The transport used between the client and the server is TCP. Before a 154 TCP session is established between the client and the server, no 155 message can be sent. The default parameters associated with the TCP 156 connections between the client and the server are as follows: 158 Socket Family AF_INET (Internet protocols) 159 Socket Type SOCK_STREAM (stream socket) 160 Port Number 1973 162 There is only one TCP connection between the client and the server. 163 It is used for both read and write operations. 165 3. DRAP Format 167 3.1. General Frame Format 169 The General format of the DRAP frame is as follows: 171 +-------------+-----------+-----------+ 172 | DRAP Header | DRAP Data | User Data | 173 +-------------+-----------+-----------+ 174 Figure 3-1. DRAP Frame Format 176 The DRAP protocol is contained in the DRAP header, which is common to 177 all frames passed between the DRAP client and the server. This header 178 is 4 bytes long. The next section will explain the details. 180 The next part is the DRAP Data. The structure and the size are based 181 on the type of messages carried in the DRAP frame. The DRAP data is 182 used to process the frame, but it is optional. 184 The third part of the frame is the user data, which is sent by the 185 local system to the remote system. The size of this block is variable 186 and is included in the frame only when there is data to be sent to 187 the remote system. 189 3.2. Header Format 191 The DRAP header is used to identify the message type and the length 192 of the frame. This is a general purpose header used for each frame 193 that is passed between the DRAP server and the client. More 194 information is needed for frames like CAN_U_REACH and I_CAN_REACH, 195 therefore, it is passed to the peer as DRAP data. The structure of 196 the DRAP data depends on the type of frames, and will be discussed 197 in detail in later sections. 199 The DRAP Header is given below: 201 +-------------------------------------------+ 202 | DRAP Packet Header (Each row is one byte) | 203 +===========================================+ 204 0 | Protocol ID / Version Number | 205 +-------------------------------------------+ 206 1 | Message Type | 207 +-------------------------------------------+ 208 2 | Packet Length | 209 + - - - - - - - - - - - - - - - - - - - - - + 210 3 | | 211 +-------------------------------------------+ 212 Figure 3-2. DRAP Header Format 214 o The Protocol ID uses the first 4 bits of this field and is set to 215 "1000". 217 o The Version Number uses the next 4 bits in this field and is set 218 to "0001". 220 o The message type is the DRAP message type. 222 o The Total Packet length is the length of the packet including the 223 DRAP header, DRAP data and User Data. The minimum size of the 224 packet is 4, which is the length of the header. 226 3.3. DRAP Messages 228 Most of the Drap frames are based on the existing DLSw frames and 229 have the same names. The information in the corresponding DRAP and 230 DLSw frames may differ; but the functionalities are the same. Thus 231 the DLSw State Machine is used to handle these DRAP frames. Some new 232 DRAP frames were created to handle special DRAP functions. For 233 example, the new DRAP frames, I_CANNOT_REACH and START_DL_FAILED 234 provide negative acknowledgment. The DLSw frames not needed for DRAP, 235 are dropped. 237 The following table lists and describes all available DRAP messages: 239 DRAP Frame Name Code Function 240 --------------- ---- -------- 241 CAN_U_REACH 0x01 Find if the station given is reachable 242 I_CAN_REACH 0x02 Positive response to CAN_U_REACH 243 I_CANNOT_REACH 0x03 Negative response to CAN_U_REACH 244 START_DL 0x04 Setup session for given addresses 245 DL_STARTED 0x05 Session Started 246 START_DL_FAILED 0x06 Session Start failed 247 XID_FRAME 0x07 XID Frame 248 CONTACT_STN 0x08 Contact destination to establish SABME 249 STN_CONTACTED 0x09 Station contacted - SABME mode set 250 DATA_FRAME 0x0A Connectionless Data Frame for a link 251 INFO_FRAME 0x0B Connection oriented I-Frame 252 HALT_DL 0x0C Halt Data Link session 253 HALT_DL_NOACK 0x0D Halt Data Link session without ack 254 DL_HALTED 0x0E Session Halted 255 FCM_FRAME 0x0F Data Link Session Flow Control Message 256 DGRM_FRAME 0x11 Connectionless Datagram Frame for a circuit 257 CAP_XCHANGE 0x12 Capabilities Exchange Message 258 CLOSE_PEER_REQUEST 0x13 Disconnect Peer Connection Request 259 CLOSE_PEER_RESPONSE 0x14 Disconnect Peer Connection Response 260 PEER_TEST_REQ 0x1D Peer keepalive test request 261 PEER_TEST_RSP 0x1E Peer keepalive response 263 Table 3-1. DRAP Frames 265 3.4. DRAP Data formats 267 The DRAP data is used to carry information required for each DRAP 268 frame. This information is used by the Server or the Client and it 269 does not contain any user data. The DRAP data frame types are listed 270 in the following sections. Please note that the sender should set 271 the reserved fields to zero and the receiver should ignore these 272 fields. 274 3.4.1. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames 276 These frame types are used to locate resources in a network. A 277 CAN_U_REACH frame is sent to the server to determine if the resource 278 is reachable. The server responds with an I_CAN_REACH frame if it can 279 reach the workstation identified in the CAN_U_REACH frame, or with 280 an I_CANNOT_REACH if the station is not reachable. The server should 281 not send the CAN_U_REACH frame to the clients. When a server receives 282 an explorer whose destination is a known client, the server should 283 respond to it directly. 285 +---------------+-----------------------+ 286 | Field Name | Information | 287 +---------------+-----------------------+ 288 | Message Type | 0x01, 0x02, or 0x03 | 289 +---------------+-----------------------+ 290 | Packet Length | 0x0C | 291 +---------------+-----------------------+ 292 Figure 3-3. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Header 293 +-----------------------------------+ 294 | Field Name (Each row is one byte) | 295 +===================================+ 296 0 | Target MAC Address | 297 + - - - - - - - - - - - - - - - - - + 298 1 | | 299 + - - - - - - - - - - - - - - - - - + 300 2 | | 301 + - - - - - - - - - - - - - - - - - + 302 3 | | 303 + - - - - - - - - - - - - - - - - - + 304 4 | | 305 + - - - - - - - - - - - - - - - - - + 306 5 | | 307 +-----------------------------------+ 308 6 | Source SAP | 309 +-----------------------------------+ 310 7 | Reserved | 311 +-----------------------------------+ 312 Figure 3-4. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Data 314 The MAC Address field carries the MAC address of the target 315 workstation that is being searched. This is a six-byte MAC Address 316 field. The same MAC Address is returned in the I_CAN_REACH and the 317 I_CANNOT_REACH frames. 319 Byte 6 is the source SAP. The destination SAP is set to zero when an 320 explorer frame is sent to the network. 322 If the sender did not receive a positive acknowledgment within a 323 recommended threshold value of 60 seconds, the destination is 324 considered not reachable. 326 3.4.2. START_DL, DL_STARTED, and START_DL_FAILED Frames 328 These frame types are used by DRAP to establish a link station 329 (circuit). The START_DL frame is sent directly to the server that 330 responds to the CAN_U_REACH frame. When the server receives this 331 frame, it establishes a link station with the source and destination 332 addresses and saps provided in the START_DL frame. If the circuit 333 establishment is successful, a DL_STARTED frame is sent back as a 334 response. A failure will result in a START_DL_FAILED response. The 335 server can also send START_DL frames to clients, to establish 336 circuits. 338 +---------------+-----------------------+ 339 | Field Name | Information | 340 +---------------+-----------------------+ 341 | Message Type | 0x04, 0x05, or 0x06 | 342 +---------------+-----------------------+ 343 | Packet Length | 0x18 | 344 +---------------+-----------------------+ 345 Figure 3-5. START_DL, DL_STARTED, and START_DL_FAILED Header 346 +-----------------------------------+ 347 | Field Name (Each row is one byte) | 348 +===================================+ 349 0 | Host MAC Address | 350 + - - - - - - - - - - - - - - - - - + 351 1 | | 352 + - - - - - - - - - - - - - - - - - + 353 2 | | 354 + - - - - - - - - - - - - - - - - - + 355 3 | | 356 + - - - - - - - - - - - - - - - - - + 357 4 | | 358 + - - - - - - - - - - - - - - - - - + 359 5 | | 360 +-----------------------------------+ 361 6 | Host SAP | 362 +-----------------------------------+ 363 7 | Client SAP | 364 +-----------------------------------+ 365 8 | Origin Session ID | 366 +-----------------------------------+ 367 9 | | 368 + - - - - - - - - - - - - - - - - - + 369 10| | 370 + - - - - - - - - - - - - - - - - - + 371 11| | 372 +-----------------------------------+ 373 12| Target Session ID | 374 + - - - - - - - - - - - - - - - - - + 375 13| | 376 + - - - - - - - - - - - - - - - - - + 377 14| | 378 + - - - - - - - - - - - - - - - - - + 379 15| | 380 +-----------------------------------+ 381 16| Largest Frame Size | 382 +-----------------------------------+ 383 17| Initial Window size | 384 +-----------------------------------+ 385 18| Reserved | 386 + - - - - - - - - - - - - - - - - - + 387 19| | 388 +-----------------------------------+ 389 Figure 3-6. START_DL, DL_STARTED, and START_DL_FAILED Data 390 The Host MAC address is the address of the target station if the 391 session is initiated from the client, or it is the address of the 392 originating station if the session is initiated from the server. 394 The next two fields are the Host and Client SAPs. Each is one byte 395 long. The Host SAP is the SAP used by the station with the Host MAC 396 address. The Client SAP is the SAP used by the client. 398 The Origin Session ID, is the ID of the originating station that 399 initiates the circuit. The originating station uses this ID to 400 identify the newly created circuit. Before the START_DL frame is sent 401 to the target station, the originating station sets up a control 402 block for the circuit. This link station information is set because 403 DRAP does not use a three-way handshake for link station 404 establishment. In the DL_STARTED and the START_DL_FAILED messages, 405 the Origin Session ID is returned as received in the START_DL frame. 406 The Target Session ID is set by the target station and returned in 407 the DL_STARTED message. 409 The Target Session ID is not valid for the START_DL and the 410 START_DL_FAILED frame, and should be treated as Reserved fields. 411 In the DL_STARTED frame, it is the session ID that is used to set up 412 this circuit by the target station. 414 The Largest Frame Size field is used to indicate the maximum frame 415 size that can be used by the client. It is valid only when it is set 416 by the server. The Largest Frame Size field must be set to zero when 417 a frame is sent by the client. Both START_DL and DL_STARTED use the 418 Largest Frame Size field and only its rightmost 6 bits are used. The 419 format is defined in the IEEE 802.1D Standard, Annex C, Largest Frame 420 Bits (LF). Bit 3 to bit 5 are base bits. Bit 0 to bit 2 are extended 421 bits. The Largest Frame Size field is not used in the START_DL_FAILED 422 frame and must be set to zero. 424 bit 7 6 5 4 3 2 1 0 425 r r b b b e e e 426 Figure 3-7. Largest Frame Size 428 Please note that if the client is a PU 2.1 node, the client should 429 use the maximum I-frame size negotiated in the XID3 exchange. 431 The Initial window size in the START_DL frame gives the receive 432 window size on the originating side, and the target DRAP station 433 returns its receive window size in the DL_STARTED frame. The field is 434 reserved in the START_DL_FAILED frame. The usage of the window size 435 is the same as the one used in DLSw. Please refer to RFC 1795 for 436 details. 438 The last two bits are reserved for future use. They must be set to 439 zero by the sender and ignored by the receiver. 441 If the sender of the START_DL frame did not receive a START_DL_FAILED 442 frame within a recommended threshold value of 60 seconds, the 443 connection is considered unsuccessful. 445 3.4.3. HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames 447 These frame types are used by DRAP to disconnect a link station. A 448 HALT_DL frame is sent directly to the remote workstation to indicate 449 that the sender wishes to disconnect. When the receiver receives this 450 frame, it tears down the session that is associated with the Original 451 Session ID and the Target Session ID provided in the HALT_DL frame. 452 The receiver should respond with the DL_HALTED frame. The DL_HALTED 453 frame should use the same Session ID values as the received HALT_DL 454 message without swapping them. The HALT_DL_NOACK frame is used when 455 the response is not required. 457 +---------------+-----------------------+ 458 | Field Name | Information | 459 +---------------+-----------------------+ 460 | Message Type | 0x0C, 0x0D, or 0x0E | 461 +---------------+-----------------------+ 462 | Packet Length | 0x10 | 463 +---------------+-----------------------+ 464 Figure 3-8. HALT_DL, HALT_DL_NOACK, and DL_HALTED Header 466 +-----------------------------------+ 467 | Field Name (Each row is one byte) | 468 +===================================+ 469 0 | Sender Session ID | 470 + - - - - - - - - - - - - - - - - - + 471 1 | | 472 + - - - - - - - - - - - - - - - - - + 473 2 | | 474 + - - - - - - - - - - - - - - - - - + 475 3 | | 476 +-----------------------------------+ 477 4 | Receiver Session ID | 478 + - - - - - - - - - - - - - - - - - + 479 5 | | 480 + - - - - - - - - - - - - - - - - - + 481 6 | | 482 + - - - - - - - - - - - - - - - - - + 483 7 | | 484 +-----------------------------------+ 485 8 | Reserved | 486 + - - - - - - - - - - - - - - - - - + 487 9 | | 488 + - - - - - - - - - - - - - - - - - + 489 10| | 490 + - - - - - - - - - - - - - - - - - + 491 11| | 492 +-----------------------------------+ 493 Figure 3-9. START_DL, DL_STARTED, and START_DL_FAILED Data 495 3.4.4. XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME, FCM_FRAME, 496 and DGRM_FRAME 498 These frame types are used to carry the end-to-end data or establish 499 a circuit. The Destination Session ID is the Session ID created in 500 the START_DL frame or the DL_STARTED frame by the receiver. The usage 501 of the flow control flag is the same as the one used in DLSw. Please 502 refer to RFC 1795 for details. 504 +---------------+----------------------------+ 505 | Field Name | Information | 506 +---------------+----------------------------+ 507 | Message Type | Based on Message type | 508 +---------------+----------------------------+ 509 | Packet Length | 0x0C + length of user data | 510 +---------------+----------------------------+ 511 Figure 3-10. Generic DRAP Header 513 +-----------------------------------+ 514 | Field Name (Each row is one byte) | 515 +===================================+ 516 0 | Destination Session ID | 517 + - - - - - - - - - - - - - - - - - + 518 1 | | 519 + - - - - - - - - - - - - - - - - - + 520 2 | | 521 + - - - - - - - - - - - - - - - - - + 522 3 | | 523 +-----------------------------------+ 524 4 | Flow Control Flags | 525 +-----------------------------------+ 526 5 | Reserved | 527 + - - - - - - - - - - - - - - - - - + 528 6 | | 529 + - - - - - - - - - - - - - - - - - + 530 7 | | 531 +-----------------------------------+ 532 Figure 3-11. Generic DRAP Data Format 534 3.4.5. DATA_FRAME 536 This frame type is used to send connectionless SNA and NetBIOS 537 Datagram (UI) frames that do not have a link station associated with 538 the source and destination MAC/SAP pair. The difference between 539 DGRM_FRAME and DATA_FRAME is that DGRM_FRAME is used to send UI 540 frames received for stations that have a link station opened, whereas 541 DATA_FRAME is used for frames with no link station established. 543 +---------------+-----------------------------+ 544 | Field Name | Information | 545 +---------------+-----------------------------+ 546 | Message Type | 0x0A | 547 +---------------+-----------------------------+ 548 | Packet Length | 0x10 + Length of user data | 549 +---------------+-----------------------------+ 550 Figure 3-12. DATA_FRAME Header 551 +-----------------------------------+ 552 | Field Name (Each row is one byte) | 553 +===================================+ 554 0 | Host MAC Address | 555 + - - - - - - - - - - - - - - - - - + 556 1 | | 557 + - - - - - - - - - - - - - - - - - + 558 2 | | 559 + - - - - - - - - - - - - - - - - - + 560 3 | | 561 + - - - - - - - - - - - - - - - - - + 562 4 | | 563 + - - - - - - - - - - - - - - - - - + 564 5 | | 565 +-----------------------------------+ 566 6 | Host SAP | 567 +-----------------------------------+ 568 7 | Client SAP | 569 +-----------------------------------+ 570 8 | Broadcast Type | 571 +-----------------------------------+ 572 9 | Reserved | 573 + - - - - - - - - - - - - - - - - - + 574 10| | 575 + - - - - - - - - - - - - - - - - - + 576 11| | 577 +-----------------------------------+ 578 Figure 3-13. DATA_FRAME Data Format 580 The definition of the first 8 bytes is the same as the START_DL 581 frame. The Broadcast Type field indicates the type of broadcast 582 frames in use; Single Route Broadcast, All Route Broadcast, or 583 Directed. The target side will use the same broadcast type. In the 584 case of Directed frame, if the RIF information is known, the target 585 peer can send a directed frame. If not, a Single Route Broadcast 586 frame is sent. 588 3.4.6. CAP_XCHANGE Frame 590 In DRAP, the capability exchange frame is used to exchange the 591 client's information, such as its MAC address, with the server. If a 592 DRAP client has its own MAC address defined, it should put it in the 593 MAC address field. Otherwise, that field must be set to zero. 595 When the DRAP server receives the CAP_XCHANGE frame, it should cache 596 the MAC address if it is non zero. The DRAP server also verifies that 597 the MAC address is unique. The server should return a CAP_XCHANGE 598 response frame with the MAC address supplied by the client if the 599 MAC address is accepted. If a client does not have its own MAC 600 address, the server should assign a MAC address to the client and 601 put that address in the CAP_XCHANGE command frame. 603 A client should record the new MAC address assigned by the server and 604 return a response with the assigned MAC address. If the client cannot 605 accept the assigned MAC address, another CAP_XCHANGE command with the 606 MAC address field set to zero should be sent to the server. The 607 server should allocate a new MAC address for this client. 609 During the capability exchange, both the client and the server can 610 send command frames. The process stops when either side sends a 611 CAP_XCHANGE response frame. When the response frame is sent, the MAC 612 address in the CAP_XCHANGE frame should be the same as the one in the 613 previous received command. The sender of the CAP_XCHANGE response 614 agrees to use the MAC address defined in the previous command. 616 The number of CAP_XCHANGE frames that need to be exchanged is 617 determined by the client and the server independently. When the 618 number of exchange frames has exceeded the pre-defined number set by 619 either the server or the client, the session should be brought down. 621 The flag is used to show the capability of the sender. The following 622 list shows the valid flags: 624 0x01 NetBIOS support. If a client sets this bit on, the server will 625 pass all NetBIOS explorers to this client. If this bit is not 626 set, only SNA traffic will be sent to this client. 628 0x02 TCP Listen Mode support. If a client supports TCP listen mode, 629 the server will keep the client's MAC and IP addresses even 630 after the TCP session is down. The cached information will be 631 used for server to connect out. If a client does not support 632 TCP listen mode, the cache will be deleted as soon as the TCP 633 session is down. 635 0x04 Command/Response. If this bit is set, it is a command, 636 otherwise, it is a response. 638 The values 0x01 and 0x02 are used only by the client. When a server 639 sends the command/response to a client, the server does not return 640 these values. 642 Starting with the Reserved field, implementors can optionally 643 implement the Capability Exchange Control Vector. Each Capability 644 Exchange Control Vector consists of three fields: Length (1 byte), 645 Type (1 byte), and Data (Length - 2 bytes). Two types of Control 646 Vectors are defined: SAP_LIST and VENDOR_CODE (described below). To 647 ensure compatibility, implementors should ignore the unknown 648 Control Vectors instead of treating them as errors. 650 0x01 SAP_LIST. Length: 2+n bytes, where n ranges from 1 to 16. 651 This control vector lists the SAPs that the client can support. 652 The maximum number of SAPs a client can define is 16. Therefore, 653 the length of this Control Vector ranges from 3 to 18. If the 654 SAP_LIST is not specified in the capability exchange, the server 655 assumes that the client can support all the SAP values. For 656 example, if a client can only support SAP 4 and 8, then the 657 following Control Vectors should be sent: "0x04, 0x01, 0x04, 658 0x08". The first byte indicates the length of 4. The second byte 659 indicates the control vector type of SAP_LIST. The last two 660 bytes indicate the supported SAP values; 0x04 and 0x08. This 661 Control Vector is used only by the client. If the server accepts 662 this Control Vector, it must return the same Control Vector to 663 the client. 665 0x02 VENDOR_CODE. Length: 6 bytes. 666 Each vendor is assigned a vendor code that identifies the 667 vendor. This Control Vector does not require a response. 669 After the receiver responds to a Control Vector, if the capability 670 exchange is not done, the sender does not have to send the same 671 Control Vector again. 673 +---------------+-----------------------+ 674 | Field Name | Information | 675 +---------------+-----------------------+ 676 | Message Type | 0x12 | 677 +---------------+-----------------------+ 678 | Packet Length | 0x1C | 679 +---------------+-----------------------+ 680 Figure 3-14. CAP_XCHANGE Header 682 +-----------------------------------+ 683 | Field Name (Each row is one byte) | 684 +===================================+ 685 0 | MAC Address | 686 + - - - - - - - - - - - - - - - - - + 687 1 | | 688 + - - - - - - - - - - - - - - - - - + 689 2 | | 690 + - - - - - - - - - - - - - - - - - + 691 3 | | 692 + - - - - - - - - - - - - - - - - - + 693 4 | | 694 + - - - - - - - - - - - - - - - - - + 695 5 | | 696 +-----------------------------------+ 697 6 | Flag | 698 +-----------------------------------+ 699 7 | Reserved | 700 +-----------------------------------+ 701 Figure 3-15. CAP_XCHANGE Data Format 703 3.4.7. CLOSE_PEER_REQ Frames 705 This frame is used for peer connection management and contains a 706 reason code field. The following list describes the valid reason 707 codes: 709 0x01 System shutdown. This indicates shutdown in progress. 711 0x02 Suspend. This code is used when there is no traffic between the 712 server and the client, and the server or the client wishes to 713 suspend the TCP session. When the TCP session is suspended, all 714 circuits should remain intact. The TCP session should be 715 re-established when new user data needs to be sent. When the TCP 716 session is re-established, there is no need to send the 717 CAP_XCHANGE frame again. 719 0x03 No MAC address available. This code is sent by the server when 720 there is no MAC address is available from the MAC address pool. 722 +---------------+-----------------------+ 723 | Field Name | Information | 724 +---------------+-----------------------+ 725 | Message Type | 0x13 | 726 +---------------+-----------------------+ 727 | Packet Length | 0x08 | 728 +---------------+-----------------------+ 729 Figure 3-16. CLOSE_PEER_REQ Header 731 +-----------------------------------+ 732 | Field Name (Each row is one byte) | 733 +===================================+ 734 0 | Reason Code | 735 +-----------------------------------+ 736 1 | Reserved | 737 + - - - - - - - - - - - - - - - - - + 738 2 | | 739 + - - - - - - - - - - - - - - - - - + 740 3 | | 741 +-----------------------------------+ 742 Figure 3-17. CLOSE_PEER_REQ Data Format 744 3.4.8. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames 746 These three frames are used for peer connection management. There is 747 no data associated with them. 749 o CLOSE_PEER_RSP 750 CLOSE_PEER_RSP is the response for CLOSE_PEER_REQ. 752 o PEER_TEST_REQ and PEER_TEST_RSP 753 PEER_TEST_REQ and PEER_TEST_RSP are used for peer level keepalive. 754 Implementing PEER_TEST_REQ is optional, but PEER_TEST_RSP must be 755 implemented to respond to the PEER_TEST_REQ frame. When a 756 PEER_TEST_REQ frame is sent to the remote station, the sender 757 expects to receive the PEER_TEST_RSP frame in a predefined time 758 interval (the recommended value is 60 seconds). If the 759 PEER_TEST_RSP frame is not received in the predefined time 760 interval, the sender can send the PEER_TEST_REQ frame again. If a 761 predefined number of PEER_TEST_REQ frames is sent to the remote 762 station, but no PEER_TEST_RSP frame is received (the recommended 763 number is 3), the sender should close the TCP session with this 764 remote station and terminate all associated circuits. 766 +---------------+-----------------------+ 767 | Field Name | Information | 768 +---------------+-----------------------+ 769 | Message Type | 0x14, 0x1D, or 0x1E | 770 +---------------+-----------------------+ 771 | Packet Length | 0x04 | 772 +---------------+-----------------------+ 773 Figure 3-18. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP DRAP 775 4. References 777 [1] AIW DLSw Related Interest Group, RFC 1795, 778 "DLSw: Switch-to-Switch Protocol", October 1993 780 [2] IEEE 802.1D Standard 782 Authors' Addresses 784 Steve T. Chiang 785 InterWorks Business Unit 786 Cisco Systems, Inc. 787 170 Tasman Drive 788 San Jose, CA 95134 789 Phone: (408) 526-5189 790 EMail: schiang@cisco.com 792 Joseph S. Lee 793 InterWorks Business Unit 794 Cisco Systems, Inc. 795 170 Tasman Drive 796 San Jose, CA 95134 797 Phone: (408) 526-5232 798 EMail: jolee@cisco.com 800 Hideaki Yasuda 801 System Product Center 802 Network Products Department 803 Network Software Products Section B 804 Mitsubishi Electric Corp. 805 Information Systems Engineering Center 806 325, Kamimachiya Kamakura Kanagawa 247, Japan 807 Phone: +81-467-47-2120 808 EMail: yasuda@eme068.cow.melco.co.jp