LAN E
LAN 4 LAN 3
12.3 GARP Architecture
Figure 12-4 illustrates the components of GARP Participants in a two-Port Bridge and an end station.
A GARP Participant in a Bridge or an end station consists of a GARP Application component, and a GARP Information Declaration (GID) component associated with each Port of the Bridge. One such GARP
Partic-Figure 12-2—Example Attribute value propagation from two stations LAN 1
LAN 4 LAN 3
a
a
Aa LAN 2
a
a
a
Aa a
a a
a Aa
a a Aa
Aa
Aa
Aa
= End station a = Registration of Attribute value A
Direction of propagation of the declaration of Attribute value A
= Bridge
A = Declaration of Attribute value A
A A A A
A A
Aa Aa
Aa
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 ipant exists per Port, per GARP Application. The propagation of information between GARP Participants
for the same Application in a Bridge is carried out by the GARP Information Propagation (GIP) component.
Protocol exchanges take place between GARP Participants by means of LLC Type 1 services, using the group MAC address and PDU format defined for the GARP Application concerned.
NOTE—This Clause defines a generic PDU structure for use in GARP protocol exchanges (12.11); however, each GARP Application defines a further specification of that generic structure in order to carry the application identification and attribute values that are required for the operation of that application.
12.3.1 The GARP Application component For each GARP Application, the following are defined:
a) A set of one or more Attribute types that are used by the Application;
b) The set of values that each Attribute type can carry;
c) The semantics associated with each Attribute type and value;
d) The group MAC address used to exchange GARP PDUs between GARP Participants for that Appli-cation;
e) The structure and encoding of the Attribute types and values in GARP PDUs;
f) The requirements placed on the support of the GARP state machines in end stations and Bridges that support the application.
The GARP Application component of the GARP Participant is responsible for defining the semantics associ-ated with parameter values and operators received in GARP PDUs, and for generating GARP PDUs for transmission. The Application component makes use of the GID component, and the state machines
associ-Figure 12-3—Example of the formation of subtrees of the active topology LAN 1
LAN 4 LAN 3
a
a
Aa
From a given Participant, indicates the direction in which one or more other Partici-pants can be found that have declared Attribute value A.
LAN 2
a
a
a
Aa a
a a
a Aa
a a Aa
Aa
Aa Aa
Aa
Aa Aa
= End station a = Registration of Attribute value A
= Bridge
A = Declaration of Attribute value A
A A
A A
A A
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
ated with GID’s operation, in order to control its protocol interactions. The service offered to the Application component by the GID component is defined by the set of primitives described in 12.3.2.
12.3.2 GID
An instance of GID consists of the set of state machines that define the current registration and declaration state of all attribute values associated with the GARP Participant of which the GID instance is a component.
Figure 12-5 illustrates the set of state machines associated with a GID instance.
The operation of GID is defined by:.
a) The Registrar State Transition Table (Table 12-4);
b) The Applicant State Transition Table (Table 12-3);
c) The state machines that represent the current declaration state (Applicant state machines) and regis-tration state (Registrar state machines) for each attribute value associated with the GARP Partici-pant;
d) The service primitives available to users of GID.
12.3.2.1 Declarations
Two primitives are defined in order to allow users of the GID service to request GID to make (Join) or revoke (Leave) Attribute declarations through a given Port, as follows:
GID_Join.request (attribute_type, attribute_value) GID_Leave.request (attribute_type, attribute_value)
Figure 12-4—GARP architecture
Frame Transmission Frame
Reception
LLC LLC
Frame Transmission Frame
Reception
GARP Participant GARP
GID GIP GID
MAC Relay Entity
Frame Transmission Frame
Reception
LLC GARP Participant
GARP GID Application Application
GARP Application GARP Participant
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 GID determines the action to be taken on receipt of these primitives in accordance with the current Applicant
state for the Attribute concerned, and the action defined for that state and event in the Applicant State Tran-sition Table (Table 12-3). The new state so determined is recorded in the Applicant state variable for that Attribute.
GID Requests can be generated by both the GARP Application component and the GARP Information Prop-agation function.
12.3.2.2 Registration
Two primitives are defined in order to allow the GID service to indicate to its users that a given Attribute value has been registered (Join) or de-registered (Leave) on a given Port, as a result of protocol activity on the LAN segment to which the Port is attached, as follows:
GID_Join.indication (attribute_type, attribute_value) GID_Leave.indication (attribute_type, attribute_value)
GID determines the action to be taken on receipt of registration and de-registration information contained in GARP PDUs in accordance with the current Registrar state for the Attribute concerned, and the action defined for that state and event in the Registrar State Transition Table (Table 12-4). The new state so deter-mined is recorded in the Registrar state variable for that Attribute.
GID Indications are received by both the GARP Application and the GARP Information Propagation func-tion.
12.3.3 GIP
The GARP Information Propagation (GIP) function operates in the same manner for all GARP applications, and enables the Attribute information registered on Bridge Ports to be propagated across the Bridged LAN to other GARP Participants.
Figure 12-5—GID architecture GID
Attribute A state:
Applicant State Machine
Registrar State Machine
Attribute n state:
Attribute B state:
Attribute C state:
Attribute ... state:
Attribute ... state:
Attribute n-2 state:
Attribute n-1 state:
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
The operation of GIP is as follows, for a given GARP Application and GIP Context (12.3.4), and for the set of Ports that are in a Forwarding state as defined by that GIP Context:
a) Any GID_Join.indication received by GIP from a given Port in the set is propagated as a GID_Join.request to the instance(s) of GID associated with any other Port in the set;
b) Any GID_Leave.indication received by GIP from a given Port in the set is propagated as a GID_Leave.request to the instance(s) of GID associated with any other Port in the set (Port P, say) if and only if no registration now exists for that Attribute on any other Port in the set excluding Port P.
The effect of these propagation rules is that, for the set of Ports defined by the GIP Context, registrations are propagated on a given Port if any other Port has seen a registration for the Attribute concerned, and de-regis-trations are propagated on a given Port if all other Ports are now de-registered for the Attribute concerned.
As the set of Ports that are in a Forwarding state for a given GIP Context can change dynamically, for exam-ple as a result of Spanning Tree re-configuration, GIP operates as follows on detection of a change in the set of forwarding Ports:
c) If a Port is added to the set of Ports that are in a Forwarding state, and that Port has previously regis-tered an attribute (a GID_Join.indication has occurred more recently than any GID_Leave.indication for that attribute), then GID_Join.requests for that attribute are propagated to the instance(s) of GID associated with any other Port in the set;
d) If a Port is removed from the set of Ports that are in a Forwarding state, and that Port has previously registered an attribute (a GID_Join.indication has occurred more recently than any GID_Leave.indi-cation for that attribute), then GID_Leave.requests for that attribute are propagated to the instance(s) of GID associated with any other Port in the set.
12.3.4 GARP Information Propagation Context
For a given Port of a GARP-aware Bridge and GARP Application supported by that Bridge, an instance of a GARP Participant can exist for each GARP Information Propagation Context (GIP Context) that is under-stood by that Bridge. A GIP Context defines a subset of the Ports of the Bridge that form the active topology (7.4) that applies in that Context. A GIP Context is defined relative to some other active topology, and defines a subset of that active topology.
An example of a GIP Context is the context defined by the active topology formed by the operation of the Spanning Tree algorithm and protocol (Clause 8). For this GIP Context, the active topology within a given Bridge that is defined by this Context is exactly equal to the active topology formed by the operation of Spanning Tree. This GIP Context is known as the Base Spanning Tree Context.
NOTE—This standard only makes use of the Base Spanning Tree Context to define the operation of GMRP; however, GARP has been defined in a manner that permits the use of other Contexts should this be necessary for other GARP applications, or for extension to the existing functionality of GMRP. In particular, this flexibility has been included in order to allow for the use of GARP Applications in networking architectures based on the use of multiple Spanning Trees and/or Virtual LAN (VLAN) technologies, where the active topology would be defined by the instance of Span-ning Tree, or the VLAN, within which the context was defined. VLANs are the subject of further development under project P802.1Q.
GARP protocol exchanges can occur on all of the Ports of a Bridge; however, the propagation of GARP reg-istration information across a Bridged LAN, controlled by the operation of GIP (12.3.3), for a given GARP Application, occurs only among the set of Ports that comprise the active topology defined by the GIP Con-text. GIP Contexts are defined such that the active topology selected for propagation of registration informa-tion allows GARP registrainforma-tions to be propagated towards all regions of the Bridged LAN that (potentially) contain GARP Participants for that GARP Application and GIP Context. Each GARP Application defines the set of GIP Contexts within which it can operate, defines the rules whereby a set of forwarding Ports is
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 selected for each Context, and assigns GIP Context identifiers to each Context for use in conjunction with
the operation of GARP and its administrative controls (12.9).
A value of 0 shall be used as the GIP Context identifier for the GIP Context defined by the operation of the Spanning Tree algorithm and protocol defined in Clause 8. Where GARP is used in any GIP Context other than 0, the definition of the GARP Application shall specify how PDUs exchanged between GARP Partici-pants are identified as belonging to the GIP Context concerned.