Subject: Moving LSP ownership between control plane and management plane

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 Jul 2005 22:40:11 +0100

Hi,

You may not have seen this I-D because it lacks the "ccamp" element in its
name.

It discusses the issues for switching ownership of an LSP from the
management plane to the control plane and back again.

Can we have some comments from the CCAMP community (and especially from
the providers) on whether this function is necessary. Would you consider
deploying a control plane into an active network, or would you shut the
network (or at least the LSPs) for maintenance, and bring it (or them)
back up using the control plane?

The I-D also proposes a relatively simple solution and I would welcome
comments on this, too.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 30, 2005 11:50 PM
Subject: I-D ACTION:draft-caviglia-mp2cpcp2mp-02.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : GMPLS Signaling Extensions for the Transfer of
>                           Ownership of Label Switched Paths Between
>                           the Management and Control Planes
> Author(s) : D. Caviglia, et al.
> Filename : draft-caviglia-mp2cpcp2mp-02.txt
> Pages : 13
> Date : 2005-6-30
>
> During migration scenarios it may be desirable to transfer the
>    ownership of a Label Switched Path (LSP) from the Management Plane
>    (MP) to the Control Plane (CP), or vice versa. If the LSP is carrying
>    traffic this change needs to be made "in service," that is, without
>    affecting traffic.
>    This memo provides minor extensions to the Generalized Multi Protocol
>    Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized
>    Resource Reservation Protocol with Traffic Engineering Extensions),
>    to enable such transfer of ownership and describes the proposed
>    procedures.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-caviglia-mp2cpcp2mp-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-caviglia-mp2cpcp2mp-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-caviglia-mp2cpcp2mp-02.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------
------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: George Newsome <[email-masked]>
Date: Tue, 19 Jul 2005 07:44:29 -0400

Adrian,

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

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.

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.

Appended is an excerpt of the meeting report detailing some of the 
issues that need to be resolved before signaling need be considered.

Regards

	George

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.

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

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

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jul 2005 15:02:24 +0100

Thanks George,

Useful input.

> Q14 experts in January of this year.

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

> 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?

> up via the control plane, and to then delete the original management set

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

> 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?"

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

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

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

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

---

From: George Newsome <[email-masked]>
Date: Wed, 20 Jul 2005 05:03:00 -0400

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the 
moment to argue the toss, so I'll reply as a note rather than 
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and 
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly 
those who would like to see just that. Related questions are how many 
times in the life of the system might this be done for the same 
connection? Is it cost effective to develop a highly reliable solution 
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be 
useful, but a technical discussion of whether changing a bit (and a slew 
of procedures) in a signaling protocol actually provides the claimed 
facility.

Because of the effort the management system needs to provide before 
signaling might be involved, changing the signaling protocol gives the 
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane 
names, we can ask what happens to the cross connect object when it is 
deleted as part of the hand off procedure? The behavior of this object 
is that its deletion results in dropping the matrix connection, which is 
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely 
obfuscates the significant difficulties, which are glossed over by 
stating that those difficulties occur at a different time.

Regards

	George

Adrian Farrel wrote:

>>actions on the connection points as the control plane is about to take
> 
> over.
> 
>>the MP for migration, and from some reliable database in the recovery
> 
> case.
> 
> This is a valid point.