Subject: RE: Two Drafts for Resilience of Control Plane

From: <[email-masked]>
Date: Tue, 1 Nov 2005 10:10:44 -0000

Young, please see below....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kim Young Hwa
Sent: 01 November 2005 04:04
To: [email-masked]
Subject: RE: Two Drafts for Resilience of Control Plane

Hi,
 
First of all, I'd like to appreciate your sending and receiving
communication broadly as an initiator of this issue.
 
As most of people know about control plane,
it consists of control nodes, control entities, and control channels. 
Here, the resilience aspect of control nodes could be addressed in the
Igor's example 
or in the duplication of processor cards within a commercial product. 
The resilience aspect of control entities could be addressed in a
protocol itself with GR (graceful restart) capability. 
And, the resilience aspect of control channels could be identified a
link or concatenation of links carrying control packets.
 
Here, I believe that the resilience of control nodes, called controller
resiliency, 
belong to implementation issue (or H/W specific issue), not protocol
issue. 
And, the resilience of control entities belong to protocol issue. 
However, the scope of resilience in control entities exists between peer
control entities, not between physically adjacent nodes. 
Note that the resilience of control entities belong to only the protocol
because a control entity means a protocol that runs a specific function.

Some protocols could be run with soft-state nature, others could be run
with hard-state nature.
The decision on soft-state and hard-state is different from every
protocol to be applied.
 
Next is the resilience of control channels. 
It seems that this could belong to implementation issue as addressed by
Adrian.
However, if you see the resilience of control channels as implementation
issue,
I think that we don't need to consider more the resilience of control
channels in a protocol approach. But,
differently from data plane, control plane has various protocols to keep
their control relation.
Control channels addressed here are concerned with physically adjacent
nodes via direct and indirect connections.
And, there could be one or more alternative routes to transfer control
packets between physically adjacent nodes.
Let's look at an example network.

            ~~~~~~~~~~~~~~~~~~~
            |                 |
            |  Intra/extra    |
|-----------|  network for    |
|           | control plane   |
|           |                 |
| 5         ~~~~~~~~~~~~~~~~~~~
|                   |
|                   | 6
|        1          |         4
A-------------------B------------------C
|                   |                  |
|        2          |                  |
|--------------------                  |
|                                      |
|                   3                  |
|--------------------------------------|

Above the example, we assume that 1, 2, 3, and 4 control channels share
the fate with data channels, and 5 and 6 control channels are used to
transfer only control packets. And, the network for control plane could
have different capacity in real implementations.
Here, we can see several alternatives routes in conveying control
packets between physically adjacent nodes.
Between A and B nodes have the following routes.
 
     Route-1 : 1
     Route-2 : 2
     Route-3 : 3-4
     Route-4 : 5-6
 
I think that the resilience aspect of control channel should handle
reliable (and fast) transfer of control packets between specific nodes.
In the example between A and B nodes, these nodes should negotiate
active and standby control channels, protocols to be carried on a
control channel, and etc. In this sense, I believe that the resilience
of control channel could belong to protocol issue.
 
One of two draft that I proposed is a solution for the resilience of
control channel, which is based on a concept of the control network,
called common channel signaling system used in the traditional PSTN and
ISDN. 
 
NH=> Exactly so.  THE major thing you have to be sure of before you can
even start to consider this is the duct graph.  If you cannot get
physical disjointedness here then you can't even progress.  The
link-connections of the control/management plane network will, like any
other data-plane network, be carried on trails in a lower layer network.
You can use an IGP above this to attempt to provide some form of
resiliency or you could do what they did in C7 (which is also a
pkt-based network BTW) and have a simple load sharing algorithm across a
multiple parallel link-set....so if 1 link fails the rest just carry on.
Fast, simple, elegant and focussed at the right/relevant problem.  So
why not use this approach....as noted you have to start with having to
ensure the equivalent of disjoint link-set anyway, so use it directly.
Note also that 'adding' stuff generally reduces reliability....keep
things simple.  
 
regards, Neil
 
 Of course, there could be other solutions to solve the resilience of
control channel.
I don't think that the IP connectivity provides a means to be capable of
using these various routes.
For the resilience of control plane, the IP connectivity is a basic, and
additional works should be considered.
 
The other draft that I proposed is a requirement document for the
resilience of control plane, not the one of control channels.
In the requirement document, as a initial comment from Dimitri, I think
that the draft should cover protocol-neutral approaches, not protocol
specific ones. For examples, the various resilience aspects of control
nodes, control entities, control channels, and etc should be covered.
However, the current draft does not sufficiently cover the general
aspect for the resilience of control plane.
I think that these parts in the requirement document could be handled in
further version with help of ccampers who are interested in the
resilience of control plane.

Regards
 
Young.

<http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]
g&name=ccamp%40ops.ietf.org&fromemail=[email-masked]&messageid=%3C939
[email-masked]%3E>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Nov 2005 11:38:00 -0000

Hi Young,

Thanks for your thoughtful mail.

In focussing on control channel resilience you must answer why it is you
are not satisfied with the resilience provided by normal IP mechanisms.

For example, in your figure...

You correctly identify that there are several control plane routes from A
to B

>     Route-4 : 5-6

The option that most people currently consider is that they run an IGP in
the control plane. This would mean that a control plane signaling message
from the signaling controller at A to the signaling controller at B would
be placed in an IP datagram addressed to the control plane address of B.
It would be sent along the shortest open path from A to B (route 1). In
the event of a failure of link 1, the IGP would converge and the signaling
messages would be sent along the next shortest path (route 2). And so on.

This mechanism is not sensitive to whether multiple control channels use
the same duct or not since the IGP will converge just as well if multiple
control channels fail at once.

Note that load sharing between control channels is not recommended because
it will result in out of order delivery of control messages. Have a look
at all of the health warnings about the use of ECMP.

So I assume that one of three issues is worrying you.
1. You do not want to implement an IGP in your control plane
2. You do not want to handle IP forwarding in your control plane
3. The speed of convergence of the IGP is not good enough for the
    use you wish to make of your control plane.

Item 1. is an issue of complexity. I can see that it would reduce the
complexity of a network device and the control plane if you do not have an
IGP. But since you must run the IGP to exchange TE information, it is no
additional cost to use it to exchange control plane information. And, to
the contrary, by using the IGP you do not need any other mechanisms for
control plane resiliency.

Item 2. is an implementation issue. The forwarding does not have to be at
line speed. In general, software forwarding of control plane packets might
be considered adequate.

Item 3. would be interesting to hear about. Note that for most cases (such
as the switch from route 1 to route 2 in your example) there is no need to
wait for IGP convergence since it is the sending node (A) that notices the
failed link and can immediately update its routing table. Thus convergence
time is only an issue for less direct routes.

So I'd like to understand a little more what is motivating your work, and
why you think existing techniques are not sufficient.

> The other draft that I proposed is a requirement document for
> the resilience of control plane, not the one of control channels.
> In the requirement document, as a initial comment from Dimitri,
> I think that the draft should cover protocol-neutral approaches,
> not protocol specific ones. For examples, the various resilience
> aspects of control nodes, control entities, control channels, and
> etc should be covered.
> However, the current draft does not sufficiently cover the
> general aspect for the resilience of control plane.
> I think that these parts in the requirement document could be
> handled in further version with help of ccampers who are
> interested in the resilience of control plane.

OK. That sounds worth further investigation.

Thanks,
Adrian