- Chapter 1: Overview of Cisco Prime Optical GateWay/CORBA
- Chapter 2: NE- and Cisco Prime Optical-Specific Details
- Chapter 3: Using Cisco Prime Optical GateWay/CORBA Interfaces
- Chapter 4: Using Connectionless Interfaces
- Appendix A: Notifications, Fault Management, and Probable Cause Mapping
- Appendix B: Server Administration and Configuration
- Appendix C: OSS Use Cases and Client Development
- Appendix D: Equipment List for NEs
Cisco Prime Optical GateWay/CORBA User Guide and Programmer Manual, 9.3
- Updated:
- February 1, 2018
Chapter: Chapter 4: Using Connectionless Interfaces
- 4.1 Understanding Key Concepts
- 4.2 Interface Managers
- 4.3 Entity Characteristics
- 4.4 Supported Provisioning Interfaces
- 4.5 EVC Provisioning Interfaces
- 4.5.1 CPTP Provisioning Interfaces
- 4.5.1.1 provisionEquipment
- 4.5.1.2 unprovisionEquipment
- 4.5.1.3 setAdditionalInfo
- 4.5.1.4 ConfigConnLessInfos
- 4.5.1.5 DeleteAllConnLessInfos
- 4.5.2 MFD Provisioning Interfaces
- 4.5.2.1 createMFD
- 4.5.2.2 assignCPTPsToMFD
- 4.5.2.3 unassignCPTPsFromMFD
- 4.5.2.4 deleteMFD
- 4.5.2.5 modifyMFD
- 4.5.3 Flow Domain Provisioning Interfaces
- 4.5.3.1 createFlowDomain
- 4.5.3.2 deleteFlowDomain
- 4.5.3.3 modifyFlowDomain
- 4.5.3.4 associateMFDsWithFlowDomain
- 4.5.3.5 deAssociateMFDsFromFlowDomain
- 4.5.4 EVC FDFr Provisioning Interfaces
- 4.5.4.1 createAndActivateFDFr
- 4.5.4.2 deactivateAndDeleteFDFr
- 4.5.4.3 modifyFDFr
- 4.5.5 Link Aggregation Provisioning Interfaces
- 4.5.5.1 createFTP
- 4.5.5.2 deleteFTP
- 4.5.5.3 setTPData
- 4.5.6 Traffic Conditioning Profile Provisioning Interfaces
- 4.5.6.1 createTCProfile
- 4.5.6.2 deleteTCProfile
- 4.5.6.3 modifyTCProfile
- 4.6 MPLS-TP Provisioning Interfaces
- 4.6.1 MPLS-TP Tunnel Provisioning Interfaces
- 4.6.1.1 createAndActivateSNC
- 4.6.1.2 deactivateAndDeleteSNC
- 4.6.1.3 modifySNC
- 4.6.2 MPLS-TP LSP Provisioning Interfaces
- 4.6.2.1 createAndActivateSNC
- 4.6.2.2 deactivateAndDeleteSNC
- 4.6.2.3 modifySNC
- 4.6.3 MPLS-TP Protection (Provisioning)
- 4.6.4 BFD Template, Node ID, and Label Range Provisioning Interface
- 4.6.4.1 setAdditionalInfo
- 4.7 Pseudowire Provisioning Interfaces
- 4.7.1 Pseudowire FDFr Provisioning Interfaces
- 4.7.1.1 createAndActivateFDFr
- 4.7.1.2 deactivateAndDeleteFDFr
- 4.7.1.3 modifyFDFr
- 4.7.2 Pseudowire Mixed Configuration (Provisioning)
- 4.7.3 Pseudowire Class and Loopback Provisioning Interface
- 4.7.3.1 setAdditionalInfo
- 4.7.4 Pseudowire QoS Provisioning Interface
- 4.7.4.1 TCProfileMgr::setAdditionalInfo
- 4.8 Supported Inventory Interfaces
- 4.9 EVC Inventory Interfaces
- 4.9.1 CPTP Inventory Interfaces
- 4.9.1.1 getAllCPTPs
- 4.9.1.2 getAllAssignedCPTPs
- 4.9.1.3 getAllAssignableCPTPs
- 4.9.1.4 getAllPTPs
- 4.9.1.5 getTP
- 4.9.2 MFD Inventory Interfaces
- 4.9.2.1 getAllAssociatedMFDs
- 4.9.2.2 getAllSupportedMFDs
- 4.9.2.3 getMFD
- 4.9.2.4 getAssigningMFD
- 4.9.3 Flow Domain Inventory Interfaces
- 4.9.3.1 getAllFlowDomains
- 4.9.3.2 getFlowDomainsByUserLabel
- 4.9.3.3 getFlowDomain
- 4.9.3.4 getAllTopologicalLinksOfFD
- 4.9.3.5 getAssociatingFD
- 4.9.4 EVC FDFr Inventory Interfaces
- 4.9.4.1 getFDFr
- 4.9.4.2 getAllFDFrs
- 4.9.4.3 getFDFrsWithTP
- 4.9.4.4 getFDFrsByUserLabel
- 4.9.4.5 getAllFDFrNames
- 4.9.4.6 getFDFrNamesWithTP
- 4.9.4.7 getFDFrRoute
- 4.9.5 Link Aggregation Inventory Interfaces
- 4.9.5.1 getAllFTPs
- 4.9.5.2 getAllFTPNames
- 4.9.5.3 getTP
- 4.9.6 Common Inventory Interface
- 4.9.6.1 getTransmissionParams
- 4.9.7 Traffic Conditioning Profile Inventory Interfaces
- 4.9.7.1 getAllTCProfiles
- 4.9.7.2 getTCProfile
- 4.10 MPLS-TP Inventory Interfaces
- 4.10.1 MPLS-TP Tunnel Inventory Interfaces
- 4.10.1.1 getSNC
- 4.10.1.2 getAllSubnetworkConnectionsWithTP
- 4.10.1.3 getAllSubnetworkConnectionsNamesWithTP
- 4.10.1.4 getAllSubnetworkConnections
- 4.10.1.5 getAllSubnetworkConnectionNames
- 4.10.1.6 getSNCsByUserLabel
- 4.10.2 MPLS-TP LSP Inventory Interfaces
- 4.10.2.1 getSNC
- 4.10.2.2 getAllSubnetworkConnectionsWithTP
- 4.10.2.3 getAllSubnetworkConnectionsNamesWithTP
- 4.10.3 MPLS-TP Tunnel Link Inventory Interfaces
- 4.10.3.1 getTopologicalLink
- 4.10.3.2 getAllTopologicalLinks
- 4.10.3.3 getAllTopologicalLinkNames
- 4.10.3.4 getAllTopLevelTopologicalLinks
- 4.10.3.5 getAllTopLevelTopologicalLinkNames
- 4.10.3.6 getTopLevelTopologicalLink
- 4.10.4 MPLS-TP LSP Route Inventory Interfaces
- 4.10.4.1 getRoute
- 4.10.4.2 getRouteAndTopologicalLinks
- 4.10.4.3 getAllCrossConnections
- 4.10.5 MPLS-TP Protection (Inventory)
- 4.10.6 BFD Templates, Node ID, and Label Range Inventory Interface
- 4.10.6.1 getManagedElement
- 4.11 Pseudowire Inventory Interfaces
- 4.11.1 Pseudowire FDFr Inventory Interfaces
- 4.11.1.1 getFDFr
- 4.11.1.2 getAllFDFrs
- 4.11.1.3 getFDFrsWithTP
- 4.11.1.4 getAllFDFrNames
- 4.11.1.5 getFDFrNamesWithTP
- 4.11.1.6 getFDFrsByUserLabel
- 4.11.1.7 getFDFrRoute
- 4.11.2 Pseudowire Class, Loopback, and QoS Policy Inventory Interface
- 4.11.2.1 getManagedElement
- 4.12 Alarm Summaries
- 4.13 Error Messages
Using GateWay/CORBA Connectionless Interfaces
This chapter describes each connectionless interface that Cisco Prime Optical supports. This chapter includes the following sections:
- Understanding Key Concepts
- Interface Managers
- Entity Characteristics
- Supported Provisioning Interfaces
–
MPLS-TP Provisioning Interfaces
– Pseudowire Provisioning Interfaces
4.1 Understanding Key Concepts
This section describes the following key concepts referenced in this chapter:
- Ethernet Virtual Circuit
- Connectionless Port Termination Point
- Matrix Flow Domain
- Flow Domain
- EVC Flow Domain Fragment
- Link Aggregation
- MPLS and MPLS-TP
- MPLS-TP Tunnel
- MPLS-TP LSP
- Pseudowire
- Pseudowire Flow Domain Fragment
4.1.1 Ethernet Virtual Circuit
An Ethernet Virtual Circuit (EVC) represents a Carrier Ethernet service and is an entity that provides an end-to-end connection between two or more customer endpoints. The instance of a specific EVC service on the physical interface of each network device through which the EVC passes is called an Ethernet Flow Point (EFP).
The key attributes of the flow point (FP) are:
- FP ID—Generated when the FP is created.
- EVC ID—Associated EVC that the EFP a is part of.
- Encapsulation string—Defines the classification criteria for an incoming packet.
- Forwarding operation—Defines the operation to be applied on frames that belong to the EFP.
- Ingress rewrite operation—Defines the rewrites to be performed on the frames that belong to the EFP before proceeding with the forwarding operation.
- Egress rewrite operation—Defines the rewrites to be performed on the frames being transmitted out of the EFP. For multipoint services, only symmetrical egress operations are supported on the PTF_10GE_4, PT_10GE_4, and PTSA_GE cards. For point-to-point services, the same result is achieved using various combinations of ingress rewrite operations on User Network Interface (UNI) and Network Node Interface (NNI) ports.
When a packet arrives on an FP, it is processed only if the packet’s VLAN tag matches the VLAN tag mentioned in the encapsulation string of this FP. The ingress rewrite operation is applied on the matching Ethernet frames and is forwarded to other FPs participating in this EVC based on forwarding operations.
All the FPs within a node, for a particular EVC, are tied together using a bridge domain construct. A bridge domain is an Ethernet broadcast domain internal to a device. The bridge domain enables you to decouple a VLAN from a broadcast domain. The bridge domain number is local to the node and need not be unique across the network for the entire EVC. Different EVC nodes can have the same or a different bridge domain number. However, the bridge domain number is unique for an EVC within a node.
The APIs related to the following entities are described in this chapter:
- Connectionless PTPs (CPTPs)
- Matrix Flow Domains (MFDs)
- Flow Domains (FDs)
- Flow Domain Fragments (FDFrs)
Figure 4-1 displays the relationships among the above-mentioned entities.
Figure 4-1 Relationships Among Entities
All administrative information related to CPTPs, MFDs, and FDs is stored in the Prime Optical server internal database and is available only through this Prime Optical server. The administrative information is not visible in other Prime Optical servers. If any service (Carrier Ethernet EVC or pseudowire) is created outside this scope, the service collides with the administrative organization.
For example, a CTC operator can create a pseudowire (PW) or an EVC that has EFPs. The EFPs are not based on CPTPs associated to the same FD. In this case, services are discovered and associated to the given FD, but a corresponding notification is generated to inform the Prime Optical operator.
For descriptions of EVC provisioning and inventory interfaces, see the following sections:
4.1.2 Connectionless Port Termination Point
A Connectionless Port Termination Point (CPTP) is a potential port capability for connectionless technologies. A CPTP is not a new object, but it is a logical entity of a piece of equipment and supports a connectionless client layer. A CPTP is a grouping of potential FPs on the server layer. The FPs are the clients of a CPTP connected using MFD.
A CPTP is created as a Physical Termination Point (PTP) if the port is an external port and if it does not support encapsulation and link aggregation. CPTP is created as a Floating Termination Point (FTP) if the port is an internal encapsulation port and if it supports encapsulation and link aggregation. A CPTP on an MFD can be either a PTP or an FTP.
ConnectionlessPort is a boolean layered parameter that identifies termination points (TPs) as CPTPs at connectionless layers; for example, Ethernet. For an Ethernet client layer, a CPTP corresponds to an IEEE bridge port, which can either be a UNI or an NNI.
The role played by CPTP for its connectionless client layer is stored in the “PortTPRoleState” layered parameter, which is associated to the PTP/FTP object. The “PortTPRoleState” parameter can assume the following values:
- unassigned CPTP—The initial role of a CPTP is unassigned. If CPTPs are automatically created, they are created as unassigned CPTPs when the equipment that supports the port is plugged into the NE. In this role, the CPTP cannot carry any traffic.
- assigned CPTP—An unassigned CPTP becomes an assigned CPTP when it is associated to an MFD through a management operation. In this role, the CPTP cannot carry any traffic because the MFD is not associated to an FD.
- fdInternal CPTP—An assigned CPTP becomes an fdInternal CPTP when the MFD is associated to an FD. An unassigned CPTP becomes an fdInternal CPTP when it is assigned to an MFD that is already associated to an FD. In this role, the potential client FPs of the CPTP can be used as internal points of the route of a Flow Domain Fragment (FDFr) and can carry traffic.
- fdEdge CPTP—An fdEdge CPTP is the same as an fdInternal CPTP. In this role, the CPTP acts as an edge in the FD.
For descriptions of CPTP provisioning and inventory interfaces, see the following sections:
Figure 4-2 displays the different CPTP states.
4.1.3 Matrix Flow Domain
A Matrix Flow Domain (MFD) is a logical entity that is contained within an ME. The ME can contain many MFDs. An MFD consists of a grouping of assigned CPTPs (MFD ports). An MFD is related to only one FD. An MFD is an FD at the lowest level of decomposition that represents the actual minimum decomposition of the hardware.
For descriptions of MFD provisioning and inventory interfaces, see the following sections:
4.1.4 Flow Domain
The Flow Domain (FD) associates more MFDs (one for each NE) and the server layer TPs of FPs assigned to it. An FD indicates the potential for flow of traffic between a set of points and contains an administrative partitioning of the connectionless network domain.
Connection-oriented subnetworks constitute the widespread transport layer (DWDM, SONET/SDH). Connection-oriented subnetworks are shared by many network applications, but connectionless subnetworks, such as Metro Ethernet, are deployed as smaller islands dedicated to a single network application; for example, a corporate customer site.
FD provisioning capability allows a Network Management System (NMS) to instantiate and to change an FD so it can meet the infrastructure requirement (CPTPs, MFDs) needed to fulfill requests (FDFr setup, tear-down, and modification) received from a service order system. An ME can participate in more than one FD at the same layer rate, but in only one subnetwork.
For descriptions of Flow Domain provisioning and inventory interfaces, see the following sections:
4.1.5 EVC Flow Domain Fragment
An EVC Flow Domain Fragment (FDFr) is a logical entity that contains a transparent end-to-end connectivity between two or more FPs (at the same connectionless layer) within an FD. The FDFr represents a Virtual Private Network (VPN) for a single customer in the provider network and enables the flow of traffic between FPs.
The server-layer CPTPs of the FPs that are connected through an FDFr must be assigned to MFDs that are associated to the FD that contains the FDFr. If traffic arrives at a point that is a member of an FDFr, it emerges at one or more of the other edge FPs that are members of the same FDFr.
The edge FPs that act as endpoints of the FDFr can be associated with CPTPs connected to customer domains or to other provider domains (of the same or different providers). The VLAN IDs of the FPs of the same FDFr must be equal and in particular must be the VLAN ID of the outermost frame. An FDFr may also support untagged frames or may be unaware of frame tags.
An FDFr is used to model the EVC and has the following attributes:
- Directionality—Either bidirectional or unidirectional. For Ethernet, directionality is always bidirectional.
- Layered transmission parameters—Technology-specific parameters associated with the layer that the FDFr is connecting; for example, Ethernet.
- aEnd TPs—A list of FPs that delimit the FDFr and characterize the edges (entry or exit points). aEnd TPs are clients of the fdEdge CPTPs. For a bidirectional FDFr, this attribute may be combined with zEnd TPs to obtain all the FPs that are associated to the FDFr. For a bidirectional Point-to-Point (PPP) FDFr, it is recommended that you specify one TP in aEnd and the other TP in zEnd. For a multipoint FDFr or a PPP FDFr that may be expanded to multipoint, it is recommended that you specify all the TPs in aEnd.
- zEnd TPs—Represents a list of FPs that delimit the FDFr and characterize the edges (entry or exit points). zEnd TPs are clients of the fdEdge CPTPs. For a bidirectional FDFr, this attribute may be combined with aEnd TPs to obtain all the FPs that are associated to the FDFr.
- Flexible—Indicates whether the FDFr is fixed or flexible. If the FDFr is fixed, the NMS cannot modify or delete it and you cannot add or remove FPs.
- Administrative State—Indicates whether the FDFr is locked or unlocked. If the FDFr is locked, traffic units cannot flow through the FDFr. If the FDFr is unlocked, traffic units are allowed to flow through the FDFr.
- FDFr state—Indicates one of the following values:
– Active—All MFDFrs and all edge FPs and internal FPs for the FDFr are active in the network.
– Partial—All parts (MFDFrs or FPs) of the FDFr either were not created during the creation operation or were not deleted during the deletion operation.
– Point-to-multipoint (E-Tree)
An FP is a point in a connectionless layer, which represents an association between a CPTP and an FDFr. An FP is modeled as a connection termination point (CTP) and it is either an FDFr endpoint where traffic enters or exits an FDFr or an FDFr internal point used to define the route of an FDFr.
FPs are created as CTP objects when the associated FDFr is created and are deleted when the associated FDFr is deleted. FPs do not exist without an associated FDFr. As a result, only in-use FPs are represented as CTP objects at the interface, and therefore only in-use FPs can be inventoried.
For Ethernet, FPs are always bidirectional. Operations on frames, which either enter or exit an FDFr are defined on the CTP object. The connectionless layered parameters are specified in the layered transmission parameters attribute inherited from the TP object. This attribute represents the technology-specific parameters associated with the different connectionless layers that are supported by the FP. If the NMS does not provide a name for the FP, the Element Management System (EMS) uses the FDFr VLAN ID.
For descriptions of EVC FDFr provisioning and inventory interfaces, see the following sections:
4.1.6 Link Aggregation
Link Aggregation (LAG) is supported using the Link Aggregation Control Protocol (LACP). LACP guarantees the compatibility of both sides of the aggregated link. LACP, which is specified in IEEE 802.3ad, has many attributes and configuration parameters that are handled at the EMS level. LAG support in Multi-Technology Network Management (MTNM) version 3.5 does not deal with these attributes and configuration parameters at the NMS level.
A LAG is represented by an FTP, and the new layer rate defined for it is LR_LAG_Fragment(305). The LAG FTP is the Edge CPTP. A LAG FTP may either be created by the EMS and discovered by the NMS or it can be created by the NMS using the createFTP() operation.
A LAN port, which usually can be an edge CPTP, cannot be an edge CPTP if it is a member of a LAG. Whether created by an EMS or NMS, LAG FTPs act like other fragment TPs. You can configure the maximum number of allowed members using the AllocationMaximum attribute. You can configure a specific number of members using the AllocatedNumber attribute.
If LAGs are created by the EMS, the EMS creates all the potential LAG FTPs that it can handle, each with FragmentServerLayer set to a layer rate at which LAG can be supported and with AllocationMaximum set to the maximum number of members that can be supported for that layer rate.
As with Cisco equipment, an Ethernet LAG port can aggregate client Ethernet ports of different ME cards (for example, PTSA_GE). The corresponding FTP is logically positioned on the unique shelf of the ME itself. As a result, the FTP name does not contain any reference to slots:
For descriptions of LAG provisioning and inventory interfaces, see the following sections:
4.1.7 MPLS and MPLS-TP
Multiprotocol Label Switching (MPLS) allows the forwarding of packets based on labels. In a normal IP network, the packets are switched based on the destination IP address. In an MPLS network, the packets are switched based on labels.
In an MPLS network, the labels can be distributed using three different protocols:
- Label Distribution Protocol (LDP)
- Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
- Border Gateway Protocol (BGP)
BGP is a routing protocol used in big IP networks where the labeling layer is mostly used to implement Layer 3 VPNs. After the labels are distributed within a network, the packets are labeled and forwarded based on labels. The advantages of labeled networks are:
- Protocol agnostic—Can transport any kind of protocol; for example, IP, ATM, Any Transport over MPLS (AToM).
- High scalability.
- Traffic Engineering—Load balancing and automatic adaption to link changes.
Multiprotocol Label Switching-Transport Profile (MPLS-TP) is a carrier-grade packet transport technology that enables the move from SONET and SDH time-division multiplexing (TDM) to packet switching. MPLS-TP enables MPLS to be deployed in a transport network and to operate similarly to existing transport technologies. MPLS-TP enables MPLS to support packet transport services with a degree of predictability that is similar to that of the existing transport networks.
The goal of MPLS-TP is to provide connection-oriented transport for packet and TDM services over optical networks leveraging the widely deployed MPLS technology. Operations, administration, and maintenance (OAM) and resiliency features are defined and implemented in MPLS-TP to ensure:
- Scalable operations
- High availability
- Performance monitoring
- Multidomain support
- Carrier-grade packet transport networks
MPLS-TP can be carried over the existing transport network infrastructure. MPLS-TP defines an MPLS profile targeted at transport applications and networks. This profile specifies the MPLS characteristics and extensions required to meet the transport requirements.
PTF_10GE_4, TP_10GE_4, and PTSA_GE equipment is mainly dedicated to forwarding Ethernet frames from customer networks, thus focusing only on AToM. The method used to transport such a frame is called pseudowire. Pseudowire is the emulation of a native service over the MPLS network. For managing PTF_10GE_4, TP_10GE_4, and PTSA_GE equipment, pseudowire and emulated (EVC-based) service are in a one-to-one relationship. Pseudowire does not provide bundling of additional EVCs. As shown in Figure 4-3, pseudowires and emulated services are represented by only one service or FDFr.
For descriptions of MPLS-TP provisioning and inventory interfaces, see the following sections:
4.1.8 MPLS-TP Tunnel
The MPLS-TP entity is characterized as follows:
- Has two endpoints.
- Has one or two bidirectional Label Switched Path (LSP) pairs between the endpoints. If there are two pairs, then one is the working path and the second is the protected path.
- The bidirectional LSPs in a pair are congruent. Bidirectional LSPs follow the same path in both directions.
- The tunnel can be configured with bandwidth. However, unlike MPLS-TE, there is no bandwidth reservation or preemption on the NE. Use the show command to view the configured bandwidth. Any bandwidth reservation must be handled within the NMS.
- Bidirectional Forwarding Detection (BFD) can be configured to monitor any of the bidirectional LSP pairs.
- MPLS-TP tunnel is used to carry pseudowires. Pseudowires or PW segments are explicitly configured to use a particular MPLS-TP tunnel using a given PW-CLASS configuration.
Figure 4-4 shows a typical MPLS-TP Tunnel.
For descriptions of MPLS-TP Tunnel provisioning and inventory interfaces, see the following sections:
4.1.9 MPLS-TP LSP
The LSP circuit provides the TP tunnel circuit with the path used for routing traffic. It also provides the distribution of labels along the defined route. Both TP tunnels and LSP subnetwork connections (SNCs) have the following attributes in common:
The information that discriminates the LSP from the TP tunnel is the Unique ID number, which serves also to distinguish one LSP from another in the case of a protected TP tunnel. Before you create the second LSP in a protected TP tunnel, you must wait until the TP tunnel and the first LSP are discovered. This is necessary in order to exclude the links used by the first LSP.
For descriptions of MPLS-TP LSP provisioning and inventory interfaces, see the following sections:
4.1.10 Pseudowire
A pseudowire (PW) is an emulation of a Layer 2 point-to-point, connection-oriented service over a packet-switching network (PSN). Pseudowire is the technique used to transport these types of frames. It is the emulation of a native service over the MPLS network.
LDP, MPLS-TE, and MPLS-TP are the basement for the pseudowire technology used to transport any kind of payload over a structured network (AToM). Currently, MPLS-TP has only one client network layer, which is pseudowire. The only way to route traffic into an MPLS-TP tunnel is to configure it as the preferred path of a pseudowire.
Each pseudowire can carry only one EVC service and is represented and exported directly by one FDFr. From the Network Circuit Provisioning (NCP) level, the pseudowire is represented by only one service.
For descriptions of pseudowire provisioning and inventory interfaces, see the following sections:
4.1.11 Pseudowire Flow Domain Fragment
An EVC-based pseudowire with an attachment circuit (AC) type of VLAN-based or port-based is modeled as an FDFr. In this model, an EVC containing the pseudowire and an FDFr on top the EVC containing the EVC do not exist; only an FDFr exists.
Ethernet FPs are represented by CTPs and the naming rule depends on the properties of the MFD that connects it.
The following table lists the MFD types and the corresponding value.
For descriptions of PW FDFr provisioning and inventory interfaces, see the following sections:
4.2 Interface Managers
In Prime Optical 9.3, the following new interface managers are introduced to support the new APIs:
The following table lists the new APIs and the corresponding interface manager.
|
|
|
|
|
|---|---|---|---|
4.3 Entity Characteristics
This section describes the following characteristics for the entities managed by the GateWay/CORBA interface:
4.3.1 Entity Naming
The following table lists the naming hierarchy for the entities managed by the GateWay/CORBA interface.
4.3.2 Entity Iterators
The NMS uses iterators to retrieve large amounts of data. Iterators provide a mechanism for retrieving data in batches. The NMS specifies the ideal size of a batch. When the NMS requests a list of objects, it specifies the maximum number of objects it can handle in the first reply. The number sent by the EMS can be less than this number.
The EMS gets a snapshot of the current objects to be returned. The response contains a list with the specified number of objects and a reference to an iterator. The NMS uses this iterator to access other objects in the snapshot.
The how_many parameter determines the maximum number of response entries in the list output parameter.
The iteratorReference parameter provides access to the remaining objects, if any.
- If the list contains the complete set of ObjectName objects, then the iteratorReference is a reference to a CORBA::Object::_nil object.
- If there are more objects, the list output parameter contains the first batch of objects known to the EMS and the iteratorReference parameter provides access to the other objects.
- If you specify 0 in the how_many parameter, no objects are returned in the list and all objects must be retrieved from the iteratorReference parameter.
The element management layer (EML) can return fewer objects than specified in the how_many value under either of the following conditions:
- Fewer objects than the number specified in the how_many value actually exist.
- The EML determines that the how_many value exceeds the server's stated performance restrictions.
For example, the EML can have 100 objects to return, the network management layer (NML) may request 50 through the how_many parameter and the EML may return 20 along with an iteratorReference.
The NMS uses the iteratorReference parameter to request further batches. This reference can be used to query how many objects can be returned by the getLength method. The NMS can subsequently start retrieving or removing the iterator. If all objects are specified in the list, it is a reference to a CORBA::Object::_nil object.
Each entry is returned only once, so you must use the next_n method to retrieve the additional entries in the selected set.
The EML may not get the total number of elements returned by the iterator in the following instances:
- The EML has to fetch all of the data that has been requested and then count the number of elements. This may not produce the desired results.
- The EML may be able to get a count of the number of elements, but due to concurrent modifications, the actual number may vary over the time of the iteration.
The interface client can determine when all data has been collected by repeatedly fetching chunks of data until the iterator indicates that no further data remains. If the EMS is unable to determine the length, the getLength method returns the EXCPT_CAPACITY_EXCEEDED exception.
The EXCPT_TOO_MANY_OPEN_ITERATORS exception is returned if the EMS has reached an implementation limitation. An EMS supports a minimum of 10 iterators.
In this interface, the iterators have the following operations:
- getLength—Returns the total number of elements in the iterator. For example, if the EML has 100 objects and 10 are returned in the initial list, the getLength method should return 90, regardless of how many objects are or are not retrieved using the next_n method. The EXCPT_CAPACITY_EXCEEDED exception is returned if the EMS cannot efficiently provide a value for the number of elements on this occasion. The next_n method may still be performed.
- next_n—Returns no more than the “n” entries, but it may return fewer. Returns true if there are more entries to be returned. If there are fewer entries, it returns false, removes the iterator, and releases the memory being used. The EML may choose to limit the number of objects returned in a single request to prevent performance issues.
- destroy—If you decide not to access the remaining objects, you can invoke the destroy operation to delete the iterator object.
4.3.3 Entity Notifications
For all entities introduced up to and including MTNM version 2.0, the ObjectType (filterable) field within the notification structure was used to identify the object types. As backward compatibility has to be supported, you cannot extend the MTNM version 2.0 enumeration type ObjectType_T to include new object types.
In MTNM version 3.0 and onward, the objectType OT_AID (alarm identifier) is used as an escape value to represent new objects being managed, in conjunction with the new filterable field objectTypeQualifier that contains the real object type:
- OT_FLOW_DOMAIN—Flow Domain.
- OT_FLOW_DOMAIN_FRAGMENT—Flow Domain Fragment.
- OT_MATRIX_FLOW_DOMAIN—Matrix Flow Domain.
- OT_TRANSMISSION_DESCRIPTOR—Transmission Descriptor.
- OT_TRAFFIC_CONDITIONING_PROFILE—Traffic Conditioning Profile.
- OT_FLOATING_TERMINATION_POINT—LAG FTP.
- OT_PW_CLASS—Pseudowire class.
- OT_BFD_TEMPLATE—BFD Template.
- (empty string) indicates a proper OT_AID alarm identifier (used to represent the EMS object types that are not modeled, but can emit alarms).
4.4 Supported Provisioning Interfaces
The following table lists the provisioning interfaces supported in Prime Optical 9.3.
|
|
|
|---|---|
|
|
|
|
|
|
BFD Template, Node ID, and Label Range Provisioning Interface |
|
|
|
|
4.5 EVC Provisioning Interfaces
This section describes the following EVC provisioning interfaces:
- CPTP Provisioning Interfaces
- MFD Provisioning Interfaces
- Flow Domain Provisioning Interfaces
- EVC FDFr Provisioning Interfaces
- Link Aggregation Provisioning Interfaces
- Traffic Conditioning Profile Provisioning Interfaces
4.5.1 CPTP Provisioning Interfaces
4.5.1.1 provisionEquipment
This interface allows you to provision CPTPs. You can provision PTPs by specifying the ConnectionlessPort additional parameter. If a PTP has been recently characterized as connectionless, you cannot set the PortTpRoleState parameter with this interface because the CPTP state machine does not allow it.
4.5.1.2 unprovisionEquipment
This interface allows you to unprovision a PTP. If the admin state is inactive and all other conditions are met, unprovisioning is successful and the corresponding CPTP entity is deleted.
4.5.1.3 setAdditionalInfo
This interface allows you to specify the following additional parameters:
The PortTpRoleState parameter can be modified only if the CPTP state machine allows it.
The following table describes the parameters.
4.5.1.4 ConfigConnLessInfos
This interface allows you to automatically populate all FDs, MFDs, and CPTPs based on the current EMS inventory.
1. Creates an FD for each network partition.
2. Within each FD, creates an MFD for each ME already assigned to the FD.
3. Within each MFD, creates a CPTP for each Ethernet port and for each port channel (link aggregation). Each CPTP is automatically assigned to the corresponding MFD and assumes the fdEdge CPTP role state. Port channel FTPs are also populated.
During discovery or provisioning, this interface allows you to manage the FDFr that represents pseudowires and EVCs. If this method is called, only the new MEs that were previously unavailable in the EMS are analyzed and contribute to the connectionless EMS information. In an administrative organization, all the APIs that allow you to create, delete, modify, assign, and unassign CPTPs, MFDs, and FDs are available.
4.5.1.5 DeleteAllConnLessInfos
This interface allows you to delete all the FDs, MFDs, and CPTPs currently stored in the EMS. You may use this interface at any time to reorganize the network from scratch.
4.5.2 MFD Provisioning Interfaces
4.5.2.1 createMFD
This interface enables the NMS to request the EMS to create an MFD with the parameters specified in the method. The NMS must specify the CPTPs to be associated with the MFD that will be created.
- MFDCreateData_T createData—Describes the structure of the MFD to be created.
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
- MatrixFlowDomain_T theMFD—The newly created MFD. The EMS is responsible for guaranteeing MFD name uniqueness. The NMS can specify the name using createData.
- string errorReason—Specifies the creation errors, if any.
The name of each MFD must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="ManagedElementName"
name="MatrixFlowDomain"; value= "MatrixFlowDomainName"
In Prime Optical, each ME name is unique irrespective of which network partition or network access domain it belongs to. In this data structure, networkAccessDomain separates an ME from another that has the same name but belongs to a different network access domain.
The following describes how the system requests to create an MFD:
1. The NMS sends the request to the EMS to create an MFD with the provided parameters.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an MFD object with the same user label exists, a User Label In Use exception is raised.
c. If one of the specified TPs is unknown to the EMS, an Entity Not Found exception is raised.
d. If at least one of the MFD parameters could not be set, an Unable To Comply exception is raised.
e. If any of the specified TPs is already in use by another MFD, an Object In Use exception is raised.
3. If the request is valid, the EMS:
b. Assigns the requested CPTPs to the MFD.
c. Replies with a success indication.
d. Sends object creation notifications to the notification service.
4.5.2.2 assignCPTPsToMFD
This interface enables the NMS to request the EMS to assign one or more CPTPs to an MFD.
- globaldefs::NamingAttributes_T mfdName—The MFD name to be modified.
- globaldefs::NamingAttributesList_T tpNames—The CPTP names to be assigned to the MFD. If the list is empty or if all the CPTPs are already assigned to the MFD, no operation is performed on the EMS and the method returns "success."
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
The following describes how the system requests to assign CPTPs to an MFD:
1. The NMS sends a request to the EMS to assign a list of CPTPs to an existing MFD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified MFD is unknown to the EMS, an Entity Not Found exception is raised.
c. If the specified MFD is fixed, an Unable To Comply exception is raised.
d. If one or more of the specified CPTPs is unknown to the EMS, an Entity Not Found exception is raised.
e. If one or more of the specified CPTPs is not a potential CPTP for this MFD (is not in the unassigned CPTP PortTPRoleState or is not in the same equipment or on the same rack with backplane connectivity), an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
a. Assigns the specified CPTPs to the MFD. The CPTP PortTPRoleState attribute is set to assigned.
b. Replies with a success indication.
c. Sends an attribute value change notification to the notification service (using a notification of the MFD assignedCPTPs attribute). The notification includes the complete list of CPTP names that are assigned to the MFD.
4.5.2.3 unassignCPTPsFromMFD
This interface enables the NMS to request the EMS to unassign one or more CPTPs from an MFD.
- globaldefs::NamingAttributes_T mfdName—The MFD name to be modified.
- globaldefs::NamingAttributesList_T tpNames—The CPTP names to be unassigned from the MFD. If no CPTP has been specified, the method returns "success."
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
The following describes how the system requests to unassign CPTPs from an MFD:
1. The NMS sends a request to the EMS to unassign a list of CPTPs from an existing MFD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified MFD is unknown to the EMS, an Entity Not Found exception is raised.
c. If the specified MFD is fixed, an Unable To Comply exception is raised.
d. If one or more of the specified CPTPs is unknown to the EMS, an Entity Not Found exception is raised.
e. If one or more of the specified CPTPs is in the unassigned PortTPRoleState, a Not In Valid State exception is raised.
f. If one or more of the specified CPTPs is used by an FDFr, an Object In Use exception is raised.
g. If one or more of the specified CPTPs is not assigned to the specified MFD, an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
a. Unassigns the specified CPTPs from the MFD. The PortTPRoleState attribute of the CPTPs is set to unassigned. If any of the CPTPs could not be unassigned, no CPTP is unassigned and an Unable To Comply exception is raised.
b. Replies with a success indication.
c. Sends the appropriate notifications to the notification service.
4.5.2.4 deleteMFD
This interface enables the NMS to request the deletion of an MFD from the EMS.
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
The following describes how the system requests to delete an MFD:
1. The NMS sends the request to the EMS to delete an MFD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified MFD object is unknown to the EMS, an Entity Not Found exception is raised.
c. The MFD to be deleted must not be associated with an FD. If the MFD is still associated, an Object In Use exception is raised.
d. The MFD to be deleted must not be fixed. If the MFD is fixed, an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
b. Releases all assigned TPs from the MFD.
c. Replies with a success indication.
d. Sends an object deletion notification to the notification service.
4.5.2.5 modifyMFD
This interface enables the NMS to request a modification of an MFD.
- globaldefs::NamingAttributes_T mfdName—The MFD name to be modified.
- MFDModifyData_T mfdModifyData—Structure describing how the MFD will be modified. Best effort is not supported. If modifying one parameter fails, an exception is raised.
- string failedAttributes—The list of attributes that could not be modified.
- MatrixFlowDomain_T newMFD—The modified MFD.
- string errorReason—If a best-effort parameter could not be set, the EMS provides the fault reason.
The read and write attributes required to modify an MFD on the EMS are bundled in the MFDModifyData structure, which the NMS passes to the EMS.
The following describes the MFDModifyData structure attributes:
- userLabel—Can be specified by the NMS or it can be empty.
- forceUniqueness—Specifies whether userLabel uniqueness is required for EMS MFDs. If the userLabel is unique and is already in use, the operation fails.
- owner—Can be specified by the NMS or it can be empty.
- networkAccessDomain—The network access domain to which the FD is assigned.
- transmissionParameters::LayeredParameterList_T transmissionParams—A list of modified connectionless parameters. As an input only, the list of parameters to be changed, removed, or added is provided. If an entry must be removed, a hyphen (-) is specified as the value. When the method is returned, this attribute contains the list of parameters that could not be applied.
- globaldefs::NVSList_T additionalModificationInfo—Additional modification information can be specified by the NMS. When the method is returned, this attribute contains the parameters that could not be applied.
The following describes how the system requests to modify an MFD:
1. The NMS sends a request to the EMS to modify an MFD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified MFD is unknown to the EMS, an Entity Not Found exception is raised.
c. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an MFD object with the same user label exists, a User Label In Use exception is raised.
d. If the EMS cannot satisfy any attribute that must be modified, an Unable To Comply exception is raised.
e. If the MFD already has the required information, the EMS replies with a success indication, but no notification is generated.
a. If the MFD has all the required information, the EMS does not send any notifications to the notification service.
b. If the MFD does not have the required information, the EMS modifies the MFD attributes as requested.
c. The EMS replies with a success indication.
d. If the EMS makes a change, the appropriate notification is sent to the notification service.
4.5.3 Flow Domain Provisioning Interfaces
4.5.3.1 createFlowDomain
This interface enables the NMS to request the EMS to create an FD with the parameters specified in the method. The NMS can specify MFDs or fdEdge CPTPs to be associated with the created FD.
- FDCreateData_T createData—Describes the FD structure to be created.
- globaldefs::NamingAttributesList_T assignedCPTPs—Identifies the list of assigned CPTPs to be associated to the FD as fdEdge CPTPs. This list can be empty. Associating CPTPs to the FD is done on a best-effort basis. When the method is returned, the list contains the names of the CPTPs that could not be associated with the FD.
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
- FlowDomain_T theFD—The newly created FD. The EMS is responsible for guaranteeing the uniqueness of the FD name. The NMS specifies the name in the createData parameter.
- string errorReason—The EMS provides the fault reason if a best-effort parameter could not be set or if a CPTP could not be associated with the FD.
The name of each FD must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="FlowDomain";value=" FlowDomainName"
In Prime Optical, each ME name is unique irrespective of which network partition or network access domain it belongs to. In this data structure, networkAccessDomain separates an ME from another that has the same name but belongs to a different network access domain.
The following describes how the system requests to create an FD:
1. The NMS sends the request to the EMS to create an FD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If an FD object with the name specified already exists, an Object In Use exception is raised.
c. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an FD object with the same user label already exists, a User Label In Use exception is raised.
d. If one of the specified resources (MFDs or CPTPs) does not exist, an Entity Not Found exception is raised.
e. If any of the MFDs to be associated is already associated to another FD, an Object In Use exception is raised.
f. If any of the MFDs to be associated could not be associated to the FD, no MFD is associated and an Unable To Comply exception is raised.
g. If a CPTP is not already assigned to one of the provided MFDs, an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
a. Creates the FD as requested.
b. Associates the requested CPTPs to the new FD (the PortTPRoleState attribute of the CPTPs is set to fdEdge). All names of the CPTPs that could not be associated are returned in the reply.
c. Replies with a success indication.
d. Sends an FD object creation notification to the notification service.
Note TPData (tpsToModify) structure contains TP data that can be set by the NMS; for example, the transmission parameters that must be applied to the TP. Only a subset of the parameters is specified in the list and only these parameters should be applied in the NE. If the list is empty, nothing will be done. To remove a parameter from the list, use a hyphen (-) in the value part of the structure.
- The tpsToModify parameter is not supported.
- The assignedCPTPs parameter is not supported. All CPTPs that are currently assigned to the MFDs specified in the createData attribute are automatically moved to fdEdge role state after the MFD is assigned to the FD. To explicitly assign CPTPs to an FD, use the assignCPTPsToMFD interface.
4.5.3.2 deleteFlowDomain
This interface enables the NMS to request the EMS to delete an FD.
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
This interface allows an NMS to delete an existing FD. The EMS verifies that no FDFr exists within the FD. The operation disassociates the fdEdge CPTPs and MFDs, and deletes the FD.
The following describes how the system requests to delete an FD:
1. The NMS sends the request to the EMS to delete an FD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the FD object is unknown to the EMS, an Entity Not Found exception is raised.
c. If any FDFr is used in the FD, an Object In Use exception is raised.
d. If any of the MFDs cannot be disassociated from the specified FD, no MFD is disassociated and an Unable To Comply exception is raised.
e. If any fdEdge CPTPs cannot be disassociated from the FD (the PortTPRoleState attribute of the CPTPs was set to assigned), no fdEdge CPTPs are disassociated and an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
b. Replies with a success indication.
c. Sends an FD object deletion notification to the notification service.
4. If the request is successful:
a. The fdEdge CPTPs associated to the FD are disassociated (the PortTPRoleState attribute of the CPTPs is set to assigned).
4.5.3.3 modifyFlowDomain
This interface enables the NMS to request the EMS to modify an existing FD, as specified by the parameters in the method. The NMS can modify the user label, owner, network access domain, connectionless layered parameters, or additional information on an existing FD.
- NamingAttributes_T fdName—The FD name to be modified.
- FDModifyData_T fdModifyData—Describes how the FD should be modified. If the FD contains the required information, nothing is done on the EMS and the method returns "success."
- string failedAttributes—The list of attributes that could not be modified.
- FlowDomain_T modifiedFD—The modified FD.
- string errorReason—Specifies the reason for the fault, if any.
The following describes how the system requests to modify an FD:
1. The NMS sends the request to the EMS to modify an FD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified FD is unknown to the EMS, an Entity Not Found exception is raised.
c. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an FD object with the same user label exists, a User Label In Use exception is raised.
d. If the EMS cannot satisfy any attribute that must be modified, an Unable To Comply exception is raised.
a. If the FD already has all the required information, the EMS does not send any notifications to the notification service.
b. If the FD does not have the required information, the EMS modifies the FD attributes as requested.
4. The EMS replies with a success indication.
5. If the EMS makes a change, the appropriate notification is sent to the notification service.
4.5.3.4 associateMFDsWithFlowDomain
This interface enables the NMS to request the EMS to associate one or more MFDs with an FD.
- NamingAttributes_T fdName—The FD name to which the MFDs will be associated.
- NamingAttributesList_T mfdNames—The names of the MFDs to be associated with the FD. If the list is empty, nothing is done on the EMS and the method returns "success."
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
The following describes how the system requests to associate additional MFDs to an existing FD:
1. The NMS sends the request to the EMS to associate additional MFDs to an existing FD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified FD is unknown to the EMS, an Entity Not Found exception is raised.
c. If one or more of the specified MFDs is unknown to the EMS, an Entity Not Found exception is raised.
d. If one or more of the specified MFDs are already associated to another FD, an Object In Use exception is raised.
e. If any of the MFDs could not be associated, no MFD is associated and an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
a. Associates the specified MFDs to the FD.
b. Verifies the server layer connectivity between the associated MFDs. The FD Connectivity State attribute is modified accordingly (fully connected, not fully connected, or unknown).
c. Replies with a success indication.
d. Sends an attribute value change notification to the notification service using the MatrixFlowDomain attribute of the FD. The notification includes the complete list of MFD names that are associated to the FD.
4. If the FD Connectivity State attribute is modified, the EMS sends a state change notification to the notification service.
4.5.3.5 deAssociateMFDsFromFlowDomain
This interface enables the NMS to disassociate one or more MFDs from an existing FD. This operation also disassociates the fdEdge CPTPs that are associated to the MFDs to be disassociated.
- NamingAttributes_T fdName—The FD name to be modified.
- NamingAttributesList_T mfdNames—The names of the MFDs to be disassociated from the FD. If the list is empty, nothing is done on the EMS and the method returns "success."
- TPDataList_T tpsToModify:
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
The EMS must validate the data provided by the NMS and disassociate the requested MFDs from the specified FD. If the EMS cannot disassociate the specified MFDs, an appropriate exception is raised. Best effort is not supported. The operation also disassociates the fdEdge CPTPs that are associated to the MFDs to be disassociated. After the disassociation, the EMS verifies the server layer connectivity between the associated MFDs using the FD Connectivity State attribute.
The following describes how the system requests to disassociate MFDs from an existing FD:
1. The NMS sends the request to the EMS to disassociate MFDs from an existing FD.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified FD is unknown to the EMS, an Entity Not Found exception is raised.
c. If one or more of the specified MFDs were not previously associated to the FD, an Unable To Comply exception is raised.
d. If one or more of the specified MFDs is carrying traffic, an Object In Use exception is raised.
e. If any fdEdge CPTPs cannot be disassociated from the MFDs that are being disassociated (the PortTPRoleState attribute of the CPTPs is set to assigned), no fdEdge CPTPs are disassociated and an Unable To Comply exception is raised.
f. If any of the MFDs could not be disassociated, no MFD is disassociated and an Unable To Comply exception is raised.
3. If the request is valid, the EMS:
a. Disassociates the specified MFDs from the FD.
b. Replies with a success indication.
c. Sends an attribute value change notification to the notification service using the MatrixFlowDomain attribute of the FD. The notification includes the complete list of MFD names that are associated to the FD.
d. Verifies the server layer connectivity between the associated MFDs. The FD Connectivity State attribute is modified accordingly (fully connected, not fully connected, or unknown).
e. If the FD Connectivity State attribute is modified, the EMS sends a state change notification to the notification service.
4. If the request is successful:
a. The requested MFDs are disassociated from the FD.
b. The corresponding fdEdge CPTPs are also disassociated from the FD.
5. If the request fails, there is no change in the system or the MFD association to the FD.
4.5.4 EVC FDFr Provisioning Interfaces
4.5.4.1 createAndActivateFDFr
This interface requests the EMS to create and activate an FDFr representing an EVC using the parameters specified in the method. This operation allows you to create and activate the following EVCs at the LR_EVC (168) layer rate:
- Ethernet Private Line
- Ethernet Virtual Private Line
- Ethernet Private LAN
- Ethernet Virtual Private LAN
Figure 4-5 shows the point-to-point EFP.
Figure 4-6 shows the multipoint-to-multipoint EFP.
Figure 4-6 Multipoint-to-Multipoint EFP
For example, if the network can automatically route, no internal CPTPs have to be specified. To configure EFP, you must consider the following:
– aEnd[0] (external source) EFP
– zEnd[0] (external destination) EFP
– aEnd[0] (external source) EFP
– aEnd[1] (internal source) EFP
– zEnd[0] (external destination) EFP
If aEnd and zEnd are in different MEs, the EMS performs an Apply-All EFP configuration of the external and internal source EFPs and then overrides the external destination EFP with the one you provide.
The network creates the internal intermediate EFPs. The aEnd and zEnd parameters contain the associated CTPs; for example:
The EFP parameters must be specified using the tpsToModify parameter. The LR_EVC (168) and the layered parameters are reported below:
For Ethernet Private Line EVCs, the number of drops must always be two. For Ethernet Private LAN EVCs, the number of drops must be two at creation, but more drops can be added using the
modifyFDFr() API. For Private EVCs (Ethernet Private Line or Ethernet Private LAN), at least one of the drops must have the "/eth=default" tagging. To include MEs in EVC routing, you must specify the MEs in the tpsToModify parameter.
The following describes how the system requests to create and activate an FDFr:
1. The NMS sends a request to the EMS to create and activate an FDFr.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If one of the referenced CPTP objects is unknown to the EMS, an Entity Not Found exception is raised.
c. If the specified CPTPs are not associated with the referenced FD, a TP Invalid Endpoint exception is raised.
d. If an FDFr with the same properties as specified in the NMS request already exists, the EMS reuses that FDFr.
e. If any of the specified Edge CPTPs do not have the fdEdge role, a Not In Valid State exception is raised.
f. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an FDFr object with the same user label exists already, a User Label In Use exception is raised.
g. If the FDFr being created will have fewer than two edge FPs, an Unable To Comply exception is raised.
3. The transmission parameters for the involved CPTPs and FPs are sent to the network by the EMS, which activated the MFDFrs as appropriate, based on the automatic route taken by the network. If any entity or parameter cannot be provisioned, a corresponding exception is raised (failed TP list is not managed).
4. The EMS initiates the activation of the FDFr, which involves establishing the MFDFrs at the MEs.
5. If all of the MFDFrs comprising the FDFr have been established, the EMS sets the FDFr state to active.
6. If one or more of the MFDFrs comprising the FDFr are not established, the EMS sets the FDFr state to partial.
7. The EMS replies with a success indication.
For descriptions of the input parameters, see createAndActivateFDFr.
Manual routing is not required for EVCs. Nodes or links can be included or excluded to drive the automatic routing performed by the network.
For pseudowires, the following layered parameters associated to the new LR_EVC layer rate change.
|
|
|
|
|---|---|---|
The following layered parameters that refer to the EFP configuration are specified within the tpsToModify parameter that is associated to the LR_EVC layer rate.
Note Pseudowire class, VC ID, static labels, and protection parameters do not apply to EVC drops.
The following table lists the mandatory parameters based on tagging type.
|
|
|
|
|
|
|---|---|---|---|---|
The network automatically assigns the SID to the FDFr at the time of creation. This SID is returned in the name. For pseudowires, see the following example:
When the creation API is executed, the service is not discovered for all parameters. The API returns a dummy object based on the input parameters. The actual objects are retrieved through the standard inventory APIs.
4.5.4.2 deactivateAndDeleteFDFr
This interface enables the NMS to deactivate and delete an FDFr that represents an EVC from an FD. For descriptions of the input parameters, see deactivateAndDeleteFDFr.
The EVC name is specified as <EVC native name>:SID=nn:LR=EVC.
In this example, LR=EVC stands for Layer Rate = EVC. This is introduced because the API does not expect an LR to be specified.
4.5.4.3 modifyFDFr
This interface enables the EMS to modify an existing FDFr representing an EVC as specified by the parameters in the method.
The EVC name is specified as <EVC native name>:SID=nn:LR=EVC.
In this example, LR=EVC stands for Layer Rate = EVC. This is introduced because the API does not expect an LR to be specified. For descriptions of the input parameters, see modifyFDFr.
The difference between pseudowires and EVCs is that for Ethernet Private LANs, you can add or remove drops after you create the FDFr. You must add or delete only one drop at a time. To achieve this, you must use the following structure:
To add or remove a new drop, you must specify the tpNamesToRemove or zEndTPNames parameters.
Note In multipoint services, all endpoints are considered as aEnd point drops.
The administrative state change applies to the entire service only if the tpsToModify or zEndTPNames parameters are not specified. If they are specified, the administrative state change applies only to those services specified in the tpsToModify parameter and to the new drop specified.
To change the administrative state, you must set the changeAdminState parameter to true in the additionalModificationInfo parameter.
The additionalModificationInfo parameter contains the following additional parameter.
|
|
|
|
|---|---|---|
Indicates whether or not the admin state is changed based on the new value specified in the administrativeState field. |
To add a new drop to a multipoint EVC, you must specify the new CTPs in the zEndTPNames parameter and the EFP parameters in the tpsToModify parameter.
For creating and modifying an EVC, consider the following:
- The new drop (zEnd[0]) is in an ME which is already part of the EVC. In this case, you must not specify the EFP configuration for the internal-intermediate drops as being already present. You need to only specify the new drop in zEnd[0] and its associated EFP parameters in the tpsToModify parameter.
- The new drop (zEnd[0]) is in an ME which currently does not belong to the EVC. In this case, you must specify the EFP configuration for both the external drop to be added (zEnd[0]) and the internal-intermediate drop (zEnd[1]) in the same ME, which is used for all the intermediate drops in the route taken by the network.
If the new drop is in an ME which currently does not belong to the EVC, the SID associated to the EVC can change. If the current SID value associated to the EVC is not available in the ME of the new drop, the network automatically picks up the first available SID shared by the current ME belonging to the EVC and the new drop ME. The new SID value is returned by the API in the result.
Note The source and new endpoint EFP configuration must be the same.
The addition or deletion of drops and the modification of the administrative state are mutually exclusive. For example, if you want to add a drop and remove another one, you must perform the modifyFDFr operation twice with the corresponding parameters.
Associate the QoS parameters to a given EVC by specifying the following layered parameters (associated to the LR_EVC layer rate) in the transmission parameters:
|
|
|
|
|---|---|---|
Select the splitHorizontal parameter to a given EFP by specifying the following layered parameter (associated to the LR_EVC layer rate) in the transmission parameters:
|
|
|
|
|---|---|---|
Indicates whether or not the splitHorizontal EFP parameters of a TP are enabled. Valid values are: |
4.5.5 Link Aggregation Provisioning Interfaces
4.5.5.1 createFTP
This interface enables the NMS to create an FTP. A LAN port, which usually can be an edge CPTP, cannot be an edge CPTP if it is a member of a LAG. The LAG FTP is the edge CPTP.
- FTPCreateData_T createData—Describes the FTP structure to be created.
- TPDataList_T tpsToModify—List of TPs and parameters to be applied and updated to provide the resulting parameters. The transmission parameters are applied on a best-effort basis and the resulting values of the transmission parameters are provided in the updated tpsToModify parameter. If the parameter is not best effort, the entire operation is rejected and the appropriate exception is returned. The tpsToModify parameter can be used by the NMS to determine the number of server layer CTPs to create for the specified FTP. An empty list signifies that the number of server layer CTPs is determined by the EMS.
- TerminationPoint_T theFTP—The new FTP. The EMS is responsible for guaranteeing FTP name uniqueness. The name is specified by the NMS in the createData parameter.
- string errorReason—Specifies the errors during creation, if any.
The following table describes the mandatory LACP protocol attributes at the FTP Level.
|
|
|
|
|---|---|---|
Ingress policy map name. Valid value is an empty string (""). In Prime Optical 9.3, this attribute is not supported. You must specify this attribute and set it to an empty string. For more information about policy maps, see Traffic Conditioning Profile Provisioning Interfaces. |
||
Ingress table map name. Valid value is an empty string (""). In Prime Optical 9.3, this attribute is not supported. You must specify this attribute and set it to an empty string. For more information about table maps, see Traffic Conditioning Profile Provisioning Interfaces. |
||
Ingress table map config name. Valid value is an empty string (""). In Prime Optical 9.3, this attribute is not supported. You must specify this attribute and set it to an empty string. |
||
Egress policy map name. Valid value is an empty string (""). In Prime Optical 9.3, this attribute is not supported. You must specify this attribute and set it to an empty string. For more information about policy maps, see Traffic Conditioning Profile Provisioning Interfaces. |
||
Enables LACP if the value is true. The value is not applied if the command does not include aggregated ports. |
||
Minimum bundle number. If portLACP is false, this attribute must be set to 1. Valid values are from 1 to 8. |
||
Maximum bundle number. If portLACP is false, this attribute must be set to 8. Valid values are from 1 to 8. |
If LACP is not enabled at the FTP level, the transmissionParams attribute is left empty. If LACP is enabled at the FTP level, the transmissionParams attribute is used to communicate with LACP parameters:
|
|
|
|
|---|---|---|
The following describes how the system requests to create an FTP.:
1. The EMS creates the requested FTP consistently with its implementation and the NMS specifications.
2. If the EMS cannot create the FTP as specified, an appropriate exception is raised.
3. The NMS specifies the FTP by choosing a location within the NE.
4. After the EMS validates the input data, and if it can satisfy the input constraints, the EMS proceeds with implementing the FTP and returns the name of the new FTP and all of the attributes to the NMS.
5. If the EMS fails to validate the input, it raises an appropriate exception.
6. If transmission parameters are specified for the contained CTPs that are created, the EMS applies the transmission parameters after the FTP creation.
7. Alarm reporting on the FTPs and contained CTPs might be enabled by the EMS using the alarm reporting transmission parameter.
8. An object creation notification is sent to notify the NMS about the existence of the new FTP.
Note If virtual concatenation applies, no notification is sent to the contained CTPs.
4.5.5.2 deleteFTP
This interface enables the NMS to request the deletion of an FTP from the EMS. The service may be used to delete CPTP FTPs.
- NamingAttributes_T ftpName—The FTP LAG name to be deleted. Because an Ethernet LAG port can aggregate client Ethernet ports of different ME cards, the corresponding FTP is logically positioned on the unique shelf of the ME itself:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="ManagedElementName"
name="FTP";value="/rack=1/shelf=1/port=nn"
– in—The list of TPs with associated parameters to be applied.
– out—The list of TPs with associated applied parameters.
4.5.5.3 setTPData
This interface allows the NMS to set parameters on a specified TP.
The following table lists the transmission parameters.
|
|
|
|
|---|---|---|
Ingress policy map name. An empty string ("") is an invalid value. The None value removes the policy reference from the FTP. For more information about policy maps, see Traffic Conditioning Profile Provisioning Interfaces. |
||
Ingress table map name. An empty string ("") is an invalid value. The None value removes the policy reference from the FTP. For more information about table maps, see Traffic Conditioning Profile Provisioning Interfaces. |
||
Ingress table map configuration name. Valid values are: The None value resets the current setting. An empty string ("") is an invalid value. |
||
Egress policy map name. An empty string ("") is an invalid value. The None value removes the policy reference from the FTP. For more information about policy maps, see Traffic Conditioning Profile Provisioning Interfaces. |
4.5.6 Traffic Conditioning Profile Provisioning Interfaces
The Traffic Conditioning (TC) function is a transport processing function. It does the following:
- Accepts the characteristic information about the layer network at input.
- Classifies the traffic units according to configured rules.
- Meters each traffic unit to determine eligibility.
- Polices nonconforming traffic units.
- Presents the remaining traffic units at output.
The TC function is modeled by a TC profile that contains the bandwidth parameters that police the traffic at the ingress and egress of a connectionless layer network.
The API that handles Traffic Conditioning (TC) Profiles uses the TCProfile_T and TCProfileCreateData_T data structures.
Prime Optical 9.3 models and groups CTP QoS parameters into four different classes of objects:
The QoS parameters are stored in the Prime Optical database, which you can access from the Prime Optical user interface and the NMS through the GateWay/CORBA API. The EMS models each of the objects with a TC profile. The NMS can use theGateWay/CORBA API to create, fetch, modify, and delete TC profiles in the repository.
The EMS enforces and guarantees the uniqueness of user labels within any given QoS class of objects (class maps), but not across different QoS classes of objects.
For any newly created TC profile, the EMS automatically assigns a name with the following space-separated concatenation:
<QoS object class>" "<user label>
As per TMF standards, the forceUniqueness parameter can be used to guarantee user label uniqueness across all types of TC profiles. In Prime Optical 9.3, the forceUniqueness parameter is not implemented.
The following table describes the usage of the TCProfile_T and TCProfileCreateData_T fields.
The additionalInfo and additionalCreationInfo fields contain a list of tuples with values specified as per the tables below. Each tuple consists a name-value pair. Tuples in the list can be in any order, unless otherwise specified. Additional parameter names are separated by a single space.
The following table describes the additi onalInfo and additionalCreationInfo parameters for the class map.
The following table describes the additionalInfo and additionalCreationInfo parameters for action.
The following table describes the additionalInfo and additionalCreationInfo parameters for policy maps.
“action,” “class-map,” and “policy-map” are optional. If one is provided, you can also repeat it. The respective values are the user labels of the action, class map, and policy map, and the values must be indicated.
The following table describes the additionalInfo and additionalCreationInfo parameters for table maps.
|
|
|
|
|---|---|---|
tcprofile is mandatory in additionalCreationInfo and must be omitted from additionalInfo. |
||
“qos-group,” “discard-class,” and “to” are optional. If one is provided, you can also repeat it.
4.5.6.1 createTCProfile
This interface is used to create a new TC profile on the server. TCProfileCreateData is passed as input, and the resulting TC profile is returned as a result or an exception is returned.
The following describes how the system requests to create a new TC profile:
1. The NMS sends a request to the EMS to create a TC profile. The NMS provides the TC profile name and a list of bandwidth parameters.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the maximum number of TC profiles in the EMS has already been reached and the TC profile cannot be created, a Capacity Exceeded exception is raised.
3. If the request is valid, the EMS creates the TC profile.
4. The EMS replies with a success indication.
If the request is successful, the NMS receives an indication of the success of the request.
If the request is not successful, the NMS receives an exception as an indication of the failure of the request.
4.5.6.2 deleteTCProfile
This interface deletes a TC profile on the server. This operation is idempotent. If the service is called with the name of a nonexistent TC profile, the operation succeeds.
4.5.6.3 modifyTCProfile
This interface modifies an existing TC profile as specified by the parameters in the method. A TC profile with the data to be changed is passed as input. The resulting TC profile is returned as a result.
4.6 MPLS-TP Provisioning Interfaces
This section describes the following MPLS-TP provisioning interfaces:
- MPLS-TP Tunnel Provisioning Interfaces
- MPLS-TP LSP Provisioning Interfaces
- MPLS-TP Protection (Provisioning)
- BFD Template, Node ID, and Label Range Provisioning Interface
4.6.1 MPLS-TP Tunnel Provisioning Interfaces
4.6.1.1 createAndActivateSNC
This interface allows you to create and activate a subnetwork connection for the TP tunnel using a single command. According to TMF standards, an SNC name is assigned by the EMS when it creates an SNC. However, if the NMS must control the SNC name, it can provide the name using the additionalInfo parameter sncName.
The layer rate that applies to TP tunnel circuits is LR_MPLS (165).
When you create an MPLS-TP tunnel, the routing is linked to the associated LSPs whenever the MPLS-TP tunnel is created with layer rate LR_MPLS_PATH.
- SNCCreateData createData—Describes the SNC structure to be created and activated.
- GradesOfImpact_T tolerableImpact—The maximum tolerable impact allowed.
- EMSFreedomLevel_T emsFreedomLevel—The maximum level of freedom allowed to the EMS to perform the creation and activation.
- TPDataList_T tpsToModify—A list of TPs and parameters that are applied and updated to provide the resulting parameters.
- SubnetworkConnection theSNC—The resulting SNC with the sncState and name set. The EMS selects the SNC names so that they are not reused for different SNCs.
- string errorReason—Specifies the creation and activation errors, if any.
name="EMS";value="Cisco Systems/PRIMEOPTICAL"
name="ManagedElement";value="M2-65-122"
name="PTP";value="/rack=1/shelf=1/slot=2/ppm_holder=1/port=1"
name="CTP";value="tunnelNum=44"
The following table describes the additional parameters that you can specify.
4.6.1.2 deactivateAndDeleteSNC
This interface allows you to deactivate and then delete the SNC, which represents a given MPLS-TP tunnel in one operation. This operation implies the automatic deletion of the associated LSP SNCs. Prime Optical removes resources allocated to this SNC from each node. This is an asynchronous operation. Successful completion of this operation guarantees only the delivery of deletion request to Prime Optical. The NMS must wait for an OBJECT_DELETION event for this SNC.
Because TP tunnel names are not guaranteed to be unique in the network, you must provide the TP tunnel name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66.
The TKEY represents the TP tunnel key and is returned as an additional parameter whenever the corresponding SNC is retrieved. This key is composed in the following format:
<source Node ID>:<source Tunnel ID>:<dest Node ID>:<dest Tunnel ID>
The TKEY represents an invariant component for every TP tunnel. A prevention check is done in case any pseudowire is configured upon the given MPLS-TP tunnel. If any pseudowire is configured, an exception is generated and the pseudowire is removed in advance.
4.6.1.3 modifySNC
This interface allows the modification of the circuit user label for the given TP tunnel SNC. Because TP tunnel names are not guaranteed to be unique in the network, you must provide the TP tunnel name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66.
The TKEY represents the TP tunnel key and is returned as an additional parameter whenever the corresponding SNC is retrieved. This key is composed in the following format:
<source Node ID>:<source Tunnel ID>:<dest Node ID>:<dest Tunnel ID>
The TKEY represents an invariant component for every TP tunnel.
4.6.2 MPLS-TP LSP Provisioning Interfaces
4.6.2.1 createAndActivateSNC
This interface allows you to create and activate a subnetwork connection (an LSP) in a single command. As per TMF standards, an SNC name is assigned by the EMS when it creates an SNC. However, if the NMS must control the SNC name, you can use the additionalInfo parameter sncName.
The LSP name must match the TP tunnel circuit name. As TP tunnel names are not guaranteed to be unique in the network, you must provide the TP tunnel name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66.
The TKEY represents the TP tunnel key and is returned as an additional parameter whenever retrieving the corresponding SNC. The layer rate that applies to the LSP circuits is LR_MPLS_PATH (166), which provides MPLS path layering to the TP tunnel entity.
Note Local and out labels in the endpoints and midpoints are automatically assigned by the network. To modify them, use the modifySNC API.
name="EMS";value="Cisco Systems/PRIMEOPTICAL"
name="ManagedElement";value="M2-65-122"
name="PTP";value="/rack=1/shelf=1/slot=2/ppm_holder=1/port=1"
You can specify the following additional parameters:
4.6.2.2 deactivateAndDeleteSNC
This interface enables you to deactivate and then delete the LSP SNC in one operation. Prime Optical removes resources allocated to this SNC from each node. This is an asynchronous operation. Successful completion of this operation guarantees only the delivery of the deletion request to Prime Optical. The NMS must wait for an OBJECT_DELETION event for this SNC.
As TP tunnel names are not guaranteed to be unique in the network, you must provide the LSP name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>:LSP=<LSP number>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66:LSP=0.
The TKEY represents the TP tunnel key and is returned as an additional parameter whenever retrieving the corresponding SNC. This key is composed as follows:
<source Node ID>:<source Tunnel ID>:<dest Node ID>:<dest Tunnel ID>
The TKEY represents an invariant component for every TP tunnel. To differentiate among the working and protected LSPs of the TP tunnel, the LSP number and the last token of the composite name is provided.
4.6.2.3 modifySNC
This interface allows the modification of the following information for the given TP tunnel SNC:
This information is provided as layered parameters associated to the LR_MPLS in transmissionParams of the tpsToModify input parameter. As TP tunnel names are not guaranteed to be unique in the network, you must provide the LSP name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>:LSP=<LSP number>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66:LSP=0.
The following table describes the layered parameters that can be modified on TPs. The TPs can be either midpoints or endpoints of the given LSP circuit.
|
|
|
|
|---|---|---|
Local label value associated to the forward path of the LSP. |
||
Local label value associated to the reverse path of the LSP. |
||
The following table describes the layered parameter that can be modified on endpoints of the given LSP circuit.
|
|
|
|
|---|---|---|
4.6.3 MPLS-TP Protection (Provisioning)
In the PTF_10GE_4, PT_10GE_4, and PTSA_GE equipment, the TP tunnel circuit names are not unique. The following pair represents their primary key:
The component LSP circuits are uniquely identified by:
sncName and SID are the same as the TP tunnel key.
When creating an LSP circuit, if you provide the circuit name, SID, and Unique ID through additional parameters, the association with the corresponding TP tunnel is automatically established.
4.6.4 BFD Template, Node ID, and Label Range Provisioning Interface
When creating MPLS-TP tunnels, you can leave some parameters with the default value or you can specify it. If you specify it, you should retrieve and specify the valid range of values at the node level.
For the BFD template and the static label range, you should change the values that are currently specified for the involved ME. To achieve this, because all these parameters are seen as additional parameters at the ME level, you must call the standard setAdditionalInfo API.
4.6.4.1 setAdditionalInfo
This interface allows you to set additional information associated to an ME. Provide the name as the input parameter.
The following table is an example of the BFD template report.
|
|
|
|
|
|
|
|---|---|---|---|---|---|
You can make multiple changes in the same table, because the overall table values are provided in provisioning. To change any field in the table, the entire table must be regenerated again. The EMS analyzes the table content and provisions the necessary changes in the NE.
You can do the following operations:
- Delete a row—Do not report the row with the given BFD name in the table.
- Add a row—Report a new row with a new BFD name in the table
- Modify a row—For a row corresponding to a given BFD, change any column value. The BFD name represents the primary key.
- Delete the whole table—Set bfdtable.Count=0 and all column parameters to an empty string ("").
The routeIdName parameter is read-only. The routeID parameter can only be modified; it cannot be created or deleted.
4.7 Pseudowire Provisioning Interfaces
This section describes the following pseudowire provisioning interfaces:
- Pseudowire FDFr Provisioning Interfaces
- Pseudowire Mixed Configuration (Provisioning)
- Pseudowire Class and Loopback Provisioning Interface
- Pseudowire QoS Provisioning Interface
4.7.1 Pseudowire FDFr Provisioning Interfaces
4.7.1.1 createAndActivateFDFr
The NMS invokes the createAndActivateFDFr service to request the EMS to create and activate a pseudowire with the parameters specified in the method.
- FDFrCreateData_T createData—Describes the structure of the FDFr to be created. Unless specified otherwise, connectionless parameter settings are on a best-effort basis.
- ConnectivityRequirement_T connectivityRequirement—For a connectivity-aware EMS, this parameter identifies the requested operation mode if not all FPs have potential connectivity to one another. If the EMS is not connectivity-aware, ignore this parameter.
- NamingAttributesList_T aEnd—The source CTP/EFP based on a CPTP. The CTP name implicitly provides the AC type and VLAN configuration. Pseudowires always have only one aEnd point. The name of each aEnd must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="name"
name="PTP";value="/rack/shelf/slot/ppm_holder=m/port=n"
For PTSA_GE endpoints, the PTP name must be in the following format:
name="PTP";value="/remote_unit=1/shelf=1/slot=36/ppm_holder=9/port=1"
Slot 36 is mapped to the PTSA_GE remote equipment.
The following table describes the possible use cases with the associated CTP names.
Figure 4-7 Use Cases with Associated CTP Names
For channel group (Ethernet Link Aggregation), the CTP refers to the FTP representing the logical interface for the LAG rather than a physical PTP. The CTP name should be in the following format:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="name"
name="FTP";value="/rack/shelf/port=n"
- globaldefs::NamingAttributesList_T zEnd—Same as aEnd. For dual-homed protected pseudowires, there are two zEnd TPs.
- NamingAttributesList_T internalTPs—Not used. A list of internal CPTP names that must be included in the route of the FDFr. As a result of creating the FDFr, FPs are created as clients of internal CPTPs.
- MatrixFlowDomainFragmentList_T mfdfrs—Not used. An optional list of MFDFrs that represents the route of the FDFr. You can omit this attribute if the FDFr is routed by the network. As a result of creating the FDFr, MFDFrs are created in the various MFDs.
- TPDataList_T tpsToModify—A list of TPs and parameters to be applied. When the method is returned, the list is updated to provide the resulting parameters. The list may refer to FPs that are being created during the createAndActivateFDFr request or to the containing CPTPs.
- flowDomainFragment::FlowDomainFragment_T theFDFr—The newly created and activated FDFr. The EMS is responsible for guaranteeing uniqueness of the name of the FDFr.
- NamingAttributesList_T notConnectableCPTPList—The list of CPTPs that could not be connected; for example, CPTPs that are not part of the same FD.
- NamingAttributesList_T parameterProblemsTPList—The list of CPTPs and FPs for which only best-effort transmission parameters could not be set.
- string errorReason—If a best-effort parameter could not be set or an FP could not be connected, the EMS indicates the fault reason.
The following table describes the transmission parameters associated to the new LR_PW.
The tpsToModify parameter is defined as:
The following table describes the layered parameters for the layer rate LR_PW that is specified on TP endpoints of the pseudowire.
The following table lists the mandatory information based on tagging type.
|
|
|
|
|
|
|---|---|---|---|---|
The network automatically assigns the SID to the FDFr at the time of creation. This SID is returned in the name. For pseudowires, see the example below:
When the creation API is executed, the service is not discovered for all parameters. The API returns a dummy object based on the input parameters. The actual objects are retrieved through the standard inventory APIs.
4.7.1.2 deactivateAndDeleteFDFr
This interface allows the NMS to request the deactivation and deletion of a pseudowire FDFr from an FD.
- NamingAttributes_T fdfrName—The pseudowire name to be deactivated and deleted. The name must be in the following format: <PW native name>:SID=nn.
- TPDataList_T tpsToModify—A list of TPs and parameters to be applied. When the method is returned, the list is updated to provide the resulting parameters. The list may refer only to TPs that take part in the FDFr deletion process.
- string errorReason—Specifies the reason for the fault, if any.
The following describes how the system requests to deactivate and delete an FDFr:
1. The NMS sends the request to the EMS to deactivate and delete an FDFr.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified FDFr object is unknown to the EMS, an Entity Not Found exception is raised.
a. The EMS initiates the deactivation of the FDFr. It attempts to remove, from the applicable MEs, all the MFDFrs which comprise this FDFr.
b. If the EMS succeeds in deactivating the FDFr, it then deletes the FDFr object and all associated FPs.
c. If some MFDFrs were removed and some were not, the FDFr is not deleted from the EMS, and it is marked as Failed.
4. The EMS provides a success indication to the NMS.
5. The EMS sends FP and FDFr object deletion notifications to the notification service.
1. The NMS receives a success indication.
2. An Object Deletion notification is sent.
3. For all MFDFrs which are removed, the associated FPs are deleted.
4. If all MFDFrs were removed, the FDFr has been deleted.
If the FDFr was not deleted, it is marked as Failed.
If the request is not successful, the NMS receives an exception as an indication of the failure of the request.
4.7.1.3 modifyFDFr
This interface allows you to request the EMS to modify an existing FDFr as specified by the parameters in the method.
- NameAndStringValue_T[] fdfrName—The FDFr name to be modified. To uniquely identify the FDFr, use the following format: <FDFr native name>:SID=34.
- FDFrModifyData_T fdfrModifyData—Describes the structure of the FDFr to be modified. Modification of connectionless parameters is done on a best-effort basis. For pseudowires, only UserLabel and administrative state can be changed.
- ConnectivityRequirement_T connectivityRequirement—Not supported for pseudowires.
- subnetworkConnection::TPDataList_T tpsToModify—A list of TPs and parameters to be applied. When the method is returned, the list is updated to provide the resulting parameters. The list may refer to the FPs or to the containing CPTPs.
- globaldefs::NamingAttributesList_T failedTPList—Not supported for pseudowires.
- globaldefs::NamingAttributesList_T parameterProblemsTPList—The list of CPTPs and FPs for which only best-effort transmission parameters could not be set.
- flowDomainFragment::FlowDomainFragment_T newFDFr—The modified FDFr.
- string errorReason—If a best-effort parameter could not be set, the EMS provides the fault reason.
The NMS can modify the user label, administrative state, and QoS information associated to the FDFR FPs.
The following describes how the system requests to modify an FDFr:
1. The NMS sends a request to the EMS to modify an FDFr.
2. The EMS validates the request:
a. If the syntax is incorrect, an Invalid Input exception is raised.
b. If the specified FDFr object is unknown to the EMS, an Entity Not Found exception is raised.
c. If user label uniqueness is required, the EMS checks the user label for uniqueness. If an FDFr object with the same user label exists, a User Label In Use exception is raised.
d. If any of the TP objects specified for modification is unknown to the EMS, an Entity Not Found exception is raised.
e. If any of the TP objects specified in the modification is not associated with the specified FDFr, an Entity Not Found exception is raised.
f. If an unrecognized name exists in the QoS policy names provided for specified FPs, an Unable To Comply exception is raised.
3. If the request is valid, the EMS modifies the FDFr attributes and parameters, as requested.
4. The EMS returns a success indication.
The administrative state change applies to the entire service only if tpsToModify or zEndTPNames is specified. If neither of these parameters is specified, the change applies only to those tpsToModify that have been specified and to the new drop specified. To change the administrative state, set the changeAdminState parameter to true in the additionalModificationInfo.
The following table describes the additionalModificationInfo parameter.
|
|
|
|
|---|---|---|
Indicates whether the admin state can be changed based on the new value specified in the administrativeState field. |
4.7.2 Pseudowire Mixed Configuration (Provisioning)
Prime Optical supports pseudowire mixed configuration. You can configure a pseudowire with an interface-based drop and a VLAN-based drop. The difference between the two is in the types of parameters that are required to characterize the two types of CTPs. For more information, see deactivateAndDeleteFDFr and modifyFDFr.
4.7.3 Pseudowire Class and Loopback Provisioning Interface
When you create a pseudowire, a given set of parameters can be either left as default values or specified. If these parameters are specified, you must retrieve and specify the valid range of values at the ME level.
The pseudowire class is a set of attributes which associates a given pseudowire with a given TP tunnel during creation. To do this, use the setAdditionalInfo API. For more information about loopback interface, see getManagedElement.
4.7.3.1 setAdditionalInfo
This interface allows you to create and associate a new pseudowire class to the ME and make it available while creating the pseudowire. You can set additional information associated to an ME by providing the name as the input parameter.
The pwClassTable attributes are all required if at least one of the pwClassTable attribute is specified. The attributes values are not passed in the creation request sent to the node if:
- pwClassTable.PrefPathEnabled is false, the pwClassTable.TunnType, pwClassTable.TunnNum, pwClassTable.DisFallback attributes are required, but the content is not passed to the node in the creation command.
- pwClassTable.SeqEnabled is true and pwClassTable.Protocol attribute is NONE, the pwClassTable.ResyncTimer attribute is required, but the content is not passed to the node in the creation command.
- pwClassTable.SeqEnabled is false, the pwClassTable.SeqOper and pwClassTable.ResyncTimer attributes are required, but the content is not passed to the node in the creation command.
- pwClassTable.StaticOAMenabled is false, the pwClassTable.StaticOamClass attribute is required, but the content is not passed to the node in the creation command.
- pwClassTable.BFDoVCCVEnabled is false, the pwClassTable.BfdTemplate and pwClassTable.AcStat attributes are required, but the content is not passed to the node in the creation command.
If pwClass creation or modification fails, an exception is returned if:
- The attribute values do not match the attribute description listed in the table.
- pwClassTable.Name is empty.
- pwClassTable.Interwork is not NONE and pwClassTable.SeqEnabled is true.
- pwClassTable.StaticOAMEnabled is true and pwClassTable.StaticOamClass is an empty string ("").
- pwClassTable.BFDoVCCVEnabled is true and pwClassTable.BfdTemplate is an empty string ("").
- pwClassTable.BFDoVCCVEnabled is true and pwClassTable.CtrlWord is false.
- pwClassTable.Protocol is NONE; and pwClassTable.BFDoVCCVEnabled, pwClassTable.StaticOAMEnabled, and pwClassTable.AcStat are true.
- pwClassTable.Protocol is LDP and pwClassTable.StaticOAMEnabled is true.
- pwClassTable.Protocol is LDP and pwClassTable.StaticOAMEnabled is false and pwClassTable.AcStat is true.
- pwClassTable.PrefPathEnabled is true, pwClassTable.TunnType is TP, and pwClassTable.Protocol is LDP.
If pwClass deletion fails, an exception is returned if:
- The attribute values do not match the attribute description listed in the table.
- pwClassTable.Name is empty.
The following table shows an example of adding a pseudowire class.
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|
The following table shows an example of deleting a pseudowire class.
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|
The following table shows an example of modifying a pseudowire class.
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|
4.7.4 Pseudowire QoS Provisioning Interface
When you create a pseudowire, specify the QoS policies to be associated to the pseudowire drops. If you specify policy maps, they must be available in the given ME the Ethernet drop belongs to.
1. Create the TC profiles for policy maps, class maps, actions, and table maps using the createTCProfile interface. The new policies are stored in the EMS database, not in the ME.
2. Modify and delete QoS policies through the modifyTCProfile and deleteTCProfile interfaces.
3. Associate the given policies that are already present in the EMS database to an ME using the setAdditionalInfo interface, which downloads the given policies to the NE.
4. Use the getManagedElement interface to get the QoS policies present in an ME. The QoS policy names are returned with the additional parameters.
5. When you create a pseudowire, specify the desired QoS policy map names (at ingress and egress) as additional parameters at pseudowire endpoints within the createAndActivateFDFr interface.
4.7.4.1 TCProfileMgr::setAdditionalInfo
This interface allows you to associate a list of QoS policies to an ME. The NMS provides the ME name in the objectName parameter and the list of QoS policies in the additionalInfo parameter. The EMS returns the list of policies whose provisioning has succeeded on the given ME in the additionalInfo parameter. If provisioning failed for all the given QoS policies, the additionalInfo output contains an empty array.
The following table describes the parameters for additionalInfo in TCProfileMgr::setAdditionalInfo.
|
|
|
|
|---|---|---|
Each tuple is optional, but can be repeated as many times as needed to direct the EMS to provision multiple class maps, policy maps, and table maps on an ME. The order is irrelevant.
Note You cannot modify or delete TC profiles that are provisioned on the node with the current API implementation.
4.8 Supported Inventory Interfaces
The following table lists the inventory interfaces supported in Prime Optical 9.3.
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
Pseudowire Class, Loopback, and QoS Policy Inventory Interface |
|
4.9 EVC Inventory Interfaces
This section describes the following EVC inventory interfaces:
- CPTP Inventory Interfaces
- MFD Inventory Interfaces
- Flow Domain Inventory Interfaces
- EVC FDFr Inventory Interfaces
- Link Aggregation Inventory Interfaces
- Common Inventory Interface
- Traffic Conditioning Profile Inventory Interfaces
- MPLS-TP Inventory Interfaces
4.9.1 CPTP Inventory Interfaces
4.9.1.1 getAllCPTPs
This interface returns the structure of all CPTPs, fdEdge CPTPs, or fdInternal CPTPs associated with an FD.
- NamingAttributes_T fdName—FD name. The associated CPTPs of this FD are returned.
- CPTP_Role_T cptpRole—CPTPs to be returned (fdEdge CPTP, fdInternal CPTP, or all CPTPs).
- unsigned long how_many—Maximum number of CPTPs to be returned in the first batch.
- TerminationPointList_T cptpList—First batch of CPTPs.
- TerminationPointIterator_I cptpIt—Iterator to retrieve the remaining CPTPs.
4.9.1.2 getAllAssignedCPTPs
This interface returns the structure of all CPTPs assigned to an MFD.
- NamingAttributes_T mfdName—MFD name. The assigned CPTPs of this MFD are returned.
- unsigned long how_many—Maximum number of CPTPs to be returned in the first batch.
- TerminationPointList_T cptpList—First batch of CPTPs.
- TerminationPointIterator_I cptpIt—Iterator to retrieve the remaining CPTPs.
4.9.1.3 getAllAssignableCPTPs
This interface returns the structure of all CPTPs that can be assigned to an MFD. These CPTPs must be on the same equipment or same rack with backplane connectivity.
- NamingAttributes_T mfdName—MFD name. The potential CPTPs of this MFD are returned.
- unsigned long how_many—Maximum number of CPTPs to be returned in the first batch.
- TerminationPointList_T cptpList—First batch of CPTPs.
- TerminationPointIterator_I cptpIt—Iterator to retrieve the remaining CPTPs.
4.9.1.4 getAllPTPs
For CPTPs, use this interface to determine the parameters that characterize a CPTP.
4.9.1.5 getTP
This interface returns the TP structure for the given TP name (CTP, FTP, or PTP). The TP structure consists of transmission parameters. The transmission parameters returned are the parameters in place on the actual TP on the NE. If there are no transmission parameters or the TP does not actually exist on the NE, transmissionParams will be empty.
- NamingAttributes tpName—TP name. The structure of this TP is retrieved.
- TerminationPoint_T tp—The retrieved TP.
For CPTPs, use this interface to determine the parameters that characterize a CPTP.
The following table describes the ConnectionlessPort and PortTPRoleState parameters.
|
|
|
|
|
|
|
|---|---|---|---|---|---|
See setAdditionalInfo. |
|||||
See setAdditionalInfo. The mismatch operational state exists for the CPTP if there is a mismatch in the port type. This is applicable only on pluggable PPM ports when you change a previously defined CPTP with a port that no longer supports Ethernet. |
4.9.2 MFD Inventory Interfaces
4.9.2.1 getAllAssociatedMFDs
This interface enables the NMS to request a list of MFDs that are associated with a specified transmission descriptor (TMD) or FD. This operation uses an iterator to allow the NMS to deal with a large number of objects.
- NamingAttributes_T tmdOrFdName—Name of the TMD or FD.
- unsigned long how_many—Maximum number of MFDs to be returned in the first batch.
- MFDList_T mfds—First batch of MFDs.
- MFDIterator_I mfdIt—Iterator to retrieve the remaining MFDs.
In Prime Optical 9.3, this interface is supported only if the tmdOrFdName parameter contains an FD name.
4.9.2.2 getAllSupportedMFDs
This interface enables the NMS to request a list of MFDs that are contained by a specified ME or supported with specified equipment (holderName). This operation uses an iterator to allow the NMS to deal with a large number of objects.
- NamingAttributes_T holderName—Name of the ME or equipment.
- unsigned long how_many—Maximum number of MFDs to be returned in the first batch.
- MFDList_T mfds—First batch of MFDs.
- MFDIterator_I mfdIt—Iterator to retrieve the remaining MFDs.
This interface supports the request only for MEs, slots, and TPs.
4.9.2.3 getMFD
This interface returns the structure of an MFD.
- globaldefs::NamingAttributes_T mfdName—MFD name that must be retrieved. The name of each MFD must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="ManagedElementName"
name="MatrixFlowDomain"; value= "MatrixFlowDomainName"
4.9.2.4 getAssigningMFD
This interface returns the MFD to which a CPTP is assigned.
- NamingAttributes_T cptpName—Name of the CPTP to which the MFD is assigned.
- MatrixFlowDomain_T mfd—The MFD structure that is returned.
4.9.3 Flow Domain Inventory Interfaces
4.9.3.1 getAllFlowDomains
This interface enables the NMS to request a list of FDs that exist in the EMS. This operation uses an iterator to allow the NMS to deal with a large number of objects.
- unsigned long how_many—Maximum number of FDs to be returned in the first batch.
- FDList_T flowDomains—First batch of FDs.
- FDIterator_I fdIt—Iterator to retrieve the remaining FDs.
4.9.3.2 getFlowDomainsByUserLabel
This interface returns the FD structure for the FDs. You must use userLabel as the parameter. The operation does not use an iterator because the number of FDs returned is 1.
- string userLabel—The user label of the FD that must be retrieved.
- FDList_T flowDomains—The list of identified FDs.
4.9.3.3 getFlowDomain
This interface returns the FD structure.
- NamingAttributes_T fdName—Name of the FD that must be retrieved. The name of each FD must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="FlowDomain";value=" FlowDomainName"
4.9.3.4 getAllTopologicalLinksOfFD
This interface returns a list of topological links at the encapsulation layer. These links are terminated at the FD. The topological link name must be passed as a parameter. This operation uses an iterator to allow the NMS to deal with a large number of objects.
- NamingAttributes_T flowDomainName—FD name.
- unsigned long how_many—Maximum number of topological links to be returned in the first batch.
- TopologicalLinkList_T topoList—First batch of topological links.
- TopologicalLinkIterator_I topoIt—Iterator to retrieve the remaining topological links.
4.9.3.5 getAssociatingFD
This interface returns the FD structure that the MFD is associated to.
- NamingAttributes_T mfdName—The name of MFD.
- FlowDomain_T flowDomain—The FD that the MFD is associated to.
4.9.4 EVC FDFr Inventory Interfaces
4.9.4.1 getFDFr
This interface returns the FDFr representing the EVC. This EVC name must be provided as a parameter.
<EVC native name>:SID=nn:LR=EVC.
The following table describes the additionalInfo parameter.
|
|
|
|
|---|---|---|
The EFP configuration parameters that characterize the EVC drops are similar to pseudowire drops. For more information, see getFDFr.
4.9.4.2 getAllFDFrs
This interface requests a list of FDFrs for the specified FD at the defined connectivity rates. This operation uses an iterator to allow the NMS to deal with a large number of objects. For more information, see getAllFDFrs.
For EVC FDFRs, all the get APIs reflect as a sequence of requests issued directly to the nodes in the network. Database data cannot be used for EVCs.
4.9.4.3 getFDFrsWithTP
This interface enables the NMS to request the EMS for the FDFrs that are connected to a specified FP or CPTP. If you use an FP as an input parameter, not more than one FDFr is returned. For more information, see getFDFrsWithTP.
4.9.4.4 getFDFrsByUserLabel
This interface returns the FDFr by userLabel. Provide the userLabel as the parameter. The operation does not use an iterator because the number of FDFrs returned is expected to be 1. For more information, see getFDFrsByUserLabel.
4.9.4.5 getAllFDFrNames
This interface returns the list of all the pseudowire names configured in an FD. For more information, see getAllFDFrNames.
4.9.4.6 getFDFrNamesWithTP
This interface returns the list of all the pseudowire names; the list has at least one EFP in the CPTP provided as the input parameter. For more information, see getFDFrsWithTP.
For EVC FDFRs, all the get APIs reflect as a sequence of requests issued directly to the nodes in the network. Database data cannot be used for EVCs.
4.9.4.7 getFDFrRoute
This interface returns the FDFr route representing the EVC. The EVC name is specified as a parameter.
<EVC native name>:SID=nn:LR=EVC
LR=EVC represents Layer Rate = EVC. The API does not expect an LR to be specified.
4.9.5 Link Aggregation Inventory Interfaces
4.9.5.1 getAllFTPs
This interface returns the FTPs.
- NamingAttributes_T managedElementName—ME name.
- LayerRateList_T tpLayerRateList—List of FTP layer rates for which the FTPs are to be fetched. An FTP must contain at least one of the layer rates specified. If the list is empty, FTPs of all rates are returned.
- LayerRateList_T connectionLayerRateList—List of connection layer rates for which the FTPs are to be fetched. An FTP must support connections for at least one of the layer rates specified. If the list is empty, FTPs for all connection rates are returned.
- unsigned long how_many—Maximum number of FTPs to be returned in the first batch.
- TerminationPointList_T tpList—First batch of FTPs.
- TerminationPointIterator_I tpIt—Iterator to retrieve remaining FTPs.
4.9.5.2 getAllFTPNames
This interface returns the FTP names.
- NamingAttributes_T managedElementName—ME name.
- LayerRateList_T tpLayerRateList—List of FTP layer rates for which the FTPs are to be fetched. An FTP must contain at least one of the layer rates specified. If the list is empty, then FTPs of all rates are returned.
- LayerRateList_T connectionLayerRateList—List of connection layer rates for which the FTPs are to be fetched. An FTP must support connections for at least one of the layer rates specified. If the list is empty, FTPs for all connection rates are returned.
- unsigned long how_many—Maximum number of FTPs to be returned in the first batch.
- NamingAttributesList_THolder nameList—First batch of FTP names.
- NamingAttributesIterator_IHolder nameIt—Iterator to retrieve remaining FTP names.
4.9.5.3 getTP
This interface returns the TP structure for the given TP names (CTP, FTP, or PTP). The TP name must be explicit. The transmission parameters returned are the parameters in place on the actual TP on the NE. If there are no transmission parameters or the TP does not actually exist on the NE, the transmissionParams are empty.
- NamingAttributes tpName—Name of the FTP to be retrieved. Because an Ethernet LAG port can aggregate client Ethernet ports of different ME cards, the corresponding FTP is logically positioned on the unique shelf of the ME itself. The TP name must be in the following format:
name="EMS";value="CompanyName/EMSname"
name="ManagedElement";value="ManagedElementName"
name="FTP";value="/rack=1/shelf=1/port=nn"
The additionalInfo parameter specifies all the following attributes at FTP Level.
4.9.6 Common Inventory Interface
4.9.6.1 getTransmissionParams
This interface returns the transmission parameters of an FD and MFD. Specify the set of transmission parameters to be returned.
4.9.7 Traffic Conditioning Profile Inventory Interfaces
4.9.7.1 getAllTCProfiles
This interface allows an NMS to request all of the TC profiles that are under the control of the TCProfileMgr. To allow the NMS to deal with a large number of objects, this operation uses an iterator.
4.9.7.2 getTCProfile
This interface returns the TC profile structure for the specified tcProfileName. The TC profile structure contains an NVSList of traffic parameters. If there are no traffic parameters, the NVSList is empty.
4.10 MPLS-TP Inventory Interfaces
This section describes the following MPLS-TP inventory interfaces:
- MPLS-TP Tunnel Inventory Interfaces
- MPLS-TP LSP Inventory Interfaces
- MPLS-TP Tunnel Link Inventory Interfaces
- MPLS-TP LSP Route Inventory Interfaces
- MPLS-TP Protection (Inventory)
- BFD Templates, Node ID, and Label Range Inventory Interface
4.10.1 MPLS-TP Tunnel Inventory Interfaces
4.10.1.1 getSNC
This interface returns the SubnetworkConnection structure for the TP tunnel SNC identified by the sncName. Because TP tunnel names are not guaranteed to be unique in the network, you must provide the TP tunnel name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66.
The BFD template order follows the order of the aEnd and zEnd endpoints of the TP tunnel. Because the order is not stored in the ME, it depends on the order of discovery. The TKEY is composed as follows:
<source Node ID>:<source Tunnel ID>:<dest Node ID>:<dest Tunnel ID>
The TKEY remains invariant with the order of discovery.
The following table describes the additionalInfo parameters.
|
|
|
|
|---|---|---|
The tunnel key is composed in the following format: sourceNodeId:SourceTunNum:DestNodeId:DestTunNum |
aEnd and zEnd CTPs report as Prime Optical native name. The tunnel number must be in the following format: TunnelNum=ddd.
The following are possible values for the SNC state:
- Pending—The SNC has been created by an NMS and has not been activated by any NMS, or the SNC has been successfully deactivated by an NMS. This state has no relationship with the network state of the SNC cross-connections.
- Partial—The SNC is not in pending state. A route has not been assigned to the SNC, or not all of the SNC cross-connections are active in the network. This may or may not include activated SNCs for which there are currently no active cross-connections in the network. A TP tunnel without any LSPs configured is in partial state.
- Active—The SNC is not in pending state. A route has been assigned to the SNC, and all SNC cross-connections are active in the network.
4.10.1.2 getAllSubnetworkConnectionsWithTP
This interface allows the NMS to request a list of MPLS-TP tunnel SNCs using the specified TP at the specified connection rates. The TP tunnel layer rate is LR_MPLS (165). A TP can be a PTP. Because an MPLS-TP tunnel is terminated in the equipment and not in the PTP, all the MPLS-TP tunnels that end in the device and are suspended by the PTP are returned.
4.10.1.3 getAllSubnetworkConnectionsNamesWithTP
This interface allows the NMS to request a list of MPLS-TP tunnel SNC names using the specified TP at the specified connection rates. The TP tunnel layer rate is LR_MPLS (165). A TP can be a PTP. Because an MPLS-TP tunnel is terminated in the equipment and not in the PTP, all the MPLS-TP tunnels that end in the device and are suspended by the PTP are returned.
4.10.1.4 getAllSubnetworkConnections
This interface allows the NMS to request a list of SNCs for the specified subnetwork at the specified connection rates.
4.10.1.5 getAllSubnetworkConnectionNames
The NML-EML interface allows the NMS to retrieve the names of all the SNCs contained within an NMS-specified Multilayer Subnetwork (MLSN).
4.10.1.6 getSNCsByUserLabel
This interface returns the SNC structures by userLabel. Specify the userLabel as a parameter. This operation does not use an iterator because the number of SNCs returned is expected to be 1.
- string userLabel—The user label of the SNCs to be retrieved.
- SubnetworkConnection_T sncList—The SNCs retrieved.
4.10.2 MPLS-TP LSP Inventory Interfaces
4.10.2.1 getSNC
This interface returns the SNC structure for the LSP SNC identified by sncName, SID, and UniqueID. For PTF_10GE_4, PT_10GE_4, and PTSA_GE MPLS implementation, the SNC name is not guaranteed to be unique within the EMS. Each LSP is specified by a given sncName, Service ID, and Unique ID, which allows for discrimination between the two LSPs (if it is a protected MPLS-TP tunnel). This operation returns the SNC structure for the TP tunnel SNC identified by sncName.
Because TP tunnel names are not guaranteed to be unique in the network, you must provide the LSP name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>:LSP=<LSP number>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66:LSP=0.
The following table describes the additionalInfo parameter.
|
|
|
|
|---|---|---|
The tunnel key is composed in the following format: sourceNodeId:SourceTunNum:DestNodeId:DestTunNum |
||
The transmissionParams associated to the layer rate LR_MPLS_PATH (166) reports the two attributes described in the following table.
|
|
|
|
|---|---|---|
Represents the administrative switch state: LOCKOUT or CLEAR. |
||
Represents the current operational state of each cross-connection: ACTIVE or STDBY. |
4.10.2.2 getAllSubnetworkConnectionsWithTP
This interface allows the NMS to request a list of LSP SNCs using the specified TP at the specified connection rates. The LSP layer rate is LR_MPLS_PATH (166). A TP can be a PTP. Because an MPLS-TP tunnel is terminated in the equipment and not in the PTP, all the MPLS-TP tunnels that end in the device and suspended by the PTP are returned.
4.10.2.3 getAllSubnetworkConnectionsNamesWithTP
This interface allows the NMS to request a list of LSP SNC names using the specified TP at the specified connection rates. The LSP layer rate is LR_MPLS_PATH (166). A TP can be a PTP. Because an MPLS-TP tunnel is terminated in the equipment and not in the PTP, all the MPLS-TP tunnels that end in the device and suspended by the PTP are returned.
4.10.3 MPLS-TP Tunnel Link Inventory Interfaces
4.10.3.1 getTopologicalLink
4.10.3.2 getAllTopologicalLinks
4.10.3.3 getAllTopologicalLinkNames
4.10.3.4 getAllTopLevelTopologicalLinks
4.10.3.5 getAllTopLevelTopologicalLinkNames
4.10.3.6 getTopLevelTopologicalLink
4.10.4 MPLS-TP LSP Route Inventory Interfaces
The Route object represents the route of an SNC. An SNC route is represented as a partially ordered series of cross-connections through which the SNC travels. Only SNC layer rate cross-connections are part of the route. The cross-connections that are part of the route are listed from the NE on which the SNC starts to the NE on which it ends. LSP aEnd and zEnd are not available in cross-connections.
4.10.4.1 getRoute
The NML-EML interface allows the NMS to retrieve the attributes of a route using the NMS-specified SNC name. The route information, in the form of ordered cross-connections, must identify the resources allocated to the SNC at the time of the request and the way in which these resources are used.
The NMS specifies if it will retrieve resources in the SNC layer only. Because TP tunnel names are not guaranteed to be unique in the network, you must provide the LSP name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>:LSP=<LSP number>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66:LSP=0.
- NamingAttributes sncName—SNC name.
- boolean includeHigherOrderCCs—Specifies whether the higher order cross-connections of other SNCs used to carry the queried SNC must be included in addition to the cross-connections of the queried SNC.
- Route_T route—The route of the SNC.
The following table describes the relevant parameters returned in the additionalInfo field.
|
|
|
|
|---|---|---|
Local label value associated to the forward path of the LSP. |
||
Local label value associated to the reverse path of the LSP. |
||
4.10.4.2 getRouteAndTopologicalLinks
This interface returns the route, in terms of cross-connections, for the LSP SNC. The LSP SNC name is specified as a parameter. This interface also returns the list of topological links for that SNC that are used in the route. Because TP tunnel names are not guaranteed to be unique in the network, you must provide the LSP name in the following format:
<Native TP-Tunnel name>:TKEY=<TP-Tunnel key>:LSP=<LSP number>
For example, tunnel192_193:TKEY=3.3.3.0:55:5.5.5.0:66:LSP=0.
- NamingAttributes sncName—SNC name.
- Route_T route—The route of the SNC.
- TopologicalLinkList_T topologicalLinkList—The list of the topological links.
4.10.4.3 getAllCrossConnections
This interface allows the NMS to request a list of cross-connections for the specified ME at the specified layer rate (LR_MPLS_PATH). This operation returns cross-connections between CTPs and FTPs. This operation uses an iterator to allow the NMS to deal with a large number of objects.
- NamingAttributes_T managedElementName—ME name for which cross-connections must be retrieved.
- LayerRateList_T connectionRateList—List of rates for which cross-connections must be retrieved. If the list is empty, an INVALID_INPUT exception is raised.
- unsigned long how_many—Maximum number of cross-connections to report in the first batch.
- CrossConnectList_T ccList—First batch of cross-connections.
- CCIterator_I ccIt—Iterator to retrieve the remaining cross-connections.
4.10.5 MPLS-TP Protection (Inventory)
The relationship between an MPLS-TP tunnel circuit and its LSP circuits is provided by inventorying the MPLS-TP tunnel circuit. Additional parameters identify the working and protected LSPs. These parameters are taken into account whenever the LSP circuits are inventoried for further details.
For the LSPs, the current network implementation provides the same sncName and SID as for the TP tunnel they are part of. LSPs are addressed individually by specifying the unique ID.
The following table describes the names of the additional parameters returned by the TP tunnel circuit.
|
|
|
|
|---|---|---|
4.10.6 BFD Templates, Node ID, and Label Range Inventory Interface
4.10.6.1 getManagedElement
This interface returns the ME with all the relevant information about BFD template, static and dynamic label range, node ID, and router ID reported in the additionalInfo parameter.
The following table describes the additionalInfo parameters involved.
|
|
|
|
|
|---|---|---|---|
Single-hop information. In Prime Optical 9.3, true is the only allowed value. |
|||
Each BFD template is characterized by a sequence of attributes. The information of all the BFD templates on an ME is modeled as a BFD table. The TMF standard anticipates to model tables in the following way:
- An attribute ("bfdTable.Count") reporting the number of rows of the table.
- For every column in the table, an attribute that consists of a string of comma-separated values. The number of comma-separated values in each parameter must be equal to the value of the bfdtableCount attribute.
The following table is an example of the BFD table.
|
|
|
|
|
|
|
|---|---|---|---|---|---|
4.11 Pseudowire Inventory Interfaces
This section describes the following pseudowire inventory interfaces:
4.11.1 Pseudowire FDFr Inventory Interfaces
4.11.1.1 getFDFr
This interface returns the FDFr representing the pseudowire. The pseudowire name is provided as a parameter.
- NamingAttributes_T fdfrName—The name of the FDFr to be retrieved. The pseudowire name is provided as:
The transmission parameters report the following information.
|
|
|
|
|---|---|---|
The additionalInfo parameter contains the following information.
|
|
|
|
|---|---|---|
For FDFr, TMF introduced the AdministrativeState parameter. It assumes the following values:
MTNM version 3.5 has defined the aEnd and zEnd FDFr data types as an array of NameAndStringValue_T rather than an array of TPData_T as for the SNC structure. Prime Optical has substituted the NameAndStringValue_T with TPData_T in the Interface Design Languages (IDLs).
The following table describes the layered parameters that characterize the pseudowire endpoints.
|
|
|
|
|---|---|---|
(Optional) Specify a static value for the backup local label. |
||
4.11.1.2 getAllFDFrs
This interface allows retrieval of a list of FDFrs for the specified FD at the specified connectivity rates. This operation uses an iterator to allow the NMS to deal with a large number of objects.
- NamingAttributes_T fdName—FD name.
- LayerRateList_T connectivityRateList—List of FDFr rates to be reported. If an empty list is specified, all FDFrs of all rates are to be reported.
- unsigned long how_many—Maximum number of FDFrs to be reported in the first batch.
- FDFrList_T fdfrList—First batch of FDFrs.
- FDFrIterator_I fdfrIt—Iterator to retrieve the remaining FDFrs.
4.11.1.3 getFDFrsWithTP
This interface allows the NMS to request the EMS for the FDFrs that are connected to a specified FP or CPTP. If the FP is an input parameter, not more than one FDFr is returned.
- NamingAttributes_T tpName—The name of the FP or CPTP for which the connected FDFrs are returned.
- unsigned long how_many—Maximum number of FDFrs to be reported in the first batch.
- FDFrList_T fdfrList—First batch of FDFrs.
- FDFrIterator_I fdfrIt—Iterator to retrieve the remaining FDFrs.
4.11.1.4 getAllFDFrNames
This interface returns the list of all the pseudowire names configured in an FD.
4.11.1.5 getFDFrNamesWithTP
This interface returns the list of all the pseudowire names that have at least one EFP in the CPTP provided as an input parameter.
4.11.1.6 getFDFrsByUserLabel
This interface returns the FDFr by userLabel. The userLabel is provided as a parameter. The operation does not use an iterator because the number of FDFrs returned is expected to be 1.
- string userLabel—The user label of the FDFrs to be retrieved.
- FDFrList_T fdfrs—The list of identified FDFrs.
4.11.1.7 getFDFrRoute
This interface returns the FDFr route. The FDFr name is specified as a parameter. Use this interface only if the route is provisioned by the NMS.
The additionalInfo parameter allows the communication of additional information (not explicitly modeled) from the EMS to the NMS. The following table describes the path1Link and path2Link parameters.
Figure 4-8 shows the unprotected pseudowire.
Figure 4-8 Unprotected Pseudowire
Figure 4-9 shows the protected pseudowire.
Figure 4-9 Protected Pseudowire
Figure 4-10 shows the dual-homed protected pseudowire.
Figure 4-10 Protected Pseudowire-Dual Homed
4.11.2 Pseudowire Class, Loopback, and QoS Policy Inventory Interface
4.11.2.1 getManagedElement
This interface returns the ME with all the relevant information about BFD template, static and dynamic label range, node ID, and router ID reported in the additionalInfo parameter.
The following table describes the additionalInfo parameters involved. All fields contain a sequence of comma-separated values.
Each pseudowire class is characterized by a sequence of attributes. The information about all pseudowire classes on a given ME is modeled as a pseudowire table. The TMF standard anticipates to model tables in the following way:
- An attribute ("pwClassTable.Count") reporting the number of rows of the table.
- For every column of the table, an attribute that consists of a string of comma-separated values. The number of comma-separated values in each parameter must be equal to the value of the pwClassTable.Count attribute.
The following is an example of the pseudowire class table.
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|
4.12 Alarm Summaries
The network can generate Layer 2 service-related alarm summaries on Ethernet ports, channel group ports, and shelves. You can use the getAllActiveAlarms method to get information about the alarms. Provide the meName parameter as shown in the following table.
4.12.1 Alarm Summary Example—Channel Group Port
|
|
|
|---|---|
The returned alarms have affectedObjList (an array of nameAndVaue type_T), which reports the list of affected Layer 2 services.
4.12.2 Pseudowire Alarm Event Example
4.12.3 MPLS-TP Tunnel Alarm Event Example
4.12.4 Channel Group Alarm Event Example
4.13 Error Messages
This section lists the error messages generated by the GateWay/CORBA connectionless interfaces. It includes the following sections:
- MPLS-TP Tunnel Error Messages
- LSP Error Messages
- Pseudowire Error Messages
- EVC Error Messages
- FD, MFD, and CPTP Error Messages
4.13.1 MPLS-TP Tunnel Error Messages
This section lists the MPLS-TP tunnel error messages. The error messages appear if you enter invalid parameters or values. For valid parameters and values, see:
The following are the error messages:
- The MPLS-TP tunnel name is invalid for managing MPLS.
- The MPLS-TP tunnel was not found: nativeName.
- Only one endpoint was discovered for the TP tunnel.
- The TP tunnel does not exist.
- bwUnits must be Kbps, Mbps, or Gbps.
- aEnd and zEnd points must be in the same multilayer subnetwork.
- Source aEnd point is not available for TP tunnel creation.
- Destination zEnd point is not available for TP tunnel creation.
- You cannot create the TP tunnel SNC name based on node ID and tunnel number.
- The SID SID-Number is already in use on ME-Name.
- The BFD that you provided is invalid.
- The BFD userBfd is not in the following list of available BFDs: listOfAvailableBFDs.
- The CTP name is invalid.
- The MPLS-TP tunnel CTP name ctpNativeName is invalid. Use the format tunnelNum=nnn.
- The TP tunnel endpoint was discovered incorrectly.
- An internal error occurred while reading rows from the Tbl_MPLS_TP_EP table.
- An internal error occurred while reading rows from the MPLS_TP_TABLE table.
- An internal error occurred while reading rows from the MPLS_SERVICE_TABLE table.
4.13.2 LSP Error Messages
This section lists the LSP tunnel error messages. The error messages appear if you enter invalid parameters or values. For valid parameters and values, see:
The following are the error messages:
- The LSP name is invalid for managing MPLS.
- The MPLS-TP tunnel for the LSP lspNativeName was not found.
- The LSP lspNativeName was not found.
- An LSP with the unique ID uniqueId was not found.
- You must provide an sncName and TKEY.
- The aEnd and zEnd LSP numbers must be the same.
- The aEnd and zEnd points must be in the same multilayer subnetwork.
- The LSP aEnd does not match the TP tunnel aEnd or zEnd.
- The TP tunnel already has working and protected LSPs.
- Source aEnd point is not available for TP tunnel creation.
- Destination zEnd point is not available for TP tunnel creation.
- The protected LSP number protLspNum is already being used by the working LSP.
- The working LSP number workLspNum is already being used by the protected LSP.
- The protected LSP already exists for the TP tunnel.
- The working LSP already exists for the TP tunnel.
- TopologicalLink input is not supported.
- neTPinclusions or neTpSncExclusions is invalid.
- neTpInclusions is invalid. The type is unsupported.
- neTpSncExclusions is invalid. The type is unsupported.
- An internal error occurred while reading rows from the MPLS_LSP_CTP table.
4.13.3 Pseudowire Error Messages
This section lists the pseudowire error messages. The error messages appear if you enter invalid parameters or values. For valid parameters and values, see:
The following are the error messages:
- Category is not specified for the enableStatistics parameter.
- You must specify pwClass for managed endpoints.
- You must specify the pseudowire vcID for managed endpoints.
- The pseudowire layer rate must be LR_PW.
- The FD fdName does not exist in the EMS.
- Pseudowire FDFrs must have only one aEnd point.
- You have not entered a value for aEnd.
- Pseudowire FDFrs must have one or two zEnd points for dual-homed protection.
- The specified pseudowire endpoint ptpName is unavailable.
- The egress policy map egrPolMapName is not contained in the ME ME-Name.
- The ingress policy map ingrPolMapName is not contained in the ME ME-Name.
- The table map TabMapName is not contained in the ME ME-Name.
- Available endpoints on ME ME-Name could not be retrieved.
- You must specify pseudowire transmission parameters.
- Redundancy information is missing.
- The necessary free labels within the NE NE-Name could not be retrieved.
- The FDFr name format is invalid.
- checkPWClassCompliancy for node ME-Name failed because pwClass is not specified.
- A connection could not be created on the node ME-Name because the VC ID is in use.
- The operation failed because the VLAN IDs vlanIds are already configured under other service instances.
4.13.4 EVC Error Messages
This section lists the EVC error messages. The error messages appear if you enter invalid parameters or values. For valid parameters and values, see:
The following are the error messages:
- The tpsToModify parameter must include the associated EFP parameters for VLAN-Based EVCs.
- The EVC layer rate must be LR_EVC.
- The drop to be added is on a new ME, so EFP for the internal drop is required.
- Unique ID could not be set on the EMS server.
- EVC constraints could not be set.
- Only ME inclusions are foreseen in EVC routing.
- The service has been created, but its SID is unavailable. Retrieve the SID using inventory APIs.
- The specified EVC endpoint ptp is unavailable.
- EVC endpoints on ME-Name could not be set.
- Category is not specified for the enableStatistics parameter.
- The FD fdName does not exist in the EMS.
- You have not entered a value for aEnd.
- Available endpoints on the ME ME-Name could not be retrieved.
- The FDFr name format is invalid.
- The operation failed because the VLAN IDs vlanIds are already configured under other service instances.
4.13.5 FD, MFD, and CPTP Error Messages
This section lists the FD, MFD, and CPTP error messages. The error messages appear if you enter invalid parameters or values. For valid parameters and values, see:
- CPTP Provisioning Interfaces
- MFD Provisioning Interfaces
- Flow Domain Provisioning Interfaces
- CPTP Inventory Interfaces
- MFD Inventory Interfaces
- Flow Domain Inventory Interfaces
The following are the error messages:
- An internal error occurred while reading rows from the Tbl_MATRIX_FLOW_DOMAIN_TABLE table.
- An internal error occurred while reading rows from the Tbl_FLOW_DOMAIN_TABLE table.
- An internal error occurred while reading rows from the Tbl_CONNLESS_TP_TABLE table.
- The FD fdName does not exist in the EMS.
- An unexpected error occurred while trying to retrieve the FD with user label userLabel from the EMS.
- The FD does not exist in the EMS.
- The ME ME-Name does not exist in the EMS.
- More than one MFD exists for the same NE/CPTP.
- The MFD mfdName does not exist in the EMS.
- The MFD is associated to an FD and thus cannot be deleted.
- The MFD is fixed and thus cannot be deleted.
- The MFD mfdName is not associated to the selected ME ME-Name.
- Some TPs are already associated to the existing MFDs.
- At least one TP is not a CPTP.
- Some TPs are in the unassigned PortTPRoleState.
- Some TPs are still being used by an FDFr.
- At least one TP is not assigned to the specified MFD.
- The CPTP name you specified is invalid.
- An FD with the name fdName was not found.
Feedback