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.3.3 Creating a customerEdgePort 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. The tables that are indexed by a single component id index are: ieee8021BridgeBaseTable ieee8021QBridgeTable ieee8021QBridgeNextFreeLocalVlanTable ieee8021QBridgeLearningConstraintDefaultTable ieee8021CistTable ieee8021MstConfigIdTable CfmVlanTable 17.X.1.1 Components A component is an element represented by a "baggy pants" diagram in an IEEE 802.1 standard. A component contains a relay function whose purpose is to move frames between interfaces to the relay called bridge ports. 17.X.1.2 Bridge Ports A bridge port is a frame source or sink directly attached to the relay function of a bridge component. 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. These interconnections are used in multi-component bridges, such as provider edge bridges and backbone edge bridges, to specify that two interfaces are related in the following manner: Two interfaces, which may be bridge ports, are interconnected if the invocation of a request operation at one of the interfaces causes an indication operation with the same parameters to happen at the other interface. EDITOR'S NOTE - I deliberately did not use the term ISS because that would make interconnection specific to bridge ports. PIPs are not bridge ports. If the formal definition of a PIP has an ISS, then perhaps use of ISS would make the definition tighter. 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 C components are used in two different types of bridges. The first is the C-Component of a customer vlan bridge. The second is as the C-Component of a provider Edge Bridge. Provider Edge Bridge C-Components are created implicitly by the creation of a customer edge port on the S-Component of the Provider Edge Bridge. C-Components that belong to customer bridges are created by a management station performing a row-create on the Component Table or by implicit action such as the insertion of blades into a system. 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 only type of ports that may be created by operating on the C Component are the customerVlanPorts. CustomerEdgePorts are created by a management action on the S-Component of a provider edge bridge. From a management perspective, these entities are managed through the S component or via management operations specific to the provider edge bridge. 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 doing a RowStatus create operation on the CustomerEdgePort table belonging to the ProviderEdgeBridge. 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. The customerNetworkPort, internal variant, is created as a side effect of adding a customerEdgePort to the member set of a backbone vlan. Internal customerNetworPorts are not directly managable. 17.X.3.3.3 Creating a customerEdgePort CustomerEdgePorts are created by doing a row-create operation the the provider edge bridge's CustomerEdgePortTable The CustomerEdgePortTable is a new table containing the following columns SComponentId - The Component ID of the S component that "owns" the CEP BasePort - The Port Number of the CEP on the S component. IfIndex - Refers to the underlying frame source/sink interface CComponentId - A read only index for the C component. Used to xref entity mib CCompPortId - A read only index for the port on the c component. Xref entity RowStatus - Controls the creation and deletion of the port. Note that the C component containing the newly created CEP does not appear in the IEEE 802.1 bridge mib's list of components. That, and the CCompPortId, are index values that are not further interpreted by any IEEE 802.1 mib. These index values, if present, can be used in an implementation dependent manner to allow management stations to cross reference entries in other MIBS, such as the IETF's entity mib, back to the information managed by the IEEE mibs. The newly created port will be added to the port list of the S component of the Provider Edge Bridge. 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.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 a bridge port is ready for operational use, the bridge port must be associated with an entity that acts as a frame source and frame sink. For a typical bridge without the dynamic port creation capability, this will likely be an 802.3 MAC interface. For a bridge with dynamic port creation, it might be something more esoteric like the end point of an MPLS tunnel. Most bridge ports set manage this association by using the BridgeBsaePortIfIndex column in the BridgeBasePort table. It is system dependent if theBridgeBasePortIfIndex column in the BridgeBasePort table needs 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 the association may not be modifiable. The association for Customer Edge Ports is managed by the CepPortCreationTable. The association between Provider Edge Ports and Customer Network Ports for provider edge bridges is managed implicitly by the creation of the PEP/CNP pair by adding backbone service tag to the CEP. The association between Provider Instance Ports and Customer Backbone Ports is managed by the internal lan table. 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.