Figure PR.16 - PhysicalPort in More Detail

PhysicalPorts are an important type of object to keep track of. This is where communication begins and/or ends on a PhysicalDevice. PhysicalPorts also play a prominent role in topology and FCAPS applications, and enable Service Providers to determine what Customers are running what Services where in the network. <br/>A PhysicalPort represents an actual or potential end point of a topological (physical) link, and corresponds directly to a physical port on a topology map. PhysicalPorts are always contained by another physical object - they can't exist by themselves. The two most common examples are PhysicalPorts on a Card and on a Chassis. These are represented using separate aggregations, and will be described in the sections that explain Card and Chassis. <br/><i> Note: relationships between PhysicalPort and Card & Chassis are only examples and could complemented with other relationships.</i><br/>The following Figure illustrates the concept of a PhysicalPort.<br/>PhysicalContainer, as we will see in the next section, is the superclass for Equipment, EquipmentHolders, PhysicalComponents, and AuxiliaryComponents. Note that a PhysicalPort is not a type of PhysicalContainer. This is because a PhysicalPort contains logical components. <br/>The ifType attribute is an enumerated integer, and specifies the particular media type of the link. This is closely related to the typeOfPort attribute, which is an enumerated integer that defines the particular type of PhysicalPort this instance is (e.g., Ethernet vs. ATM). The portNumber attribute is the number of this physical port as defined by the application, and the vendorPortName is a critical attribute that contains the name of the port according to the vendor. This enables an enterprise-wide naming scheme to be correlated with vendor-specific names, which are necessary for configuring the port.<br/>For example, an enterprise may need to assign either special strings, or a monotonically increasing number to distinguish all of their PhysicalPorts. Or, an enterprise may want to reuse PhysicalPort numbers, so that “port 1” on any device has special significance. Both of these schemes are very common, and must be accommodated in the model.<br/>However, if an enterprise chooses to use their own naming scheme, then this makes it difficult, if not impossible, to program the device. This is because a (logical) DeviceInterface is contained within a PhysicalPort. Programming a device also means programming its device interfaces.<br/>