DP83261AVF datasheet(10/132 Pages) NSC

10 / 132 page

40 FDDI MAC Facilities (Continued)

The Source Address has the same length as the Destination

Address (ie if the DA is a 16-bit Address the SA is a 16-bit

Address if the DA is a 48-bit Address the SA is a 48-bit

Address)

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 M

Flag 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 (SAIG) 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 Section

7424 for futher 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

Information

The Information field (Info) contains the Service Data Unit

(SDU) A SDU is the unit of data transfer between peer us-

ers 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

Standard

The first 4 bytes of the INFO field of MAC frames (eg MAC

Beacon or MAC Claim) 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 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

The Frame Check Sequence (FCS) is a 32-bit Cyclic Redun-

dancy 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

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

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 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

Figures 4-4 and 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-restricted token arrives a station is per-

mitted to transmit one or more frames in accordance with its

synchronous bandwidth 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 FDDI standard All frame types may be created exter-

nal to the BMAC device and be passed through the MAC

Request Interface to the Ring The BMAC device also has

the ability to generate Void Beacon and Claim frames inter-

nally

DP83261AVF Datasheet(PDF) 10 Page - National Semiconductor (TI)

DP83261AVF Datasheet(HTML) 10 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