Liaison statement
Connection migration

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.