DP83266 datasheet(14/152 Pages) NSC

14 / 152 page

40 FDDI MAC Facilities (Continued)

On the receive side the incoming SA is compared with ei-

ther MSA or MLA If a match occurs between the incoming

SA and this station’s MLA or MSA the MFlag is set This

flag is used to indicate that the frame is recognized as hav-

ing been transmitted by this station and is stripped The

most significant bit of the SA (SAlG) is not evaluated in the

comparison

On the transmit side the station’s individual address is

transmitted as the SA Since the SA field is normally used

for stripping frames from the ring the SA stored by the Ring

Engine normally replaces the SA from the data stream The

length of the address to be transmitted is determined by the

L bit of the FC field (The FC field is passed in the data

stream) The most significant bit of the SA (SAIG) is nor-

mally transmitted as 0 independent of the value passed

through the data stream

As a transmission option the SA may also be transmitted

transparently from the data stream When the SA Transpar-

ency option is used an alternate stripping mechanism is

necessary to remove these frames from the ring (The Ring

Engine provides a Void Stripping Option see Request

Channel 0 and 1 Configuration Registers 0 (R0CR0 and

R1CR0) for further information)

As a separate and independent transmission option the

MSB of the SA may also be transmitted transparently from

the data stream This is useful for end stations participating

in the Source Routing protocol that would like to continue to

perform reliable stripping based on the SA (When this op-

tion is used without SAT the transmitted SA is generated by

the Ring Engine as always)

Information (INFO)

The Information field contains the data transferred between

peer users of the MAC data service (SMT LLC etc) There

is no INFO field in a Token

The INFO field contains zero or more bytes

On the receive side the INFO field is checked to ensure

that it has at least the minimum length for the frame type

and contains an even number of symbols as required by the

ANSl X3T95 MAC standard

The first 4 bytes of the INFO field of MAC frames are stored

in an internal register and compared against the INFO field

of the next MAC frame If the data of the two frames match

and both frames were MAC frames the SameInfo signal is

generated This signal may be used to copy MAC frames

only when new information is present

On the transmit side the Ring Engine does not limit the

maximum size of the INFO field but it does insure that

frames are transmitted with a valid DA and SA

Frame Check Sequence (FCS)

The Frame Check Sequence is a 32-bit Cyclic Redundancy

Check that is used to check for data corruption in frames

There is no FCS field in a Token

On the receive side the Ring Engine checks the FCS to

determine whether the frame is valid or corrupted

On the transmit side the FCS field is appended to the end

of the INFO field As a transmission option appending the

FCS to the frame can be inhibited (FCS Transparency)

End of Frame Sequence (EFS)

The End of Frame Sequence (EFS) always begins with a T

symbol and should always contain an even number of sym-

bols For Tokens an additional T symbol is added For

frames the Ending Delimiter (ED) is followed by one or

more of Frame Status Indicators (FS)

The Frame Status (FS) field is used to indicate the status of

the frame The FS field consists of three Indicators Error

Detected (E) Address Recognized (A) and Frame Copied

in the ANSl X3T95 MAC standard

For frames transmitted by the Ring Engine the E A and C

Indicators are appended to all frames and are transmitted

as R symbols No provisions are made to generate addition-

al trailing control indicators

For frames repeated by the Ring Engine the E A and C

Indicators are handled as specified in the Standard Addi-

tional trailing control indicators are repeated unmodified

provided they are properly aligned See Section 55 for de-

tails on Frame Status Processing

422 Token Formats

The Ring Engine supports non-restricted and restricted To-

kens See

Figure 4-4 and Figure 4-5

SFS

EFS

FIGURE 4-4 Non-Restricted Token Format

SFS

FIGURE 4-5 Restricted Token Format

Non-restricted

A non-restricted token is used for synchronous and non-re-

stricted asynchronous transmissions Each time the non-re-

stricted token arrives a station is permitted to transmit one

or more frames in accordance with its synchronous band-

width allocation regardless of the status of the token (late or

early)

Asynchronous transmissions occur only if the token is early

(usable token) and the Token Holding Timer has not

reached the selected threshold

Restricted

A restricted token is used for synchronous and restricted

asynchronous transmissions only

A station which initiates the restricted dialogue captures a

non-restricted token and releases a restricted token Sta-

tions that participate in the restricted dialogue are allowed

to capture the restricted token A station ends the restricted

dialogue by capturing the restricted token and releasing a

non-restricted token

423 Frame Formats

The Ring Engine supports all of the frame formats permitted

by the FDDl standard All frame types may be created ex-

temal to the Ring Engine and be passed through the MAC

Request Interface to the Ring The Ring Engine also has the

ability to generate Void Beacon and Claim frames internal-

DP83266 Datasheet(PDF) 14 Page - National Semiconductor (TI)

DP83266 Datasheet(HTML) 14 Page - National Semiconductor (TI)

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

Datasheet Download

Link URL