Re: Moving LSP ownership between control plane and management plane

["Adrian Farrel" <adrian@olddog.co.uk>]

Thanks George,

Useful input.

> You asked for comments on this proposal, which was presented to ITU-T
> Q14 experts in January of this year.

Can you confirm that there were plenty of providers represented at the
meeting.

> There are so many issues involved in moving a connection from the
> management plane to the control plane that involve intensive management
> action, that it is not evident that signaling need be involved at all.

Interesting. It is certainly valuable to have a list of these issues out
in the open. I have made some comments in the appended meeting report.

If the control plane is to take over the connection then we assume that
signaling state must be built so that the control plane could then modify
or tear down the connection. how would you propose that this be done
without involving signaling?

> As a personal opinion, it makes little sense to consider moving the
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original management set
> up connection.

The question arrises of how this would be done in a network with limited
resources. That is, if it is possible to set up a parallel conneciton then
the method you describe would be fine, but if there are not enough
parallel resources then would you propose that a lambda (for example)
could be used for the management-established connection and for the
control-plane-owned connection at the same time? This might present some
difficulties as well.

Do you have an opinion on my main question which is whether this tyoe of
change-over would ever be done in service?

Thanks,
Adrian

> Excerpt of the meeting report of Q14 Experts, January 2005
>
> WD06 (Marconi) "G.7713 Modification in order to support Circuit
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
> the concept of Call/Connection setup to setup/adopt and release to
> release/de-adopt. In Connection Adoption both the SNC are not actually
> created and the LC are not actually established due to the fact that the
> underlying physical resources are already in place. In the
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
> only the Control Plane information associated with then is removed and
> the ownership is moved to Management Plane. Attributes for indicating
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
>
> The discussion was mainly on the Management plane and Control plane
> actions required before signalling is involved. The group noted that the
> following issues need to be addressed:
>
> - Naming of transport resources to the control plane.  Before a call can
> be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no
> explicit route can be formed to match the resources of the connection.

This is pretty obvious. But actually, this is an issue with moving the
resources from one plane to another (or having them present in both
planes). It is certainly a prerequisite for moving the connection, but it
is not functionally an element of moving the connection.

The draft, as I read it, assumes that these operations have been completed
and then asks "how do I move the connection from one plane to the other?"

> - Resource state while under dual CP and MP views.  After resources are
> given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the
> resource to indicate that the management plane cannot perform some
> actions on the connection points as the control plane is about to take
over.

Yes. There is certainly scope for a race condition here. I believe that
the I-D proposes to (try to) make the transfer an atomic action from the
point of view of the change-over.

Note, however, that it is wrong to assume that a resource belongs only to
the control or to the management plane at any moment in time. This may be
true with respect to the ability to provision/control connections, but
resources that are available for use by the control plane can still be
managed through the management plane. Thus, you take a laser out of
service through the management plane, not through the control plane.

> - Role of discovery functions (esp. CELA).  After control plane names
> are allocated, distributed control plane functions need to be associated
> and communication adjacencies formed.  This too is a precursor to any
> signalling procedures in migrating from the MP to CP.

Note to CCAMP: CELA is Control Entity Logical Adjacency.
This too is "obvious".
But this discussion seems to be wide of the mark. Before deploying a
control plane, it is clear that this type of operation needs to take
place. Since (within the context of CCAMP) a control plane *is* going to
be deployed, we can assume this operation and move on to the discussion in
the draft.

> - Similarity of migration to synchronization after CP failure and
> subsequent recovery.  Connection control procedures might be the same in
> migrating a call from the MP to the CP as the situation when the CP has
> failed and is recovering.  Here, the network connections are already in
> place, but connection and call state need to be created to match it.
> Knowledge of the call and what the connection should be is obtained from
> the MP for migration, and from some reliable database in the recovery
case.

This is a valid point.
Control plane failure, however, is unlikely to be total. That is, it would
be unusual for more than one control plane link or node to fail. Thus, in
the control plane, the "reliable database" is distributed and recovery can
follow the procedures outlined in draft-ietf-ccamp-rsvp-restart-ext-03.txt

It would certainly be worth considering whether the procedures used for
control plane recovery could be applied to transfer of ownership from the
management to control plane. at the moment, I suspect that they could not
because the restart extensions assume a specific period during which
signaling is associated with recovery.

We would also need to look at the reverse process (transfer from CP to MP)
that is not possible to cover by CP restart procedures.

> - Call awareness of migration vs. connection being unaware of migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require awareness of
> why this is happening as the context could be migration or recovery.  A
> mechanism to create control state without affecting transport plane
> state is needed in the CCs.  Call controllers though do need migration
> awareness as they need to obtain/derive call identification from the MP.

I disagree.
Connection controllers must be able to distinguish between resources that
are already in use and cannot be assigned to a new connection, and those
that are already in use and can be assigned to a new connection because
the connection is replacing an existing connection. If this were happening
entirely within the control plane we would use resource sharing, but when
the operation spans the control and management planes resource
ownership/sharing is more complex and the conneciotn controller needs to
be able to issue the approriate instrucitons for the assignment of the
resources.
On the other hand, call controllers do not need awareness of the details
of the realisation of the connections.

> In summary, the group decided that it is premature to consider
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to expose in a
> larger context the interaction between CP and MP for connection
> migration. The above issues were included in SP24 of the G.7713 Living
> List (see WD22).