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).