Outline 17.X Dynamic Component and Port Creation 17.X.1 Overview of the Dynamically Created Bridge Entities 17.X.1.1 Components 17.X.1.2 Bridge Ports 17.X.1.3 Internal LAN Connections 17.X.1.4 Provider Instance Ports 17.X.2 Component Creation 17.X.2.1 D Component Creation 17.X.2.2 C Component Creation 17.X.2.3 S Component Creation 17.X.2.4 B Component Creation 17.X.2.5 I Component Creation 17.X.3 Port Creation 17.X.3.1 Port Creation On D Components 17.X.3.2 Port Creation on C Components 17.X.3.2.1 Creating customerVlanPorts 17.X.3.2.2 Creating customerEdgePorts 17.X.3.2.3 Creating providerEdgePorts 17.X.3.3 Port Creation on S Components 17.X.3.3.1 Creating providerNetworkPorts 17.X.3.3.2 Creating customerNetworkPorts 17.X.3.3.2.1 Creating the customerNetworkPort External Variant 17.X.3.3.2.2 Creating the customerNetworkPort Internal Variant 17.X.3.4 Port Creation on B Components 17.X.3.4.1 Creating providerNetworkPorts 17.X.3.4.2 Creating customerBackbonePorts 17.X.3.5 Port Creation on I Components 17.X.3.5.1 Creating customerNetworkPorts 17.X.3.5.2 Creating virtualInstancePorts 17.X.3.5.3 Creating providerInstancePorts 17.X.3.N Bridge Port Post Creation Operations 17.X Dynamic Component and Port Creation 17.X.1 Overview of the Dynamically Created Bridge Entities The IEEE bridge mibs allow for the possiblity of bridge components and bridge ports to be created under the control of management operations. This functionality is optional. Compliant bridges need not support this functionality or may tie the creation of components and ports to the insertion of physical cards into a system. This subclause outlines the rules and table interactions to be used by management stations to create dynamic components and ports on those systems that support this functionality. A bridge component contains, at a minimum, a collection of bridge ports, a relay unit that fowards and filters frames that travel between ports, and managed objects to control the operation of the component. Certain types of components may contain other objects. These will be addressed later in this subclause in component specific text. Bridge components are the owners of bridge ports, so components must be created before components can be populated with ports. There are 5 different types of bridge components, however the MIBS do not contain any The tables that are indexed by a single component id index are: ieee8021BridgeBaseTable ieee8021QBridgeTable ieee8021QBridgeNextFreeLocalVlanTable ieee8021QBridgeLearningConstraintDefaultTable ieee8021CistTable ieee8021MstConfigIdTable CfmVlanTable 17.X.1.1 Components 17.X.1.2 Bridge Ports 17.X.1.3 Internal LAN Connections In Provider Backbone Bridges, PBBs, there needs to be a way of specifying the interconnections between the PIPs on the I-Component and the Customer Backbone Port on the B Component. This is done via the ieee8021BridgeILanIfTable defined in the Bridge mib. Essentially, this table allows for the creation of a new "interface" to represent the I-LAN and then the ifStackTable is used to specify the interconnection. 17.X.1.4 Provider Instance Ports Even though it is technically not a bridge port, the creation Provider Instance Ports on I-Components are discussed as part of the bridge port creation logic for I-Components. 17.X.2 Component Creation A component is created by making an entry in the ieee8021BridgeBaseTable with the ieee8021BridgeBaseComponentType set to the proper value. A bridge component consists of a relay function and related bridge ports. The component type determines if the relay operates on untagged, C-Tagged, or S-Tagged frames. It also determines which specific type(s) of bridge ports may be created on the component. 17.X.2.1 D Component Creation No specific component creation rules 17.X.2.2 C Component Creation When a C component is created, the system has to know if the C component is being set up to act as an 802.1Q bridge or if it is to act as the C-Componenet of a Provider Edge Bridge. Editor Note - As of draft 3.2 there is no mechanism to specify this. In the remainder of this document, I'm assuming that both the management station and agent know which is the case for any particular C component by the invocation of deep and powerful voo-doo. Editor Note - I have submitted a comment against draft 3.2 that proposed a couple of ways that this voo-doo can be specified in the MIB. 17.X.2.3 S Component Creation No specific component creation rules 17.X.2.4 B Component Creation No specific component creation rules 17.X.2.5 I Component Creation No specific component creation rules 17.X.3 Port Creation This subclause of the document discusses how ports of each relevant port type to be created on each relevant component type. The general procedure is for the network administrator to perform an SNMP row create operation on a table specific to the type of port being created. If the operation suceeds, an entry will be implicitly created in the BridgeBasePortTable by the agent. The specific details are outlined in the following subclauses of the document. 17.X.3.1 Port Creation On D Components D components are used in 802.1D bridges. Creation of a port on a D bridge requires specifying the component and port index in the T.B.D. table. Editor Note - Draft 3.2 does not support the creation of 802.1D ports. Editor Note - Draft 3.2 does not have a value to represent the type of an 802.1D port. The type of the component refered to by the component id parameter must be dBridgeComponent(4). The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per T.B.D 802.1D Port Table BridgeBasePort - As per T.B.D 802.1D Port Table BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerVlanPort(0) must be set PortType - none(0) PortExternal - Implementation Specific 17.X.3.2 Port Creation on C Components C Components support three different types of bridge ports. These are customerVlanPorts, customerEdgePorts, and ProviderEdgePorts. A C component that is not part of a Provider Edge Bridge may have customerVlanPorts. A C component that is part of a Provider Edge Bridge must have exactly 1 customerEdgePort and any number of ProviderEdgePorts. The two type of ports that may be created by operating on the C Component are the customerVlanPorts and the customerEdgePorts. ProviderEdgePorts are created as a side effect of the creation of a customerNetworkPort on the S-VLAN component of a Provider Edge Bridge. 17.X.3.2.1 Creating customerVlanPorts customerVlanPorts are created by performing a row-create operation on the ieee8021QBridgeCVlanPortTable for a C component that is configured to act as an 802.1Q bridge. The required columns are the component id and the port number to use for the newly created port. The type of the component refered to by the component id parameter must be cVlanComponent(2) configured for Q-Bridge operation. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerVlanPort(0) must be set PortType - customerVlanPort(2) PortExternal - Implementation Specific 17.X.3.2.2 Creating customerEdgePorts customerEdgePorts are created by performing a row-create operation on the ieee8021QBridgeCVlanPortTable for a C component that is configured to be the C component of a providerEdgeBridge. The required columns are the component id and the port number to use for the newly created port. The type of the component refered to by the component id parameter must be cVlanComponent(2) configured for PEB operation. There must not be another customerEdgePort configured on this component as a cVlanComponent supports exactly 1 customerEdgePort The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerEdgePort(3) must be set PortType - customerEdgePort(5) PortExternal - Implementation Specific 17.X.3.2.3 Creating providerEdgePorts ProviderEdgePorts are created implicitly by creating a providerNetworkPort on the S Component of a provider edge bridge. See the discusson on port creation in the S Component subclause of this subclause of the standard. 17.X.3.3 Port Creation on S Components S Components are the S-VLAN aware component of an S-VLAN bridge or Provider Bridges. There are two different types of ports that may be created on on S components. These are providerNetworkPorts and customerNetworkPorts. 17.X.3.3.1 Creating providerNetworkPorts A providerNetworkPort on an S Component works pretty much the same way as a customerVlanPort on a C component except that the VID value used for forwarding and filtering decisions must come from an S-TAG and not a C-TAG. Creating a providerNetworkPort uses the same tables as creating a customerVlanPort. The type of the component refered to by the component id parameter must be sVlanComponent(3). The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit providerNetworkPort(1) must be set PortType - providerNetworkPort(3) PortExternal - Implementation Specific 17.X.3.3.2 Creating customerNetworkPorts There are two variants on the creation of customerNetworkPorts. customerNetworkPorts are either internal or external. Internal ports are directly connected to a providerEdgePort on the C-Vlan component of a Provider Edge Bridge and provide a C-Tagged service interface. External ports are connected to an external customer system and provide either a port based or S-Tagged service interface. Editor Note - need a new table in the provider bridge mib to allow for the creation of both internal and external customerNetworkPorts. ieee8021CNPConfigurationTable BComponentId - Component Id of the specified B component BridgePort - BridgePortNumber of the customerNetworkPort CComponentId - Component Id of the C-Vlan component if an internal customerNetworkPort is being created or zero if an external customerNetworkPort is being created. S-VID - S-VID for service if an internal customerNetworkPort is to be created. 0 if external. NOTE - Need Draft 3.2 comment to create this table. 17.X.3.3.2.1 Creating the customerNetworkPort External Variant The external variant of a customerNetworkPort is used to provide a port based or S-tagged service interface to customer of the provider bridged network. Creating a customerNetworPort of the external variant requires specifying the B component id and bridge port number of the port to be created. This is done by creating an entry in the ieee8021CNPConfigurationTable with 0 specified for the CComonentId and S-VID. This creates a new entry in the ieee8021QBridgeCVlanPortTable for the S-Component. This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit (2) must be set PortType - customerNetworkPort(4) PortExternal - Implementation Specific 17.X.3.3.2.2 Creating the customerNetworkPort Internal Variant The internal variant of a customerNetworkPort is used to provide a C-tagged service interface to the customer of a provider bridged network. Creating a customerNetworkPort of the internal variant requires specifying the following information: B component id and bridge port number of the port to be created. S-VID - Set to the VID of the service to carry the packets CComponentId - Component id of the C-VLAN component The CComponentID must be the ID of a C-VLAN component configured for provider edge bridge operation and there must be a Customer Edge Port configured on this component. There must not be another entry in the PbEdgePortEntry table that matches the component id for the C-VLAN component and bridge port number of the CEP. The S-VID must match an entry in the VlanCurrentTable and may match an entry in the VlanStaticTable. This operation adds the newly created port to the member set of the vlan and updates the state of the VlanCurrentTable to indicate this. NOTE - This isn't quite correct for asymmetric operation. This creates a new entry in the ieee8021QBridgeCVlanPortTable for the S-Component. This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerNetworkPort(2) must be set PortType - customerNetworkPort(4) PortExternal - Implementation Specific Additionally, this operation creates a providerEdgePort on the specified C-Vlan component of the provider bridge. As such, an entry will be created in both the ieee8021QBridgeCVlanPort table and the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit NO TYPE(3) must be set PortType - XXX NO TYPE PortExternal - Implementation Specific Finally, an entry will be made in the PbEdgePortTable for the provider edge port. The component ID will be set to the componet id of the relevant C-VLAN, the port number will be set to the port number of the CEP, and the S-VID will be set to the specified S-VID parameter. 17.X.3.4 Port Creation on B Components B and I components are the two components that comprise a Provider Backbone Bridge or Provider Backbone Edge Bridge. These components are defined in standard 802.1ah ( Draft 4.1 as of the time of this writing ) and provide what is generally known as "MAC in MAC" transport of Ethernet frames. Ports on these PBB components are creating using a clause 12 managed object defined in 802.1ah D4.1. For the purposes of this note, I am assuming that a table has been added to the pbb MIB to support port creation on these components. The table, called PbbPortConfigTable, is assumed to be a table with the following entries: ComponentId PortNumber PortType RowStatus One creates a new port by specifying the component id, port number, and type in a row and then one sets rowstatus to create the entry. Depending upon the type of the component and type of the port, additional entries are made in other tables. The type specific details are discussed in the subclauses specific to B and I components. 17.X.3.4.1 Creating providerNetworkPorts The creation providerNetworkPorts starts with the creation of an entry in the PbbPortConfigTable with the componentId, portNumber, and portType fields set properly. ComponentID - Component Number of B component PortNumber - As appropriate PortType - providerNetworkPort RowStatus - Probably either createAndGo or createAndWait As a providerNetworkPort is a port on a B component, which is a sub-species of Q bridge component, the act of creating a providerNetworkPort causes entries to be made in the QBridgePortTable and the BridgeBasePortTable. The following columns in the QBridgeCVlanPortEntry will be filled in as follows: QBridgeCVlanPortComponentId - As per PbbPortConfigTable QBridgeCVlanPortNumber - As per PbbPortConfigTable QBridgeCVlanRowStatus - "Active" This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit providerNetworkPort(2) must be set PortType - providerNetworkPort(3) PortExternal - Implementation Specific 17.X.3.4.2 Creating customerBackbonePorts The creation customerBackbonePorts starts with the creation of an entry in the PbbPortConfigTable with the componentId, portNumber, and portType fields set properly. ComponentID - Component Number of B component PortNumber - As appropriate PortType - customerBackBonePort RowStatus - Probably either createAndGo or createAndWait As a customerBackBone is a port on a B component, which is a sub-species of Q bridge component, the act of creating a customerBackbonePort causes entries to be made in the QBridgePortTable and the BridgeBasePortTable. The following columns in the QBridgeCVlanPortEntry will be filled in as follows: QBridgeCVlanPortComponentId - As per PbbPortConfigTable QBridgeCVlanPortNumber - As per PbbPortConfigTable QBridgeCVlanRowStatus - "Active" This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerBackbonePort(2) must be set PortType - customerBackbonePort(3) PortExternal - Implementation Specific 17.X.3.5 Port Creation on I Components Creating a bridge port on an I Component works the same way as creating a port on a B component with the exception that the rules for determination of the legality of the port type are different. Creating PIPs works in a manner analogous to the creation of a bridge port, but as PIPs are not bridge ports the details are somewhat different. 17.X.3.5.1 Creating customerNetworkPorts The creation of customerNetworkPorts starts with the creation of an entry in the PbbPortConfigTable with the componentId, portNumber, and portType fields set properly. ComponentID - Component Number of I component PortNumber - As appropriate PortType - customerNetworkPort RowStatus - Probably either createAndGo or createAndWait As a customerNetworkPort is a port on a I component, which is a sub-species of Q bridge component, the act of creating a customerBackbonePort causes entries to be made in the QBridgePortTable and the BridgeBasePortTable. The following columns in the QBridgeCVlanPortEntry will be filled in as follows: QBridgeCVlanPortComponentId - As per PbbPortConfigTable QBridgeCVlanPortNumber - As per PbbPortConfigTable QBridgeCVlanRowStatus - "Active" This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit customerNetworkPort must be set PortType - customerNetworkPort PortExternal - Implementation Specific 17.X.3.5.2 Creating virtualInstancePorts The creation of virtualInstancePort starts with the creation of an entry in the PbbPortConfigTable with the componentId, portNumber, and portType fields set properly. ComponentID - Component Number of I component PortNumber - As appropriate PortType - virtualInstancePort RowStatus - Probably either createAndGo or createAndWait An entry will be created in the ieee8021PbbVipTable with the following columns set: PbbVipPipIfIndex - 0 PbbVipISid - Not Assigned Value 0? PbbVipDefaultDstBMAC - Not Assigned Value 0? PbbVipType - IngressAndEgress PbbVipRowStatus - "Active" As a virtualInstancePort is a port on a I component, which is a sub-species of Q bridge component, the act of creating a customerBackbonePort causes entries to be made in the QBridgePortTable and the BridgeBasePortTable. The following columns in the QBridgeCVlanPortEntry will be filled in as follows: QBridgeCVlanPortComponentId - As per PbbPortConfigTable QBridgeCVlanPortNumber - As per PbbPortConfigTable QBridgeCVlanRowStatus - "Active" This operation also created a new entry in the BridgeBasePortTable. The implicitly constructed BridgeBasePortTable entry will have the following fields filled in: BridgeBaseComponentId - As per QBridgeCVlanPortTable BridgeBasePort - As per QBridgeCVlanPortTable BridgeBasePortIfIndex - Implementation Specific Action DelayExceededDiscards - Statistic, reset to 0 by creation MtuExceededDiscards - Statistic, reset to 0 by creation PortCapabilties - Implementation Specific PortTypeCapabilities - Implementation Specific bit virtualInstancePort must be set PortType - virtualInstancePort PortExternal - Implementation Specific Note that before becoming operational, the VIP must be assigned to a PIP and must be assigned to a service by setting an I-SID value. Furthermore, the mapping tables must be set up in a consistent basis. 17.X.3.5.3 Creating providerInstancePorts Provider instance ports are not bridge ports, but they are necessary parts of the internal operation of a BEB. They share many characteristics of bridge ports, simply because both PIPs and bridge ports are interfaces that transfer MAC frames, but are not connected to a mac relay function. PIP are created using a clause 12 manageed object defined in 802.1ah D4.1. For the purposes of this note I am assuming that a table has been added to the pbb MIB to support PIP creation. The table, called the PbbPipCreateTable is assumed to be ba table with the following values: ifIndex - Something appropriate ComponentId - ComponentId of an I-Component BMAC - Backbone MAC, if necessary RowStatus - either createAndGo or createAndWait This operation, when successful, results in the creation of a PIP and the creation of a correspond entry in the ieee8021PbbPipTable: pbbPipIfIndex - As specified in the PbbPipCreateTable pbbPipBMACAddress - Implementation Default or specified value pbbPipPipName - Implementation Default pbbPipICompnentId - As specified in the PbbPipCreateTable pbbPipVipMAP - Empty Mapping Note that before the operation can occur on this PIP, it may be necessary to modify the BMAC address value of the PIP, especially in the case where local MAC addresses are to be used in the Provider Backbone Network. 17.X.3.N Required Post Creation Operations Before any bridge port is ready for operational use, the BridgeBasePortIfIndex column in the BridgeBasePort table may need to be filled in with the appropriate ifIndex for the newly created bridge port. Systems that enforce a specific mapping between bridge port numbers and physical interfaces may have the agent automatically fill in this field and it may not be modifiable. Additionally, for ports on elements of provider bridges and provider backbone bridges, instances in service tables must be created before the ports are capable of passing frames according to the relevant clauses of 802.1Q and subsequent amendments.