|From Contact||Greg Jones|
At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. - Links must be pre-configured and made visible to control plane routing. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem.