INTERNET-DRAFT Network Working Group K. Dobbins Expire in six months T. Grant Category: Informational D. Ruffen E. Ziegler Cabletron Systems Incorporated April 1997 Address Resolution and Location Discovery (ARLD) Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Address Resolution and Location Discovery (ARLD) protocol is part of the InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate interswitch communication within distributed connection-oriented switching networks. The ARLD protocol is used to resolve a packet destination address when the source and destination pair of a packet does not match a known connection. It is also used to provide end-station address mobility between switches. Table of Contents Status of this Memo.....................................1 Abstract................................................1 1. Introduction........................................2 1.1 Data Conventions...............................2 2. ISMP Overview.......................................2 3. General ISMP Packet Format..........................3 3.1 Frame Header...................................3 3.2 ISMP Packet Header.............................4 3.3 ISMP Message Body..............................5 4. ARLD Protocol Operational Overview..................5 4.1 Definitions....................................5 4.1.1 Address.................................6 4.1.2 Undirected Messages.....................6 4.1.3 Switch Flood Path.......................6 4.1.4 Upstream Neighbor.......................6 4.1.5 Downstream Neighbor.....................6 4.2 Address Resolution.............................6 4.3 End-Station Address Mobility...................7 5. Tag/Length/Value (TLV) Format.......................9 6. Interswitch Resolve Message........................11 7. Interswitch New User Message.......................14 References.............................................17 Security Considerations................................17 Author's Addresses.....................................17 K. Dobbins, et. al. [Page 1] DRAFT ARLD Protocol Specification April 1997 1. Introduction This draft is being distributed to members of the Internet community in order to solicit reactions to the proposals contained herein. While the specification discussed here may not be directly relevant to the research problems of the Internet, it may be of interest to researchers and implementers. 1.1 Data Conventions The methods used in this memo to describe and picture data adhere to the standards of Internet Protocol documentation [RFC1700], in particular: The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data in "big-endian" order. That is, fields are described left to right, with the most significant octet on the left and the least significant octet on the right. The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. 2. ISMP Overview The InterSwitch Message Protocol (ISMP) is used for interswitch communication within distributed connection-oriented switching networks. ISMP provides the following services: - Topology services. Each switch maintains a distributed topology of the switch fabric by exchanging the following interswitch messages with other switches: - Interswitch Keepalive messages (SNDM protocol) are sent by each switch to announce its existence to its neighboring switches and to establish the topology of the switch fabric. K. Dobbins, et. al. [Page 2] DRAFT ARLD Protocol Specification April 1997 - Interswitch Spanning Tree BPDU messages and Interswitch Remote Blocking messages (LSMP protocol) are used to determine and maintain a loop-free flood path between all network switches in the fabric. This flood path is used for all undirected interswitch messages -- that is, messages of the ARLD, SBCD and SFCT protocols. - Interswitch Link State messages (VLS protocol) are used to determine and maintain a fully connected mesh topology graph of the switch fabric. Call-originating switches use the topology graph to determine the path over which to route a call connection. - Address resolution services. Interswitch Resolve messages (ARLD protocol) are used to resolve a packet destination address when the packet source and destination pair does not match a known connection. Interswitch New User messages (also part of the ARLD protocol) are used to provide end- station address mobility between switches. - Tag-based flooding. A tag-based broadcast method (SBCD protocol) is used to restrict the broadcast of unresolved packets to only those ports within the fabric that belong to the same VLAN as the source. - Call tapping services. Interswitch Tap messages (SFCT protocol) are used to monitor traffic moving between two end stations. Traffic can be monitored in one or both directions along the connection path. NOTE This document describes the ARLD protocol. Other ISMP protocols are described in other RFCs. See the References section for a list of these related RFCs. 3. General ISMP Packet Format ISMP packets are of variable length and have the following general structure: - Frame header - ISMP packet header - ISMP message body 3.1 Frame Header ISMP packets are encapsulated within an IEEE 802-compliant frame using a standard header as shown below: K. Dobbins, et. al. [Page 3] DRAFT ARLD Protocol Specification April 1997 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address + 08 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 | | + + : : Destination address This 6-octet field contains the Media Access Control (MAC) address of the multicast channel over which all switches in the fabric receive ISMP packets. The destination address of all ISMP packets contain a value of 01-00-1D-00-00-00. Source address This 6-octet field contains the physical (MAC) address of the switch originating the ISMP packet. Type This 2-octet field identifies the type of data carried within the frame. The type field of ISMP packets contains the value 0x81FD. 3.2 ISMP Packet Header The ISMP packet header consists of 6 octets, as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 |///////////////////////////////////////////////////////////////| ://////// Frame header /////////////////////////////////////////: +//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 |///////////////////////////////| Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | ISMP message type | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | + + : : K. Dobbins, et. al. [Page 4] DRAFT ARLD Protocol Specification April 1997 Frame header This 14-octet field contains the frame header. Version This 2-octet field contains the version number of the InterSwitch Message Protocol to which this ISMP packet adheres. This document describes ISMP Version 2.0. ISMP message type This 2-octet field contains a value indicating which type of ISMP message is contained within the message body. Valid values are as follows: 1 (reserved) 2 Interswitch Keepalive messages (SNDM protocol) 3 Interswitch Link State messages (VLS protocol) 4 Interswitch Spanning Tree BPDU messages and Remote Blocking messages (LSMP protocol) 5 Interswitch Resolve and New User messages (ARLD protocol) 6 (reserved) 7 Tag-Based Flood messages (SBCD protocol) 8 Interswitch Tap messages (SFCT protocol) ARLD protocol messages have a message type of 5. Sequence number This 2-octet field contains an internally generated sequence number used by the various protocol handlers for internal synchronization of messages. 3.3 ISMP Message Body The ISMP message body is a variable-length field containing the actual data of the ISMP message. The length and content of this field are determined by the value found in the message type field. 4. ARLD Protocol Operational Overview The ARLD protocol provides two services: - Resolution of packet destination addresses - End-station address mobility between switches 4.1 Definitions The following terms are used in this description of the ARLD protocol. K. Dobbins, et. al. [Page 5] DRAFT ARLD Protocol Specification April 1997 4.1.1 Address Within most computer networks, the concept of "address" is somewhat elusive because different protocols can (and do) use different addressing schemes and formats. To distinguish between the various protocol-specific forms of addressing, ARLD messages specify addresses in a format known as Tag/Length/Value (TLV), unless otherwise noted in the text. (See Tag/Length/Value (TLV) Format for a description of this format.). 4.1.2 Undirected Messages Undirected messages are those messages that are (potentially) sent to all switches in the switch fabric -- that is, they are not directed to any particular switch. ISMP messages of the SBCD, ARLD, and SFCT protocols are undirected messages. 4.1.3 Switch Flood Path The switch flood path is used to send undirected ISMP messages throughout the switch fabric. The flood path is formed using a spanning tree algorithm that provides a single path through the switch fabric and guarantees loop-free delivery to every other switch in the fabric. 4.1.4 Upstream Neighbor A switch's upstream neighbor is that switch connected to the incoming link of the switch flood path -- that is, the switch from which the undirected message was received. Note that each switch receiving an undirected message has, at most, one upstream neighbor, and the originator of any undirected ISMP message has no upstream neighbors. 4.1.5 Downstream Neighbor A switch's downstream neighbors are those switches connected to all outgoing links of the flood path except the link over which the undirected message was received. Note that for each undirected message some number of switches have no downstream neighbors. 4.2 Address Resolution When a switch receives a packet on one of its local access ports, it examines the destination address of the packet to try to determine where the packet should be sent -- that is, it tries to "resolve" the destination address. There are a variety of circumstances under which a switch may not be able to resolve an address. For example, the address may be a physical MAC address that the switch has not K. Dobbins, et. al. [Page 6] DRAFT ARLD Protocol Specification April 1997 previously encountered, or the address may be a high-level network address (such as an IP address) for which the switch has no MAC address mapping. If the switch cannot resolve the address from within its own local database, it formats and sends an Interswitch Resolve request message to other switches in the switch fabric. The Interswitch Resolve request message contains the destination address as it was received within the packet, along with a list of requested addressing information. When a switch receives an Interswitch Resolve request message from one of its upstream neighbors, it checks to see if the destination end station is connected to one of its local access ports. If so, it formulates an Interswitch Resolve response message by filling in the requested address information, along with its own MAC address. It then sets the message status field to ResolveAck, and returns the message to its upstream (requesting) neighbor. If the switch cannot resolve the address, it forwards the Interswitch Resolve request message to its downstream neighbors. If the switch has no downstream neighbors, it sets the message status field to Unknown, and returns the message to its upstream (requesting) neighbor. When a switch forwards an Interswitch Resolve request message to its downstream neighbors, it keeps track of the number of requests it has sent out and received back. It will only respond back to its upstream (requesting) neighbor when one of the following conditions occurs: - It receives any response with a status of ResolveAck - All downstream neighbors have responded with a status of Unknown Note that any Interswitch Resolve request message that is not responded to within a certain predetermined time (currently 5 seconds) is assumed to have a response status of Unknown. If the destination end station address cannot be resolved by the above method, the originating switch will flood the packet to the source VLAN using the Tag Based Flood message (SBCD protocol). 4.3 End-Station Address Mobility When a switch detects a new end-station address on one of its local ports, it sends an Interswitch New User request message over the switch flood path to all other switches in the fabric. The purpose of the Interswitch New User request is two-fold: K. Dobbins, et. al. [Page 7] DRAFT ARLD Protocol Specification April 1997 - It informs the other switches that the end-station address has changed and any entries for that end station in local databases should be dealt with appropriately. - It requests information about the static VLAN(s) to which the end station has been assigned. When a switch receives an Interswitch New User request message from one of its upstream neighbors, it first forwards the message to all its downstream neighbors. No actual processing or VLAN resolution is attempted until the message reaches the end of the flood path and begins its trip back along the return path. This ensures that all switches in the fabric receive notification of the new user and have synchronized their databases. If a switch receives an Interswitch New User request message but has no downstream neighbors, it does the following: - If the end station was previously connected to one of the switch's local ports, the switch formulates an Interswitch New User Response message by loading the VLAN identifier(s) of the static VLAN(s) to which the end station was assigned, along with its own MAC address. (VLAN identifiers are stored in Tag/Length/Value (TLV) format.) The switch then sets the message status field to NewUserAck, and returns the message to its upstream (requesting) neighbor. Otherwise, the switch sets the status field to NewUserUnknown and returns the message to its upstream neighbor. - The switch then deletes the end station from its local database, as well as any entries associated with the end station in its connection table. When a switch forwards an Interswitch New User request message to its downstream neighbors, it keeps track of the number of requests it has sent out and does not respond back to its upstream neighbor until all requests have been responded to. - As each response is received, the switch checks the status field of the message. If the status is NewUserAck, the switch retains the information in that response. When all requests have been responded to, the switch returns the NewUserAck response to its upstream neighbor. - If all the Interswitch New User Request messages have been responded to with a status of NewUserUnknown, the switch checks to see if the end station was previously connected to one of its local ports. If so, the switch formulates an Interswitch New User Response message by loading the VLAN identifier(s) of the static VLAN(s) to which the end station K. Dobbins, et. al. [Page 8] DRAFT ARLD Protocol Specification April 1997 was assigned, along with its own MAC address. (VLAN identifiers are stored in Tag/Length/Value (TLV) format.) The switch then sets the message status field to NewUserAck, and returns the message to its upstream (requesting) neighbor. Otherwise, the switch sets the status field to NewUserUnknown and returns the message to its upstream neighbor. - The switch then deletes the end station from its local database, as well as any entries associated with the end station in its connection table. When the originating switch has received responses to all the Interswitch New User Request messages it has sent, it does the following: - If it has received a response message with a status of NewUserAck, it loads the new VLAN information into its local database. - If all responses have been received with a status of NewUserUnknown, the originating switch assumes that the end station was not previously connected anywhere in the network and assigns it to a VLAN according to the VLAN membership rules and order of precedence. If any Interswitch New User Request message has not been responded to within a certain predetermined time (currently 5 seconds), the originating switch recalculates the flood path and resends the Interswitch New User Request message. 5. Tag/Length/Value (TLV) Format Within most computer networks, the concept of "address" is somewhat elusive because different protocols can (and do) use different addressing schemes and formats. For example, Ethernet (physical layer) addresses are six octets long, while IP (network layer) addresses are only four octets long. To distinguish between the various protocol-specific forms of addressing, ARLD messages specify addresses in a format known as Tag/Length/Value (TLV). This format uses a variable-length construct as shown below: K. Dobbins, et. al. [Page 9] DRAFT ARLD Protocol Specification April 1997 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Tag : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value length | | +-+-+-+-+-+-+-+-+ + | Address value | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag This variable-length field specifies the type of address contained in the structure. Note that the tag itself is a complex structure consisting of a single octet containing the length of the ASCII tag identifier string and a variable number of octets containing the value of the identifier, as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag ID length | | +-+-+-+-+-+-+-+-+ + | Tag identifier | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following address tag identifiers are currently defined: ID string ID length address.ethernet 16 address.ip 10 address.ip.udp 14 address.ipx 11 address.netbios 15 address.vlan 12 address.hostname 16 Value length This 1-octet field contains the length of the value of the address. The valid lengths associated with the currently defined address types are shown below: K. Dobbins, et. al. [Page 10] DRAFT ARLD Protocol Specification April 1997 Identifier Value length address.ethernet 6 address.ip 4 address.ip.udp 2 address.ipx 10 address.netbios 16 address.vlan <16 address.hostname <256 Address value This variable-length field contains the value of the address. The length of this field is stored in the Value length field. 6. Interswitch Resolve Message The ARLD Interswitch Resolve message consists of a variable number of octets, as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Frame header / + : ISMP packet header : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | ARLD version | Opcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Status | Call Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | | + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + 36 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | | + Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 48 | | : Known destination address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n | Count | | +-+-+-+-+-+-+-+-+ + n1 | Resolve list | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K. Dobbins, et. al. [Page 11] DRAFT ARLD Protocol Specification April 1997 n = 46 + length of known address TLV n1 = n + 4 In the following description of the message fields, the term "originating" switch refers to the switch that issued the original Interswitch Resolve request. The term "owner" switch refers to that switch to which the destination end station is attached. And the term "responding" switch refers to either the "owner" switch or to a switch at the end of the control path that does not own the end station but issues an Interswitch Resolve response because it has no downstream neighbors. With the exception of the resolve list (which has a different size and format in a Resolve response message), all fields of an Interswitch Resolve message are allocated by the originating switch, and unless otherwise noted below, are written by the originating switch. Frame header/ISMP packet header This 20-octet field contains the frame header and the ISMP packet header. ARLD version This 2-octet field contains the version number of the ARLD protocol to which this message adheres. This document describes ARLD Version 1. Opcode This 2-octet field contains the operation code of the message. Valid values are as follows: 1 The message is a Resolve request. 2 The message is a Resolve response. 3 (unused in Resolve messages) 4 (unused in Resolve messages) The originating switch writes a value of 1 to this field, while the responding switch writes a value of 2. Status This 2-octet field contains the status of a Resolve response message. Valid values are as follows: 0 The Resolve request succeeded (ResolveAck). 1 (unused) 2 The Resolve request failed (Unknown). K. Dobbins, et. al. [Page 12] DRAFT ARLD Protocol Specification April 1997 This field is written by the responding switch. Call tag This 2-octet field contains the call tag of the end station packet for which this Resolve request is issued. The call tag is a 16-bit value (generated by the originating switch) that uniquely identifies the packet. Source MAC of packet This 6-octet field contains the physical (MAC) address of the end station that originated the packet identified by the call tag. Originating switch MAC This 6-octet field contains the physical (MAC) address of the switch that issued the original Resolve request. Owner switch MAC This 6-octet field contains the physical (MAC) address of the switch to which the destination end station is attached -- that is, the switch that was able to resolve the requested addressing information. This field is written by the owner switch. If the status of the response is Unknown, this field is irrelevant. Known destination address This variable-length field contains the known attribute of the destination end-station address. This address is stored in Tag/Length/Value format. Count This 1-octet field contains the number of address attributes requested or returned. This is the number of items in the resolve list. Resolve list This variable-length field contains a list of the address attributes either requested by the originating switch or returned by the owner switch. Note that in a Resolve request message, this list contains only the tags of the requested address attributes. On the other hand, a Resolve response message with a status of ResolveAck contains the full TLV of each resolved address attribute. The number of entries in the list is specified in the count field. K. Dobbins, et. al. [Page 13] DRAFT ARLD Protocol Specification April 1997 In an Interswitch Resolve response message, this field is irrelevant if the status of the response is Unknown. 7. Interswitch New User Message The ARLD Interswitch New User message consists of a variable number of octets, as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + Frame header / + : ISMP packet header : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | ARLD version | Opcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Status | Call Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | | + Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC + 36 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | | + Previous owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 48 | : : MAC address of new user + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | Count | | +-+-+-+-+-+-+-+-+ + 74 | Resolve list | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the following description of the message fields, the term "originating" switch refers to the switch that issued the original Interswitch New User request. The term "previous owner" switch refers to that switch to which the end station was previously attached. And the term "responding" switch refers to either the "previous owner" switch or to a switch at the end of the control path that did not own the end station but issues an Interswitch New User response because it has no downstream neighbors. K. Dobbins, et. al. [Page 14] DRAFT ARLD Protocol Specification April 1997 With the exception of the resolve list, all fields of an Interswitch New User message are allocated by the originating switch, and unless otherwise noted below, are written by the originating switch. Frame header/ISMP packet header This 20-octet field contains the frame header and the ISMP packet header. ARLD version This 2-octet field contains the version number of the ARLD protocol to which this message adheres. This document describes ARLD Version 1. Opcode This 2-octet field contains the operation code of the message. Valid values are as follows: 1 (unused in a New User message) 2 (unused in a New User message) 3 The message is a New User request. 4 The message is a New User response. The originating switch writes a value of 3 to this field, while the responding switch writes a value of 4. Status This 2-octet field contains the status of a New User response message. Valid values are as follows: 0 The end station VLAN(s) was successfully resolved (NewUserAck). 1 (unused) 2 The end station VLAN(s) was not resolved (NewUserUnknown). This field is written by the responding switch. Call tag This 2-octet field contains the call tag of the end station packet for which this New User request is issued. The call tag is a 16-bit value (generated by the originating switch) that uniquely identifies the packet that caused the switch to identify the end station as a new user. K. Dobbins, et. al. [Page 15] DRAFT ARLD Protocol Specification April 1997 Source MAC of packet This 6-octet field contains the physical (MAC) address of the end station that originated the packet identified by the call tag. Originating switch MAC This 6-octet field contains the physical (MAC) address of the switch that issued the original New User request. Previous owner switch MAC This 6-octet field contains the physical (MAC) address of the switch to which the end station was previously attached -- that is, the switch that was able to resolve the VLAN information. This field is written by the previous owner switch. If the status of the response is Unknown, this field is irrelevant. MAC address of new user This 24-octet field contains the physical (MAC) address of the new user end-station, stored in Tag/Length/Value format. Count This 1-octet field contains the number of VLAN identifiers returned. This is the number of items in the resolve list. This field is written by the previous owner switch. If the status of the response is Unknown, this field and the resolve list are irrelevant. Resolve list This variable-length field contains a list of the VLAN identifiers of all static VLANs to which the end station belongs, stored in Tag/Length/Value format. The number of entries in the list is specified in the count field. This list is written by the previous owner switch. If the status of the response is Unknown, this field is irrelevant. K. Dobbins, et. al. [Page 16] DRAFT ARLD Protocol Specification April 1997 References [RFC1700] Reynolds, S.J., Postel, J. Assigned Numbers. October 1994. Dobbins, K., et. al. ARLD Protocol Specification Work in Progress. Dobbins, K., et. al. ISM Protocol Specification Work in Progress. Dobbins, K., et. al. LSMP Protocol Specification Work in Progress. Dobbins, K., et. al. SBCD Protocol Specification Work in Progress. Dobbins, K., et. al. SNDM Protocol Specification Work in Progress. Dobbins, K., et. al. VLS Protocol Specification Work in Progress. Security Considerations Security issues are not discussed in this document. Authors' Addresses Cabletron Systems, Inc., is located at: Post Office Box 5005 Rochester, NH 03866-5005 (603) 332-9400 Kurt Dobbins Email: dobbins@ctron.com Tom Grant Email: tgrant@ctron.com Dave Ruffen Email: ruffen@ctron.com Eric Ziegler Email: ziegler@ctron.com INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT