The CTP can be mapped and currently is (i.e., it has contained actual CTPs). This indicates that the G.805 CPs adapted from the corresponding G.805 Termination Function within the CTP aggregate are available to provide client layer capacity (e.g. STS1 terminated and mapped to VT1.5 i.e. channelized). In this state the TCP will be sourcing and sinking traffic. This is only a valid value for CTPs that support client adaptation.

The FTP can be mapped on the server side and currently is (i.e., it has contained actual CTPs on the server side). This indicates that the FTP supports IM (Inverse Multiplexing) and the server side contained CTPs (if any) are available for connection as the FTP is actively assembling the fragments of the IM. This value is not valid for an FTP that does not support IM. (see layering for more details).

For ATM VP or VC CTP this value is used to model a VPC or a VCC terminating within the Managed Element (i.e. internal VP or VC Trails). Such a terminated ATM connection is used as a trail acting as a server for upper layer protocols (e.g., VCCs in case of a VPC TP,Frame Relay in case of a VCC TP). In the two switching layer ATM model, the VP layer acts as the infrastructure on which VC Connections (either PVC, SPVC or SVC) are routed and switched. This capability allows the operator to build a logical partitioning (VP overlay) of the physical ATM network by configuring VPCs (or VP "tunnels") which are terminated inside the subnetwork. Such overlay VP network allows operators to aggregate and segregate VCs according to their traffic management policy. In addition, the use of an intra-subnetwork VPC may provide for enhanced protection of the VC traffic by using 1+1 VP protection (VP protection is not supported in this release of the EMS-NMS interface). In order to be able to make routing decisions at VC level (e.g., explicit route constraint), the NMS needs to know the VP topology available from the ATM network.

Readable by NMS? Yes
Writeable by NMS? No
Invariant? Yes
