|
| 發表者 |
討論內容 |
冷日
(冷日) |
發表時間：2007/5/31 2:12 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [分享]修正上一篇，Bridge 和 Switch 是否為同樣的東西
- > 這一段你可以把IEEE 802.3裏面關於jam的敘述再看一看，你的說法與實際情況有
> 出入。
多謝提點﹗
學習的過程中﹐真是來不得半點懶惰﹐想偷懶蒙混﹐實在不容易過關。為免誤導大
家﹐將文件查詢結果茲列如下﹕
4.1.2.2 Access interference and recovery
In half duplex mode,if multiple stations attempt to transmit at the same
time,it is possible for them to interfere with each other ’s
transmissions,in spite of their attempts to a oid this by deferring.When
transmissions
from two stations o erlap,the resulting contention is called a
collision.Collisions occur only in half duplex
mode,where a collision indicates that there is more than one station
attempting to use the shared physical
medium.In full duplex mode,two stations may transmit to each other
simultaneously without causing interference.The Physical Layer may generate
a collision indication,but this is ignored by the full duplex MAC.
A gi en station can experience a collision during the initial part of its
transmission (the collision window)
before its transmitted signal has had time to propagate to all stations on
the CSMA/CD medium.Once the
collision window has passed,a transmitting station is said to ha e acquired
the medium;subsequent collisions are a oided since all other (properly
functioning)stations can be assumed to ha e noticed the signal
and to be deferring to it.The time to acquire the medium is thus based on
the round-trip propagation time of
the Physical Layer whose elements include the PLS,PMA,and physical medium.
In the e ent of a collision,the transmitting station ’s Physical Layer
initially notices the interference on the
medium and then turns on the collision detect signal.In half duplex
mode,this is noticed in turn by the
Transmit Media Access Management component of the MAC sublayer,and
collision handling begins.First,
Transmit Media Access Management enforces the collision by transmitting a
bit sequence called jam.In 4.4,
implementations that use this enforcement procedure are provided.This
ensures that the duration of the collision is suf ?cient to be noticed by
the other transmitting station(s)in olved in the collision.After the jam is
sent,Transmit Media Access Management terminates the transmission and
schedules another transmission
attempt after a randomly selected time interval.Retransmission is attempted
again in the face of repeated
collisions.Since repeated collisions indicate a busy medium,howe
er,Transmit Media Access Management
attempts to adjust to the medium load by backing off (voluntarily delaying
its own retransmissions to reduce
its load on the medium).This is accomplished by expanding the interval from
which the random retransmission time is selected on each successi e
transmit attempt.Eventually,either the transmission succeeds,or the
attempt is abandoned on the assumption that the medium has failed or has
become o erloaded.
In full duplex mode,a station ignores any collision detect signal generated
by the Physical Layer.Transmit
Media Access Management in a full duplex station will always be able to
transmit its frames without contention,so there is ne er any need to jam or
reschedule transmissions.
At the receiving end,the bits resulting from a collision are recei ed and
decoded by the PLS just as are the
bits of a alid frame.Fragmentary frames recei ed during collisions are
distinguished from alid transmissions by the MAC sublayer ’s Recei e Media
Access Management component.
4.2.3.2.3 Collision handling (half duplex mode only)
Once a CSMA/CD sublayer has ?nished deferring and has started
transmission,it is still possible for it to
experience contention for the medium.Collisions can occur until acquisition
of the network has been accomplished through the deference of all other
stations ’ CSMA/CD sublayers.
The dynamics of collision handling are largely determined by a single
parameter called the slot time.This
single parameter describes three important aspects of collision handling:
a)It is an upper bound on the acquisition time of the medium.
b)It is an upper bound on the length of a frame fragment generated by a
collision.
c)It is the scheduling quantum for retransmission.
To ful ?ll all three functions,the slot time shall be larger than the sum
of the Physical Layer roundtrip propagation time and the Media Access Layer
maximum jam time.The slot time is determined by the parameters
of the implementation,see 4.4.
4.2.3.2.4 Collision detection and enforcement (half duplex mode only)
Collisions are detected by monitoring the collisionDetect signal provided
by the Physical Layer.When a collision is detected during a frame
transmission,the transmission is not terminated immediately.Instead,the
transmission continues until additional bits speci ?ed by jamSize ha e been
transmitted (counting from the
time collisionDetect went on).This collision enforcement or jam guarantees
that the duration of the collision
is suf ?cient to ensure its detection by all transmitting stations on the
network.The content of the jam is
unspeci ?ed;it may be any ?xed or ariable pattern con enient to the Media
Access implementation,however,the implementation shall not be intentionally
designed to be the 32-bit CRC alue corresponding to the
(partial)frame transmitted prior to the jam.
4.2.3.2.5 Collision backoff and retransmission (half duplex mode only)
When a transmission attempt has terminated due to a collision,it is retried
by the transmitting CSMA/CD
sublayer until either it is successful or a maximum number of attempts
(attemptLimit)ha e been made and
all ha e terminated due to collisions.Note that all attempts to transmit a
gi en frame are completed before
any subsequent outgoing frames are transmitted.The scheduling of the
retransmissions is determined by a
controlled randomization process called “truncated binary exponential
backoff.”At the end of enforcing a
collision (jamming),the CSMA/CD sublayer delays before attempting to
retransmit the frame.The delay is
an integer multiple of slotTime.The number of slot times to delay before
the nth retransmission attempt is
chosen as a uniformly distributed random integer r in the range:
0 r <2 k
where
k =min (n,10)
If all attemptLimit attempts fail,this e ent is reported as an
error.Algorithms used to generate the integer r
should be designed to minimize the correlation between the numbers
generated by any two stations at any
given time.
Note that the alues gi en abo e de ?ne the most aggressi e behavior that a
station may exhibit in attempting
to retransmit after a collision.In the course of implementing the
retransmission scheduling procedure,a station may introduce extra delays
that will degrade its own throughput,but in no case may a station ’s
retransmission scheduling result in a lower a erage delay between
retransmission attempts than the procedure
defined above.
4.2.4.2.2 Collision Filtering
In the absence of a collision,the shortest alid transmission in half duplex
mode must be at least one slot-Time in length.Within a burst of frames,the
?rst frame of a burst must be at least slotTime bits in length in
order to be accepted by the recei er,while subsequent frames within a burst
must be at least minFrameSize
in length.Anything less is presumed to be a fragment resulting from a
collision,and is discarded by the
recei er.In half duplex mode,occasional collisions are a normal part of the
Media Access management procedure.The discarding of such a fragment by a
MAC is not reported as an error.
The shortest alid transmission in full duplex mode must be at least
minFrameSize in length.While collisions do not occur in full duplex mode
MACs,a full duplex MAC ne ertheless discards recei ed frames containing
less than minFrameSize bits.The discarding of such a frame by a MAC is not
reported as an error.
> 誰說的?
> 請把IEEE 802.3標準中對switch和bridge的定義拿來看看吧。
> 另外，IEEE 802.1D的標題正是 MAC bridge。
>
剛纔查了一下 IEEE 的文件﹐的確發現他們將 switch 和 bridge 定義在一起了。那
就不能怪當初在校時的筆記﹐而應該怪自己沒仔細看文件囉~~~
不過﹐讀 IEEE 或 RFC 之類的文件﹐的確是非常乏味的﹐如果不想從頭看起﹐下面是
我‘斷章取義’下來的引文﹐希望對那些有興趣看看的朋友有些幫助吧。
********************************************
IEEE Std 802.3, 2000 Edition
Part 3:Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications
1.4 Definitions
1.4.53 bridge:A layer 2 interconnection device that does not form part of a
CSMA/CD collision domain but
conforms to the ISO/IEC 15802-3:1998 [ANSI/IEEE 802.1D,1998
Edition ]International Standard.A
bridge does not form part of a CSMA/CD collision domain but,rather appears
as a Media Access Control
(MAC)to the collision domain.(See also IEEE Std 100-1996.)
1.4.264 switch:A layer 2 interconnection device that conforms to the
ISO/IEC 10038 [ANSI/IEEE 802.1D-
1990 ] International Standard..Syn:bridge.
4.1.1 Overview
The most common configuration envisioned for full duplex operation consists
of a central bridge (also
known as a switch)with a dedicated LAN connecting each bridge port to a
single device.
12.4.3.2.7 Collision presence startup
When a hub starts generating CP (as speci ?ed in 12.4.3.2.2 through
12.4.3.2.5)it shall synchronize the startup to a half or whole bit-cell
boundary of any immediately preceding signal.If it was sending IDL
immediately before the CP,no synchronization or preamble is required.
A hub may start transmission of CP at any point in the sequence that does
not result in periods of more than
one bit time without a transition during the switch from passing on data to
sending CP.Depending on the
preceding signal,it may start with L010H,010HL,10HL0,0HL01,or HL010.Because
startup may be synchronized to any half-bit-cell boundary,a hub may also
transmit the shifted ersion of CP starting with
1LH10,LH101,H101L,101LH,or 01LH1.
********************************************
ANSI/IEEE Std 802.1D, 1998 Edition
Part 3: Media Access Control (MAC) Bridges
6. Support of the MAC Service
MAC Bridges interconnect the separate IEEE 802 LANs that comprise a Bridged
LAN by relaying and filtering
frames between the separate MACs of the Bridged LAN.The position of the
bridging function within
the MAC Sublayer is shown in Figure 6-1.
Figure 6-1—Internal organization of the MAC Sublayer
This clause discusses the following aspects of service provision in Bridged
LANs:
a) Provision of the MAC Service to end stations;
b) Preservation of the MAC Service;
c) Maintenance of Quality of Service;
d) Provision of the internal sublayer service within the MAC Bridge;
e) Support of the Internal Sublayer Service by specific MAC procedures;
f) Filtering services.
6.5.1 Support by IEEE Std 802.3 (CSMA/CD)
The CSMA/CD access method is specified in IEEE Std 802.3. Clause 3 of that
standard specifies the MAC
frame structure, and Clause 4 specifies the MAC method.
On receipt of an M_UNITDATA.request primitive, the local MAC Entity
performs Transmit Data Encapsulation,
assembling a frame using the parameters supplied as specified below. It
prepends a preamble and a
Start Frame Delimiter before handing the frame to the Transmit Media Access
Management Component in
the MAC Sublayer for transmission (IEEE Std 802.3, 4.2.3).
On receipt of a MAC frame by Receive Media Access Management, the MAC frame
is passed to Receive
Data Decapsulation, which validates the FCS and disassembles the frame, as
specified below, into the
parameters that are supplied with an M_UNITDATA.indication primitive (IEEE
Std 802.3, 4.2.4).
The frame_type parameter takes only the value user_data_frame and is not
explicitly encoded in MAC
frames.
The mac_action parameter takes only the value request_with_no_response and
is not explicitly encoded in
MAC frames.
The destination_address parameter is encoded in the destination address
field of the MAC frame (IEEE Std
802.3, 3.2.3).
The source_address parameter is encoded in the source address field of the
MAC frame (IEEE Std
802.3, 3.2.3).
The number of octets in the mac_service_data_unit parameter is encoded in
the length field of the MAC
frame (IEEE Std 802.3, 3.2.6), and the octets of data are encoded in the
data field (IEEE Std 802.3, 3.2.7).
The user_priority parameter provided in a data request primitive is not
encoded in MAC frames. The
user_priority parameter provided in a data indication primitive takes the
value of the Default User Priority
parameter for the Port through which the MAC frame was received (see 6.4).
The frame_check_sequence parameter is encoded in the FCS field of the MAC
frame (IEEE Std 802.3,
3.2.8). The FCS is computed as a function of the destination address,
source address, length, data, and PAD
fields. If an M_UNITDATA.request primitive is not accompanied by this
parameter, it is calculated in accordance
with IEEE Std 802.3, 3.2.8.
NOTE 1—Since the PAD field, if present, contributes to the FCS, this
parameter needs to include at least the contribution
of the PAD field to the FCS in order for the original FCS to be preserved
(See Annex G).
No special action, above that specified for the support of use of the MAC
Service by LLC, is required for the
support of the MAC Internal Sublayer Service by the CSMA/CD access method.
NOTE 2—The support by IEEE Std 802.3 is described only in terms of the
operation of a Bridge when relaying frames
that result from the use of LLC services over an 802.3 MAC. ISO/IEC 11802-5
defines the recommended practice for
bridging Ethernet V2.0 frames.
NOTE 3—IEEE Std 802.3, 1998 Edition, describes the use of either a Length
or an Ethernet protocol type in its frame
format; however, the text of this subclause has yet to be revised to
describe the use of Ethernet protocol types.
6.6 Filtering services in Bridged LANs
MAC Bridges provide filtering services in Bridged LANs that support some
aspects of the maintenance of
Quality of Service; in particular, transit delay, priority, and throughput.
In addition, these services provide
for a degree of administrative control over the propagation of particular
MAC Addresses in the Bridged
LAN.
The services described are services in the most general sense; i.e., they
are descriptions of the functionality
that are made available to the MAC Service user or an administrator in
order to control and access filtering
capabilities in Bridged LANs. The description of each service makes no
assumptions in terms of how the
service might be realized. There are at least the following possibilities:
a) Use of existing protocols and mechanisms, defined in IEEE 802 standards
and elsewhere;
b) Use of management functionality, either locally defined or implemented
via remote management
protocols;
c) Other means, standardized or otherwise.
6.6.1 Purpose(s) of filtering service provision
Filtering services are provided in Bridged LANs for the purposes described
in the following subclauses.
6.6.7.1 Dynamic registration and de-registration services
These services allow MAC Service users dynamic control over the set of
destination Group MAC Addresses
that they will receive from the MAC Service provider, by
a) Registering/de-registering membership of specific Groups associated with
those addresses;
b) Registering/de-registering their service requirements with regard to the
overall forwarding/filtering
behavior for Groups.
Provision of these services is achieved by means of GMRP and its associated
procedures, as described in
Clause 10.
NOTE—The intent of these services is to provide the MAC Service user with
dynamic control over access to multicast
data streams, for example, multiple video channels made available by a
server using a different group MAC Address for
each channel. The ability to both register and de-register Group
membership, coupled with the filtering action associated
with the Group membership, limits the impact of such services on the
bandwidth available in the Bridged LAN. These
services can be used to control the reception of other categories of
multicast traffic, for similar reasons.
REGISTER_GROUP_MEMBER (MAC_ADDRESS)
Indicates to the MAC Service provider that the MAC Service user wishes to
receive frames containing the
group MAC Address indicated in the MAC_ADDRESS parameter as the destination
address. The MAC
Addresses that can be carried by this parameter do not include
a) Any individual address;
b) Any of the Reserved Addresses identified in Table 7-9;
c) Any of the GARP Application addresses, as defined in Table 12-1.
DEREGISTER_GROUP_MEMBER (MAC_ADDRESS)
Indicates to the MAC Service provider that the end station no longer wishes
to receive frames containing the
group MAC Address indicated in the MAC_ADDRESS parameter as the destination
address.
REGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)
Indicates to the MAC Service provider that the MAC Service user has a
requirement for any devices that
support Extended Filtering Services to forward frames in the direction of
the Mac Service User in accordance
with the definition of the service requirement defined by the
REQUIREMENT_SPECIFICATION
parameter. The values that can be carried by this parameter are
a) Forward All Groups;
b) Forward Unregistered Groups.
DEREGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)
Indicates to the MAC Service provider that the MAC Service user no longer
has a requirement for any
devices that support Extended Filtering Services to forward frames in the
direction of the Mac Service User
in accordance with the definition of the service requirement defined by the
REQUIREMENT_SPECIFICATION parameter. The values that can be carried by this
parameter are
a) Forward All Groups;
b) Forward Unregistered Groups.
The use of these services can result in the propagation of group MAC
Address and service requirement
information across the Spanning Tree, affecting the contents of Group
Registration Entries (7.9.3) in Bridges
and end stations in the Bridged LAN, and thereby affecting the frame
forwarding behavior of the Bridges
and end stations with regard to multicast frames.
7.1 Bridge operation
The principal elements of Bridge operation are
a) Relay and filtering of frames.
b) Maintenance of the information required to make frame filtering and
relaying decisions.
c) Management of the above.
7.1.1 Relay
A MAC Bridge relays individual MAC user data frames between the separate
MACs of the Bridged LANs
connected to its Ports. The order of frames shall be preserved as defined
in 7.7.3.
The functions that support the relaying of frames and maintain the Quality
of Service supported by the
Bridge are
a) Frame reception.
b) Discard on received frame in error (6.3.2).
c) Frame discard if the frame_type is not user_data_frame, or if its
mac_action parameter is not
request_with_no_response (6.4).
d) Regeneration of user priority, if required (6.4).
e) Frame discard following the application of filtering information.
f) Frame discard on transmittable service data unit size exceeded (6.3.8).
g) Forwarding of received frames to other Bridge Ports.
h) Selection of traffic class, following the application of filtering
information.
i) Queuing of frames by traffic class.
j) Frame discard to ensure that a maximum bridge transit delay is not
exceeded (6.3.6).
k) Selection of queued frames for transmission.
l) Selection of outbound access priority (6.3.9).
m) Mapping of service data units and recalculation of Frame Check Sequence,
if required (6.3.7, 7.7.6).
n) Frame transmission.
7.1.2 Filtering and relaying information
A Bridge filters frames, i.e., does not relay frames received by a Bridge
Port to other Ports on that Bridge, in
order to prevent the duplication of frames (6.3.4). The function that
supports the use and maintenance of
information for this purpose is
a) Calculation and configuration of Bridged LAN topology.
A Bridge also filters frames in order to reduce traffic in parts of the
Bridged LAN that do not lie in the path
between the source and destination of that traffic. The functions that
support the use and maintenance of
information for this purpose are:
b) Permanent configuration of reserved addresses.
c) Explicit configuration of static filtering information.
d) Automatic learning of dynamic filtering information for unicast
destination addresses through observation
of source addresses of Bridged LAN traffic.
e) Ageing out of dynamic filtering information that has been learned.
f) Automatic addition and removal of dynamic filtering information as a
result of GMRP protocol
exchanges.
A Bridge classifies frames into traffic classes in order to expedite
transmission of frames generated by critical
or time-sensitive services. The function that supports the use and
maintenance of information for this
purpose is
g) Explicit configuration of traffic class information associated with the
Ports of the Bridge.
7.1.3 Bridge Management
The functions that support Bridge Management control and monitor the
provision of the above functions.
They are specified in Clause 14.
7.2 Bridge architecture
7.2.1 Architectural model of a Bridge
Figure 7-1 gives an example of the physical topology of a Bridged LAN. The
component LANs are interconnected
by means of MAC Bridges; each Port of a MAC Bridge connects to a single
LAN. Figure 7-2 illustrates
a Bridge with two Ports, and Figure 7-3 illustrates the architecture of
such a Bridge.
A Bridge is modeled as consisting of
a) A MAC Relay Entity that interconnects the Bridge’s Ports;
b) At least two Ports;
c) Higher layer entities, including at least a Bridge Protocol Entity.
7.2.2 MAC Relay Entity
The MAC Relay Entity handles the MAC method independent functions of
relaying frames between Bridge
Ports, filtering frames, and learning filtering information. It uses the
Internal Sublayer Service provided by
the separate MAC Entities for each Port. (The Internal Sublayer Service and
its support are described in 6.4
and 6.5.) Frames are relayed between Ports attached to different LANs.
7.2.3 Ports
Each Bridge Port transmits and receives frames to and from the LAN to which
it is attached. An individual
MAC Entity permanently associated with the Port provides the Internal
Sublayer Service used for frame
transmission and reception. The MAC Entity handles all the MAC method
dependent functions (MAC protocol
and procedures) as specified in the relevant standard for that IEEE 802 LAN
MAC technology.
7.5 Frame reception
The individual MAC Entity associated with each Bridge Port examines all
frames transmitted on the LAN to
which it is attached.
All error-free received frames give rise to M_UNITDATA indication
primitives, which shall be handled as
follows.
NOTE—A frame that is in error, as defined by the relevant MAC
specification, is discarded by the MAC Entity without
giving rise to any M_UNITDATA indication; see 6.4.
Frames with M_UNITDATA.indication primitive frame_type and mac_action
parameter values of
user_data_frame and request_with_no_response, respectively (6.4), shall be
submitted to the Learning and
Forwarding Processes.
Frames with other values of frame_type and mac_action parameters (e.g.,
request_with_response and response
frames), shall not be submitted to the Forwarding Process. They may be
submitted to the Learning Process.
Frames with a frame_type of user_data_frame and addressed to the Bridge
Port as an end station shall be
submitted to LLC. Such frames carry either the individual MAC Address of
the Port or a group address associated
with the Port (7.12) in the destination address field. Frames submitted to
LLC can also be submitted to
the Learning and Forwarding Processes, as specified above.
Frames addressed to a Bridge Port as an end station, and relayed to that
Bridge Port from other Bridge Ports
in the same Bridge by the Forwarding Process, shall also be submitted to
LLC.
No other frames shall be submitted to LLC.
7.6 Frame transmission
The individual MAC Entity associated with each Bridge Port transmits frames
submitted to it by the MAC
Relay Entity.
Relayed frames are submitted for transmission by the Forwarding Process.
The M_UNITDATA.request
primitive associated with such frames conveys the values of the source and
destination address fields
received in the corresponding M_UNITDATA.indication primitive.
LLC Protocol Data Units are submitted by LLC as a user of the MAC Service
provided by the Bridge Port.
Frames transmitted to convey such Protocol Data Units carry the individual
MAC Address of the Port in the
source address field.
Each frame is transmitted subject to the MAC procedures to be observed for
that specific IEEE 802 LAN
technology. The values of the frame_type and mac_action parameters of the
corresponding M_UNITDATA.
request primitive shall be user_data_frame and request_with_no_response,
respectively (6.5).
Frames transmitted following a request by the LLC user of the MAC Service
provided by the Bridge Port
shall also be submitted to the MAC Relay Entity.
7.7 The Forwarding Process
Frames submitted to the Forwarding Process after being received at any
given Bridge Port (7.5) shall be forwarded
through the other Bridge Ports subject to the constituent functions of the
Forwarding Process. These
functions enforce topology restrictions (7.7.1), use filtering database
information to filter frames (7.7.2),
queue frames (7.7.3), select queued frames for transmission (7.7.4), map
priorities (7.7.5), and recalculate
FCS if required (7.7.6).
The Forwarding Process functions are described in 7.7.1–7.7.6 in terms of
the action taken for a given frame
received on a given Port (termed “the reception Port”). The frame can be
forwarded for transmission on
some Ports (termed “transmission Ports”), and is discarded without being
transmitted at the other Ports.
NOTE—The model of operation of the Forwarding Process described in this
standard is limited to the operation of the
relay function of the MAC Bridge, and does not take into consideration what
may occur in real implementations once
frames are passed to the MAC for transmission. In some MAC implementations,
and under some traffic conditions, a
degree of indeterminacy may be introduced between the modeled description
of the process of passing selected frames to
the MAC for transmission and the actual sequence of frames as visible on
the LAN medium itself. Examples can be
found in the handling of access_priority in Token-Passing Bus MACs, or in
the effect of different values for Token Holding
Time in FDDI LANs. Such indeterminacy could result in apparent violation of
the queuing/de-queueing and prioritiation
rules described for the Forwarding Process, when observing traffic on the
medium. As a consequence, in some
implementations of this standard, it may prove to be impossible to test
conformance to the standard simply by relating
observed LAN traffic to the described model of the Forwarding Process;
conformance tests would have to allow for the
(permissible) behavior of the MAC implementations as well.
Figure 7-4 illustrates the operation of the Forwarding Process in a single
instance of frame relay between the
Ports of a Bridge with two Ports. Figure 7-8 illustrates the detailed
operation of the Forwarding Process.
7.8 The Learning Process
The Learning Process observes the source addresses of frames received on
each Port and updates the Filtering
Database conditionally on the state of the receiving Port.
Frames are submitted to the Learning Process by the individual MAC Entities
associated with each Bridge
Port as specified in 7.5.
The Learning Process may deduce the path through the Bridged LAN to
particular end stations by inspection
of the source address field of received frames. It shall create or update a
Dynamic Filtering Entry (7.9, 7.9.2)
in the Filtering Database, associating the Port on which the frame was
received with the MAC Address in the
source address field of the frame, if and only if
a) The Port on which the frame was received is in a state that allows
learning (8.4), and
b) The source address field of the frame denotes a specific end station,
i.e., is not a group address, and
c) No Static Filtering Entry (7.9, 7.9.1) for the associated MAC Address
exists in which the Port Map
specifies Forwarding or Filtering for that Port, and
d) The resulting number of entries would not exceed the capacity of the
Filtering Database.
If the Filtering Database is already filled up to its capacity, but a new
entry would otherwise be made, then an
existing entry may be removed to make room for the new entry.
Figure 7-5 illustrates the operation of the Learning Process in the
inclusion of station location information
carried by a single frame, received on one of the Ports of a Bridge, in the
Filtering Database.
7.9 The Filtering Database
The Filtering Database supports queries by the Forwarding Process as to
whether frames received by the
Forwarding Process from a given reception Port, and with given values of
destination MAC Address parameter,
are to be forwarded through a given potential transmission Port (7.7.1,
7.7.2). It contains filtering information
in the form of filtering entries that are either
a) Static, and explicitly configured by management action; or
b) Dynamic, and automatically entered into the Filtering Database by the
normal operation of the
bridge and the protocols it supports.
A single entry type, the Static Filtering Entry, represents all static
information in the Filtering Database, for
individual and for group MAC Addresses. It allows administrative control of
c) Forwarding of frames with particular destination addresses; and
d) The inclusion in the Filtering Database of dynamic filtering information
associated with Extended
Filtering Services, and use of this information.
The Filtering Database shall contain entries of the Static Filtering Entry
type.
Static filtering information is added to, modified, and removed from the
Filtering Database only under
explicit management control. It shall not be automatically removed by any
ageing mechanism. Management
of static filtering information may be carried out by use of the remote
management capability provided by
Bridge Management (7.11) using the operations specified in Clause 14.
Two entry types are used to represent dynamic filtering information.
Dynamic Filtering Entries are used to
specify the ports on which individual addresses have been learned. They are
created and updated by the
Learning Process (7.8), and are subject to ageing and removal by the
Filtering Database. Group Registration
Entries support the registration of group MAC Addresses. They are created,
updated, and removed by the
GMRP protocol in support of Extended Filtering Services (6.6.5, 7.9.3, and
Clause 10). Dynamic filtering
information may be read by use of the remote management capability provided
by Bridge Management
(7.11) using the operations specified in Clause 14.
Both static and dynamic entries comprise
e) A MAC Address specification;
f) A Port Map, with a control element for each outbound Port to specify
filtering for the MAC Address
specification.
The Filtering Services supported by a Bridge (Basic and Extended Filtering
Services) determine the default
behavior of the Bridge with respect to the forwarding of frames destined
for group MAC Addresses. In
Bridges that support Extended Filtering Services, the default forwarding
behavior of each Port for group
MAC Addresses can be configured both statically and dynamically by means of
Static Filtering Entries and/
or Group Registration Entries that can carry the following MAC Address
specifications:
g) All Group Addresses, for which no more specific Static Filtering Entry
exists;
h) All Unregistered Group Addresses (i.e., all group MAC Addresses for
which no Group Registration
Entry exists), for which no more specific Static Filtering Entry exists.
NOTE—The All Group Addresses specification (item g above), when used in a
Static Filtering Entry with an appropriate
control specification, provides the ability to configure a Bridge that
supports Extended Filtering Services to behave as a
Bridge that supports only Basic Filtering Services on some or all of its
Ports. This might be done for the following reasons:
— The Ports concerned serve “legacy” devices that wish to receive
multicast traffic, but are unable to register Group
membership;
— The Ports concerned serve devices that need to receive all multicast
traffic, such as routers or diagnostic devices.
The Filtering Database shall support the creation, updating, and removal of
Dynamic Filtering Entries by the
Learning Process (7.8). In Bridges that support Extended Filtering
Services, the Filtering Database shall
support the creation, updating, and removal of Group Registration Entries
by GMRP (Clause 10).
Figure 7-4 illustrates the use of the Filtering Database by the Forwarding
Process in a single instance of
frame relay between the Ports of a Bridge with two Ports.
Figure 7-5 illustrates the creation or update of a dynamic entry in the
Filtering Database by the Learning
Process.
Figure 7-6 illustrates the operation of the Bridge Protocol Entity (7.10),
which operates the Spanning Tree
Algorithm and Protocol, and its notification of the Filtering Database of
changes in active topology signaled
by that protocol.
7.12.1 End stations
Frames transmitted between end stations using the MAC Service provided by a
Bridged LAN carry the
MAC Address of the source and destination peer end stations in the source
and destination address fields of
the frames, respectively. The address, or other means of identification, of
a Bridge is not carried in frames
transmitted between peer users for the purpose of frame relay in the
Bridged LAN.
The broadcast address and other group MAC Addresses apply to the use of the
MAC Service provided by a
Bridged LAN as a whole. In the absence of explicit filters configured via
management as Static Filtering
Entries, or via GMRP as Group Registration Entries (Clause 14, Clause 10,
7.9), frames with such destination
addresses are relayed throughout the Bridged LAN.
7.12.2 Bridge Ports
The individual MAC Entity associated with each Bridge Port shall have a
separate individual MAC Address.
This address is used for any MAC procedures required by the particular MAC
method employed.
Frames that are received from the LAN to which a Port is attached and that
carry a MAC Address for the
Port in the destination address field are submitted to the MAC Service User
(LLC) exactly as for an end
station.
******************************************************
有許多人﹐如弟﹐不是很喜歡看文件﹐但就算看得懂文件﹐如何整理出來﹐向大家說
明白﹐看來比起看文件更難﹗
|
|
|
|
|
討論串
|
[分享]L2與L3 Switch的差別 (冷日