[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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
        <draft-rfced-info-dobbins-00.txt>


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