idnits 2.17.1 draft-rfced-info-dobbins-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-26) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 311 has weird spacing: '...or, and the o...' == Line 336 has weird spacing: '... If the swi...' -- 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 (April 1997) is 9873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 Network Working Group K. Dobbins 5 Expire in six months T. Grant 6 Category: Informational D. Ruffen 7 E. Ziegler 8 Cabletron Systems Incorporated 9 April 1997 11 Address Resolution and Location Discovery (ARLD) Protocol 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress". 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 The Address Resolution and Location Discovery (ARLD) protocol 36 is part of the InterSwitch Message Protocol (ISMP). ISMP was 37 designed to facilitate interswitch communication within 38 distributed connection-oriented switching networks. The ARLD 39 protocol is used to resolve a packet destination address when 40 the source and destination pair of a packet does not match a 41 known connection. It is also used to provide end-station 42 address mobility between switches. 44 Table of Contents 46 Status of this Memo.....................................1 47 Abstract................................................1 48 1. Introduction........................................2 49 1.1 Data Conventions...............................2 50 2. ISMP Overview.......................................2 51 3. General ISMP Packet Format..........................3 52 3.1 Frame Header...................................3 53 3.2 ISMP Packet Header.............................4 54 3.3 ISMP Message Body..............................5 55 4. ARLD Protocol Operational Overview..................5 56 4.1 Definitions....................................5 57 4.1.1 Address.................................6 58 4.1.2 Undirected Messages.....................6 59 4.1.3 Switch Flood Path.......................6 60 4.1.4 Upstream Neighbor.......................6 61 4.1.5 Downstream Neighbor.....................6 62 4.2 Address Resolution.............................6 63 4.3 End-Station Address Mobility...................7 64 5. Tag/Length/Value (TLV) Format.......................9 65 6. Interswitch Resolve Message........................11 66 7. Interswitch New User Message.......................14 67 References.............................................17 68 Security Considerations................................17 69 Author's Addresses.....................................17 71 1. Introduction 73 This draft is being distributed to members of the Internet 74 community in order to solicit reactions to the proposals 75 contained herein. While the specification discussed here may 76 not be directly relevant to the research problems of the 77 Internet, it may be of interest to researchers and implementers. 79 1.1 Data Conventions 81 The methods used in this memo to describe and picture data 82 adhere to the standards of Internet Protocol documentation 83 [RFC1700], in particular: 85 The convention in the documentation of Internet Protocols 86 is to express numbers in decimal and to picture data in 87 "big-endian" order. That is, fields are described left to 88 right, with the most significant octet on the left and the 89 least significant octet on the right. 91 The order of transmission of the header and data described 92 in this document is resolved to the octet level. Whenever 93 a diagram shows a group of octets, the order of transmission 94 of those octets is the normal order in which they are read 95 in English. 97 Whenever an octet represents a numeric quantity the left 98 most bit in the diagram is the high order or most 99 significant bit. That is, the bit labeled 0 is the most 100 significant bit. 102 Similarly, whenever a multi-octet field represents a 103 numeric quantity the left most bit of the whole field is 104 the most significant bit. When a multi-octet quantity is 105 transmitted the most significant octet is transmitted 106 first. 108 2. ISMP Overview 110 The InterSwitch Message Protocol (ISMP) is used for interswitch 111 communication within distributed connection-oriented switching 112 networks. ISMP provides the following services: 114 - Topology services. Each switch maintains a distributed 115 topology of the switch fabric by exchanging the following 116 interswitch messages with other switches: 118 - Interswitch Keepalive messages (SNDM protocol) are sent by 119 each switch to announce its existence to its neighboring 120 switches and to establish the topology of the switch 121 fabric. 123 - Interswitch Spanning Tree BPDU messages and Interswitch 124 Remote Blocking messages (LSMP protocol) are used to 125 determine and maintain a loop-free flood path between all 126 network switches in the fabric. This flood path is used 127 for all undirected interswitch messages -- that is, 128 messages of the ARLD, SBCD and SFCT protocols. 130 - Interswitch Link State messages (VLS protocol) are used 131 to determine and maintain a fully connected mesh topology 132 graph of the switch fabric. Call-originating switches use 133 the topology graph to determine the path over which to 134 route a call connection. 136 - Address resolution services. Interswitch Resolve messages 137 (ARLD protocol) are used to resolve a packet destination 138 address when the packet source and destination pair does not 139 match a known connection. Interswitch New User messages 140 (also part of the ARLD protocol) are used to provide end- 141 station address mobility between switches. 143 - Tag-based flooding. A tag-based broadcast method (SBCD 144 protocol) is used to restrict the broadcast of unresolved 145 packets to only those ports within the fabric that belong to 146 the same VLAN as the source. 148 - Call tapping services. Interswitch Tap messages (SFCT 149 protocol) are used to monitor traffic moving between two end 150 stations. Traffic can be monitored in one or both 151 directions along the connection path. 153 NOTE 155 This document describes the ARLD protocol. 156 Other ISMP protocols are described in other 157 RFCs. See the References section for a 158 list of these related RFCs. 160 3. General ISMP Packet Format 162 ISMP packets are of variable length and have the following 163 general structure: 165 - Frame header 166 - ISMP packet header 167 - ISMP message body 169 3.1 Frame Header 171 ISMP packets are encapsulated within an IEEE 802-compliant 172 frame using a standard header as shown below: 174 0 1 2 3 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 00 | | 178 + Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 04 | | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address + 181 08 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 12 | Type | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 185 16 | | 186 + + 187 : : 189 Destination address 191 This 6-octet field contains the Media Access Control (MAC) 192 address of the multicast channel over which all switches in 193 the fabric receive ISMP packets. The destination address of 194 all ISMP packets contain a value of 01-00-1D-00-00-00. 196 Source address 198 This 6-octet field contains the physical (MAC) address of 199 the switch originating the ISMP packet. 201 Type 203 This 2-octet field identifies the type of data carried 204 within the frame. The type field of ISMP packets contains 205 the value 0x81FD. 207 3.2 ISMP Packet Header 209 The ISMP packet header consists of 6 octets, as shown below: 211 0 1 2 3 212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 00 |///////////////////////////////////////////////////////////////| 215 ://////// Frame header /////////////////////////////////////////: 216 +//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 12 |///////////////////////////////| Version | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 16 | ISMP message type | Sequence number | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 20 | | 222 + + 223 : : 225 Frame header 227 This 14-octet field contains the frame header. 229 Version 231 This 2-octet field contains the version number of the 232 InterSwitch Message Protocol to which this ISMP packet 233 adheres. This document describes ISMP Version 2.0. 235 ISMP message type 237 This 2-octet field contains a value indicating which type of 238 ISMP message is contained within the message body. Valid 239 values are as follows: 241 1 (reserved) 242 2 Interswitch Keepalive messages (SNDM protocol) 243 3 Interswitch Link State messages (VLS protocol) 244 4 Interswitch Spanning Tree BPDU messages and Remote 245 Blocking messages (LSMP protocol) 246 5 Interswitch Resolve and New User messages (ARLD 247 protocol) 248 6 (reserved) 249 7 Tag-Based Flood messages (SBCD protocol) 250 8 Interswitch Tap messages (SFCT protocol) 252 ARLD protocol messages have a message type of 5. 254 Sequence number 256 This 2-octet field contains an internally generated sequence 257 number used by the various protocol handlers for internal 258 synchronization of messages. 260 3.3 ISMP Message Body 262 The ISMP message body is a variable-length field containing the 263 actual data of the ISMP message. The length and content of 264 this field are determined by the value found in the message 265 type field. 267 4. ARLD Protocol Operational Overview 269 The ARLD protocol provides two services: 271 - Resolution of packet destination addresses 272 - End-station address mobility between switches 274 4.1 Definitions 276 The following terms are used in this description of the ARLD 277 protocol. 279 4.1.1 Address 281 Within most computer networks, the concept of "address" is 282 somewhat elusive because different protocols can (and do) use 283 different addressing schemes and formats. To distinguish 284 between the various protocol-specific forms of addressing, 285 ARLD messages specify addresses in a format known as 286 Tag/Length/Value (TLV), unless otherwise noted in the text. 287 (See Tag/Length/Value (TLV) Format for a description of this 288 format.). 290 4.1.2 Undirected Messages 292 Undirected messages are those messages that are (potentially) 293 sent to all switches in the switch fabric -- that is, they are 294 not directed to any particular switch. ISMP messages of the 295 SBCD, ARLD, and SFCT protocols are undirected messages. 297 4.1.3 Switch Flood Path 299 The switch flood path is used to send undirected ISMP messages 300 throughout the switch fabric. The flood path is formed using a 301 spanning tree algorithm that provides a single path through the 302 switch fabric and guarantees loop-free delivery to every other 303 switch in the fabric. 305 4.1.4 Upstream Neighbor 307 A switch's upstream neighbor is that switch connected to the 308 incoming link of the switch flood path -- that is, the switch 309 from which the undirected message was received. Note that each 310 switch receiving an undirected message has, at most, one 311 upstream neighbor, and the originator of any undirected ISMP 312 message has no upstream neighbors. 314 4.1.5 Downstream Neighbor 316 A switch's downstream neighbors are those switches connected to 317 all outgoing links of the flood path except the link over which 318 the undirected message was received. Note that for each 319 undirected message some number of switches have no downstream 320 neighbors. 322 4.2 Address Resolution 324 When a switch receives a packet on one of its local access 325 ports, it examines the destination address of the packet to try 326 to determine where the packet should be sent -- that is, it 327 tries to "resolve" the destination address. 329 There are a variety of circumstances under which a switch may 330 not be able to resolve an address. For example, the address 331 may be a physical MAC address that the switch has not 332 previously encountered, or the address may be a high-level 333 network address (such as an IP address) for which the switch 334 has no MAC address mapping. 336 If the switch cannot resolve the address from within its own 337 local database, it formats and sends an Interswitch Resolve 338 request message to other switches in the switch fabric. The 339 Interswitch Resolve request message contains the destination 340 address as it was received within the packet, along with a list 341 of requested addressing information. 343 When a switch receives an Interswitch Resolve request message 344 from one of its upstream neighbors, it checks to see if the 345 destination end station is connected to one of its local access 346 ports. If so, it formulates an Interswitch Resolve response 347 message by filling in the requested address information, along 348 with its own MAC address. It then sets the message status 349 field to ResolveAck, and returns the message to its upstream 350 (requesting) neighbor. 352 If the switch cannot resolve the address, it forwards the 353 Interswitch Resolve request message to its downstream 354 neighbors. If the switch has no downstream neighbors, it sets 355 the message status field to Unknown, and returns the message to 356 its upstream (requesting) neighbor. 358 When a switch forwards an Interswitch Resolve request message 359 to its downstream neighbors, it keeps track of the number of 360 requests it has sent out and received back. It will only 361 respond back to its upstream (requesting) neighbor when one of 362 the following conditions occurs: 364 - It receives any response with a status of ResolveAck 365 - All downstream neighbors have responded with a status of 366 Unknown 368 Note that any Interswitch Resolve request message that is not 369 responded to within a certain predetermined time (currently 5 370 seconds) is assumed to have a response status of Unknown. 372 If the destination end station address cannot be resolved by 373 the above method, the originating switch will flood the packet 374 to the source VLAN using the Tag Based Flood message (SBCD 375 protocol). 377 4.3 End-Station Address Mobility 379 When a switch detects a new end-station address on one of its 380 local ports, it sends an Interswitch New User request message 381 over the switch flood path to all other switches in the fabric. 382 The purpose of the Interswitch New User request is two-fold: 384 - It informs the other switches that the end-station address 385 has changed and any entries for that end station in local 386 databases should be dealt with appropriately. 388 - It requests information about the static VLAN(s) to which 389 the end station has been assigned. 391 When a switch receives an Interswitch New User request message 392 from one of its upstream neighbors, it first forwards the 393 message to all its downstream neighbors. No actual processing 394 or VLAN resolution is attempted until the message reaches the 395 end of the flood path and begins its trip back along the return 396 path. This ensures that all switches in the fabric receive 397 notification of the new user and have synchronized their 398 databases. 400 If a switch receives an Interswitch New User request message 401 but has no downstream neighbors, it does the following: 403 - If the end station was previously connected to one of the 404 switch's local ports, the switch formulates an Interswitch 405 New User Response message by loading the VLAN identifier(s) 406 of the static VLAN(s) to which the end station was assigned, 407 along with its own MAC address. (VLAN identifiers are 408 stored in Tag/Length/Value (TLV) format.) The switch then 409 sets the message status field to NewUserAck, and returns the 410 message to its upstream (requesting) neighbor. 412 Otherwise, the switch sets the status field to 413 NewUserUnknown and returns the message to its upstream 414 neighbor. 416 - The switch then deletes the end station from its local 417 database, as well as any entries associated with the end 418 station in its connection table. 420 When a switch forwards an Interswitch New User request message 421 to its downstream neighbors, it keeps track of the number of 422 requests it has sent out and does not respond back to its 423 upstream neighbor until all requests have been responded to. 425 - As each response is received, the switch checks the status 426 field of the message. If the status is NewUserAck, the 427 switch retains the information in that response. When all 428 requests have been responded to, the switch returns the 429 NewUserAck response to its upstream neighbor. 431 - If all the Interswitch New User Request messages have been 432 responded to with a status of NewUserUnknown, the switch 433 checks to see if the end station was previously connected to 434 one of its local ports. If so, the switch formulates an 435 Interswitch New User Response message by loading the VLAN 436 identifier(s) of the static VLAN(s) to which the end station 437 was assigned, along with its own MAC address. (VLAN 438 identifiers are stored in Tag/Length/Value (TLV) format.) 439 The switch then sets the message status field to NewUserAck, 440 and returns the message to its upstream (requesting) 441 neighbor. 443 Otherwise, the switch sets the status field to 444 NewUserUnknown and returns the message to its upstream 445 neighbor. 447 - The switch then deletes the end station from its local 448 database, as well as any entries associated with the end 449 station in its connection table. 451 When the originating switch has received responses to all the 452 Interswitch New User Request messages it has sent, it does the 453 following: 455 - If it has received a response message with a status of 456 NewUserAck, it loads the new VLAN information into its local 457 database. 459 - If all responses have been received with a status of 460 NewUserUnknown, the originating switch assumes that the end 461 station was not previously connected anywhere in the network 462 and assigns it to a VLAN according to the VLAN membership 463 rules and order of precedence. 465 If any Interswitch New User Request message has not been 466 responded to within a certain predetermined time (currently 5 467 seconds), the originating switch recalculates the flood path 468 and resends the Interswitch New User Request message. 470 5. Tag/Length/Value (TLV) Format 472 Within most computer networks, the concept of "address" is 473 somewhat elusive because different protocols can (and do) use 474 different addressing schemes and formats. For example, 475 Ethernet (physical layer) addresses are six octets long, while 476 IP (network layer) addresses are only four octets long. 478 To distinguish between the various protocol-specific forms of 479 addressing, ARLD messages specify addresses in a format known 480 as Tag/Length/Value (TLV). This format uses a variable-length 481 construct as shown below: 483 0 1 2 3 484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 : Tag : 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Value length | | 491 +-+-+-+-+-+-+-+-+ + 492 | Address value | 493 : : 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Tag 499 This variable-length field specifies the type of address 500 contained in the structure. Note that the tag itself is a 501 complex structure consisting of a single octet containing 502 the length of the ASCII tag identifier string and a variable 503 number of octets containing the value of the identifier, as 504 shown below: 506 0 1 2 3 507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Tag ID length | | 510 +-+-+-+-+-+-+-+-+ + 511 | Tag identifier | 512 : : 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 The following address tag identifiers are currently defined: 518 ID string ID length 520 address.ethernet 16 521 address.ip 10 522 address.ip.udp 14 523 address.ipx 11 524 address.netbios 15 525 address.vlan 12 526 address.hostname 16 528 Value length 530 This 1-octet field contains the length of the value of the 531 address. The valid lengths associated with the currently 532 defined address types are shown below: 534 Identifier Value length 536 address.ethernet 6 537 address.ip 4 538 address.ip.udp 2 539 address.ipx 10 540 address.netbios 16 541 address.vlan <16 542 address.hostname <256 544 Address value 546 This variable-length field contains the value of the 547 address. The length of this field is stored in the Value 548 length field. 550 6. Interswitch Resolve Message 552 The ARLD Interswitch Resolve message consists of a variable 553 number of octets, as shown below: 555 0 1 2 3 556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 00 | | 559 + Frame header / + 560 : ISMP packet header : 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 20 | ARLD version | Opcode | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 24 | Status | Call Tag | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 28 | | 568 + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 32 | | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + 571 36 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 40 | | 574 + Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 44 | | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 577 48 | | 578 : Known destination address : 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 n | Count | | 582 +-+-+-+-+-+-+-+-+ + 583 n1 | Resolve list | 584 : : 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 n = 46 + length of known address TLV 588 n1 = n + 4 590 In the following description of the message fields, the term 591 "originating" switch refers to the switch that issued the 592 original Interswitch Resolve request. The term "owner" switch 593 refers to that switch to which the destination end station is 594 attached. And the term "responding" switch refers to either 595 the "owner" switch or to a switch at the end of the control 596 path that does not own the end station but issues an 597 Interswitch Resolve response because it has no downstream 598 neighbors. 600 With the exception of the resolve list (which has a different 601 size and format in a Resolve response message), all fields of 602 an Interswitch Resolve message are allocated by the originating 603 switch, and unless otherwise noted below, are written by the 604 originating switch. 606 Frame header/ISMP packet header 608 This 20-octet field contains the frame header and the ISMP 609 packet header. 611 ARLD version 613 This 2-octet field contains the version number of the ARLD 614 protocol to which this message adheres. This document 615 describes ARLD Version 1. 617 Opcode 619 This 2-octet field contains the operation code of the 620 message. Valid values are as follows: 622 1 The message is a Resolve request. 623 2 The message is a Resolve response. 624 3 (unused in Resolve messages) 625 4 (unused in Resolve messages) 627 The originating switch writes a value of 1 to this field, 628 while the responding switch writes a value of 2. 630 Status 632 This 2-octet field contains the status of a Resolve response 633 message. Valid values are as follows: 635 0 The Resolve request succeeded (ResolveAck). 636 1 (unused) 637 2 The Resolve request failed (Unknown). 639 This field is written by the responding switch. 641 Call tag 643 This 2-octet field contains the call tag of the end station 644 packet for which this Resolve request is issued. The call 645 tag is a 16-bit value (generated by the originating switch) 646 that uniquely identifies the packet. 648 Source MAC of packet 650 This 6-octet field contains the physical (MAC) address of 651 the end station that originated the packet identified by the 652 call tag. 654 Originating switch MAC 656 This 6-octet field contains the physical (MAC) address of 657 the switch that issued the original Resolve request. 659 Owner switch MAC 661 This 6-octet field contains the physical (MAC) address of 662 the switch to which the destination end station is attached 663 -- that is, the switch that was able to resolve the 664 requested addressing information. This field is written by 665 the owner switch. 667 If the status of the response is Unknown, this field is 668 irrelevant. 670 Known destination address 672 This variable-length field contains the known attribute of 673 the destination end-station address. This address is stored 674 in Tag/Length/Value format. 676 Count 678 This 1-octet field contains the number of address attributes 679 requested or returned. This is the number of items in the 680 resolve list. 682 Resolve list 684 This variable-length field contains a list of the address 685 attributes either requested by the originating switch or 686 returned by the owner switch. Note that in a Resolve 687 request message, this list contains only the tags of the 688 requested address attributes. On the other hand, a Resolve 689 response message with a status of ResolveAck contains the 690 full TLV of each resolved address attribute. The number of 691 entries in the list is specified in the count field. 693 In an Interswitch Resolve response message, this field is 694 irrelevant if the status of the response is Unknown. 696 7. Interswitch New User Message 698 The ARLD Interswitch New User message consists of a variable 699 number of octets, as shown below: 701 0 1 2 3 702 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 00 | | 705 + Frame header / + 706 : ISMP packet header : 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 20 | ARLD version | Opcode | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 24 | Status | Call Tag | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 28 | | 714 + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 32 | | | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + 717 36 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 40 | | 720 + Previous owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 44 | | | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 723 48 | : 724 : MAC address of new user + 725 | | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 70 | Count | | 728 +-+-+-+-+-+-+-+-+ + 729 74 | Resolve list | 730 : : 731 | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 In the following description of the message fields, the term 735 "originating" switch refers to the switch that issued the 736 original Interswitch New User request. The term "previous 737 owner" switch refers to that switch to which the end station 738 was previously attached. And the term "responding" switch 739 refers to either the "previous owner" switch or to a switch at 740 the end of the control path that did not own the end station 741 but issues an Interswitch New User response because it has no 742 downstream neighbors. 744 With the exception of the resolve list, all fields of an 745 Interswitch New User message are allocated by the originating 746 switch, and unless otherwise noted below, are written by the 747 originating switch. 749 Frame header/ISMP packet header 751 This 20-octet field contains the frame header and the ISMP 752 packet header. 754 ARLD version 756 This 2-octet field contains the version number of the ARLD 757 protocol to which this message adheres. This document 758 describes ARLD Version 1. 760 Opcode 762 This 2-octet field contains the operation code of the 763 message. Valid values are as follows: 765 1 (unused in a New User message) 766 2 (unused in a New User message) 767 3 The message is a New User request. 768 4 The message is a New User response. 770 The originating switch writes a value of 3 to this field, 771 while the responding switch writes a value of 4. 773 Status 775 This 2-octet field contains the status of a New User 776 response message. Valid values are as follows: 778 0 The end station VLAN(s) was successfully resolved 779 (NewUserAck). 780 1 (unused) 781 2 The end station VLAN(s) was not resolved 782 (NewUserUnknown). 784 This field is written by the responding switch. 786 Call tag 788 This 2-octet field contains the call tag of the end station 789 packet for which this New User request is issued. The call 790 tag is a 16-bit value (generated by the originating switch) 791 that uniquely identifies the packet that caused the switch 792 to identify the end station as a new user. 794 Source MAC of packet 796 This 6-octet field contains the physical (MAC) address of 797 the end station that originated the packet identified by the 798 call tag. 800 Originating switch MAC 802 This 6-octet field contains the physical (MAC) address of 803 the switch that issued the original New User request. 805 Previous owner switch MAC 807 This 6-octet field contains the physical (MAC) address of 808 the switch to which the end station was previously attached 809 -- that is, the switch that was able to resolve the VLAN 810 information. This field is written by the previous owner 811 switch. 813 If the status of the response is Unknown, this field is 814 irrelevant. 816 MAC address of new user 818 This 24-octet field contains the physical (MAC) address of 819 the new user end-station, stored in Tag/Length/Value format. 821 Count 823 This 1-octet field contains the number of VLAN identifiers 824 returned. This is the number of items in the resolve list. 825 This field is written by the previous owner switch. 827 If the status of the response is Unknown, this field and the 828 resolve list are irrelevant. 830 Resolve list 832 This variable-length field contains a list of the VLAN 833 identifiers of all static VLANs to which the end station 834 belongs, stored in Tag/Length/Value format. The number of 835 entries in the list is specified in the count field. This 836 list is written by the previous owner switch. 838 If the status of the response is Unknown, this field is 839 irrelevant. 841 References 843 [RFC1700] Reynolds, S.J., Postel, J. Assigned Numbers. 844 October 1994. 846 Dobbins, K., et. al. ARLD Protocol Specification 847 Work in Progress. 849 Dobbins, K., et. al. ISM Protocol Specification 850 Work in Progress. 852 Dobbins, K., et. al. LSMP Protocol Specification 853 Work in Progress. 855 Dobbins, K., et. al. SBCD Protocol Specification 856 Work in Progress. 858 Dobbins, K., et. al. SNDM Protocol Specification 859 Work in Progress. 861 Dobbins, K., et. al. VLS Protocol Specification 862 Work in Progress. 864 Security Considerations 866 Security issues are not discussed in this document. 868 Authors' Addresses 870 Cabletron Systems, Inc., is located at: 872 Post Office Box 5005 873 Rochester, NH 03866-5005 874 (603) 332-9400 876 Kurt Dobbins Email: dobbins@ctron.com 877 Tom Grant Email: tgrant@ctron.com 878 Dave Ruffen Email: ruffen@ctron.com 879 Eric Ziegler Email: ziegler@ctron.com 881 INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT