Liaison statement
Connection migration

State Posted
Posted Date 2005-11-25
From Group ITU-T-SG-15
From Contact Greg Jones
To Group ccamp
To Contacts kireeti@juniper.net
Ccsob@harvard.edu
fenner@research.att.com
zinin@psg.com
ccamp@ops.ietf.org
maeda@ansl.ntt.co.jp
sjtrowbridge@lucent.com
Response Contact tsbsg15@itu.int
greg.jones@itu.int
Technical Contact hklam@lucent.com
betts01@nortel.com
Purpose For information
Attachments Connection migration
Body
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.