IEEE 802.5 Details

The current standard for token ring's, IEEE 802.5-1985, specifies the operation of single ring networks. However, most implementations of 802.5 have added extensions for multi-ring networks using source-routing of packets at the MAC layer. There is now a Draft Addendum to IEEE 802.5, "Enhancement for Multi-Ring Networks" which attempts to standardize these extensions. Unfortunately, the most recent draft (November 10, 1987) is still rapidly evolving. More importantly, it differs significantly from the existing implementations. Therefore, the existing implementations of 802.5 [13] are described but no attempt is made to specify any future standard.

The MAC header contains 1 octet of access control, 1 octet of frame control, 6 (2) octets of source address, 6 (2) octets of destination address, and (for multi-ring networks) 0 to 18 octets of Routing Information Field (RIF). The MAC trailer contains 4 octets of FCS, for a total of 18 (10) to 36 (28) octets. There is one additional octet of frame status after the FCS.

Multi-Ring Extension Details

The presence of a Routing Information Field is indicated by the Most Significant Bit (MSB) of the source address, called the Routing Information Indicator (RII). If the RII equals zero, a RIF is not present. If the RII equals 1, the RIF is present. Although the RII is indicated in the source address, it is not part of a stations MAC layer address. In particular, the MSB of a destination address is the individual/group address indicator, and if set will cause such frames to be interpreted as multicasts. Implementations should be careful to reset the RII to zero before passing source addresses to other protocol layers which may be confused by their presence.

The RIF consists of a two-octet Routing Control (RC) field followed by 0 to 8 two-octet Route-Designator (RD) fields. The RC for all-routes broadcast frames is formatted as follows:

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  B  |   LTH   |D|  LF |   r   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Note that each tick mark represents one bit position.

B - Broadcast Indicators: 3 bits

The Broadcast Indicators are used to indicate the routing desired for a particular frame. A frame may be routed through a single specified route, through every distinct non-repeating route in a multi-ring network, or through a single route determined by a spanning tree algorithm such that the frame appears on every ring exactly once. The values which may be used at this time are (in binary):

      000 - Non-broadcast (specific route)
      100 - All-routes broadcast (global broadcast)
      110 - Single-route broadcast (limited broadcast)

All other values are reserved for future use.

LTH - Length: 5 bits

The Length bits are used to indicate the length or the RI field, including the RC and RD fields. Only even values between 2 and 30 inclusive are allowed.

D - Direction Bit: 1 bit

The D bit specifies the order of the RD fields. If D equals 1, the routing-designator fields are specified in reverse order.

LF - Largest Frame: 3 bits

The LF bits specify the maximum MTU supported by all bridges along a specific route. All multi-ring broadcast frames should be transmitted with a value at least as large as the supported MTU. The values used are:

       LF (binary)   MAC MTU      IP MTU

           000          552         508
           001         1064        1020
           010         2088        2044
           011         4136        4092
           100         8232        8188

All other values are reserved for future use.

The receiver should compare the LF received with the MTU. If the LF is greater than or equal to the MTU then no action is taken; however, if the LF is less than the MTU the frame is rejected.

There are actually three possible actions if LF < MTU. First is the one required for this specification (reject the frame). Second is to reduce the MTU for all hosts to equal the LF. And, third is to keep a separate MTU per communicating host based on the received LFs.

r - reserved: 4 bits

These bits are reserved for future use and must be set to 0 by the transmitter and ignored by the receiver.

It is not necessary for an implementation to interpret routing-designators. Their format is left unspecified. Routing-designators should be transmitted exactly as received.

IEEE 802.5 networks have no minimum packet size.

IEEE 802.5 networks have a maximum packet size based on the maximum time a node may hold the token. This time depends on many factors including the data signalling rate and the number of nodes on the ring. The determination of maximum packet size becomes even more complex when multi-ring networks with bridges are considered.

Given a token-holding time of 9 milliseconds and a 4 megabit/second ring, the maximum packet size possible is 4508 octets including all octets between the access control and the FCS inclusive.

This allows 4508 - 36 (MAC header+trailer with 18 octet RIF) - 8 (LLC+SNAP header) = 4464 for the IP datagram (including the IP header).

However, some current implementations are known to limit packets to 2046 octets (allowing 2002 octets for IP). It is recommended that all implementations support IP packets of at least 2002 octets.

By convention, source routing bridges used in multi-ring 802.5 networks will not support packets larger than 8232 octets. With a MAC header+trailer of 36 octets and the LLC+SNAP header of 8 octets, the IP datagram (including IP header) may not exceed 8188 octets.

A source routing bridge linking two rings may be configured to limit the size of packets forwarded to 552 octets, with a MAC header+trailer of 36 octets and the LLC+SNAP of 8 octets, the IP datagram (including the IP header) may be limited to 508 octets. This is less that the default IP MTU of 576 octets, and may cause significant performance problems due to excessive datagram fragmentation. An implementation is not required to support an MTU of less than 576 octets, although it is suggest that the MTU be a user-configurable parameter to allow for it.

IEEE 802.5 networks support three different types of broadcasts. All-Stations broadcasts are sent with no RIF or with the Broadcast Indicators set to 0 and no Routing Designators, and are copied once by all stations on the local ring. All-Routes broadcasts are sent with the corresponding Broadcast Indicators and result in multiple copies equal to the number of distinct non-repeating routes a packet may follow to a particular ring. Single-Route broadcasts result in exactly one copy of a frame being received by all stations on the multi-ring network.

The dynamic address discovery procedure is to broadcast an ARP request. To limit the number of all rings broadcasts to a minimum, it is desirable (though not required) that an ARP request first be sent as an all-stations broadcast, without a Routing Information Field (RIF). If the all-stations (local ring) broadcast is not supported or if the all-stations broadcast is unsuccessful after some reasonable time has elapsed, then send the ARP request as an all-routes or single-route broadcast with an empty RIF (no routing designators). An all-routes broadcast is preferable since it yields an amount of fault tolerance. In an environment with multiple redundant bridges, all-routes broadcast allows operation in spite of spanning-tree bridge failures. However, single-route broadcasts may be used if IP and ARP must use the same broadcast method.

When an ARP request or reply is received, all implementations are required to understand frames with no RIF (local ring) and frames with an empty RIF (also from the local ring). If the implementation supports multi-ring source routing, then a non- empty RIF is stored for future transmissions to the host originating the ARP request or reply. If source routing is not supported them all packets with non-empty RIFs should be gracefully ignored. This policy will allow all implementations in a single ring environment, to interoperate, whether or not they support the multi-ring extensions.

It is possible that when sending an ARP request via an all-routes broadcast that multiple copies of the request will arrive at the destination as a result of the request being forwarded by several bridges. However, these "copies" will have taken different routes so the contents of the RIF will differ. An implementation of ARP in this context must determine which of these "copies" to use and to ignore the others. There are three obvious and legal strategies: (1) take the first and ignore the rest (that is, once you have an entry in the ARP cache don't change it), (2) take the last, (that is, always up date the ARP cache with the latest ARP message), or (3) take the one with the shortest path, (that is, replace the ARP cache information with the latest ARP message data if it is a shorter route). Since there is no problem of incompatibility for interworking of different implementations if different strategies are chosen, the choice is up to each implementor. The recipient of the ARP request must send an ARP reply as a point to point message using the RIF information.

The RIF information should be kept distinct from the ARP table. That is, there is, in principle, the ARP table to map from IP addresses to 802 48-bit addresses, and the RIF table to map from those to 802.5 source routes, if necessary. In practical implementations it may be convenient to store the ARP and RIF information together.

Storing the information together may speed up access to the information when it is used. On the other hand, in a generalized implementation for all types of 802 networks a significant amount of memory might be wasted in an ARP cache if space for the RIF information were always reserved.

IP broadcasts (datagrams with a IP broadcast address) must be sent as 802.5 single-route broadcasts. Unlike ARP, all-routes broadcasts are not desirable for IP. Receiving multiple copies of IP broadcasts would have undesirable effects on many protocols using IP. As with ARP, when an IP packet is received, all implementations are required to understand frames with no RIF and frames with an empty RIF.

Since current interface hardware allows only one group address, and since the functional addresses are not globally unique, IP and ARP do not use either of these features. Further, in the IBM style 802.5 networks there are only 31 functional addresses available for user definition.

IP precedence should not be mapped to 802.5 priority. All IP and ARP packets should be sent at the default 802.5 priority. The default priority is 3.

After packet transmission, 802.5 provides frame not copied and address not recognized indicators. Implementations may use these indicators to provide some amount of error detection and correction. If the frame not copied bit is set but the address not recognized bit is reset, receiver congestion has occurred. It is suggested, though not required, that hosts should retransmit the offending packet a small number of times (4) or until congestion no longer occurs. If the address not recognized bit is set, an implementation has 3 options: (1) ignore the error and throw the packet away, (2) return an ICMP destination unreachable message to the source, or (3) delete the ARP entry which was used to send this packet and send a new ARP request to the destination address. The latter option is the preferred approach since it will allow graceful recovery from first hop bridge and router failures and changed hardware addresses.