[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
Hello Zafar,
Please allow me to summarize my understanding of our discussion thus
far.
LMP's "control channel management"
- Is an extra, new protocol on top of an existing IP network.
That is what I understand when Jonathan writes "You could certainly
create an LMP control channel through a DCN network. In fact, this
is probably the preferred configuration."
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
- Needs careful setting of hello frequency.
This is based on your comment: "LMP Hellos should be faster than RSVP
Hellos or the mechanism used to detect signalling channel failure.
Similarly, LMP Hello frequency should be greater than IGP hello frequency,
so that the optical network can make "conscious" decision on the control
channel failure, before having an adverse affect on the IGP adjacencies at L3."
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html
- Provide a fast recovering transport mechanism for "signalling channels"
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html
Furthermore, there is a need to route packets through a network consisting
of "signalling channels": the RSVP-TE "notify message" is sent between
non-adjacent (at transmission plane) nodes in case it is "encapsulated
in a new IP header whose destination is equal to the target IP address."
[RSVP-TE, section 4.3]
So in other words, the proposal is to create an extra "network layer"
(OSI terminology) consisting of "signalling channels". These "signalling
channels" make use of underlying "control channels" which again can make
use of any generic network layer (e.g. DCN). Correct ?
I agree with you that we need to carefully look at the "hello" frequencies
of these network layers. Probably some consideration is also needed for
hello-timers on datalink layer and hold-off timers at transport layer.
All together, my feeling is that this is getting quite complex.
Are we sure we want to go in this direction ? Can't we simply remove
the whole "control channel management" mechanism and define "control
channel" as follows:
control channel = a facility that interconnects two switching neighbours
at the transmission plane for the purpose of exchanging control messages.
This facility can be in-band or out-of-band; point-to-point or multi-point.
If we would accept this definition, a DCN network (or better: SCN network)
can be an implementation to have control channels between all neighbouring
nodes at the transmission plane.
If we have to go on discussing "control channel management", I think we
still have the following open questions:
- why does control channel management need to be fast
- is control channel management fast
On your email:
> I don't see if we can cover all cases of control channel failure detection
> after removing this functionality from LMP (e.g., the case of routed control
> channels or control channels where L2 failure detection is not feasible).
Hopefully someone on this mailing list can show us a case in which a standard
IP network is not sufficient for the control plane...
> LMP will be using UDP, as indicated in an earlier email from Jonathan.
Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask if
we could add neighbour discovery in LMP and to get clarity on the use of
"control channel management". Guess I was somewhat naive to think that that
could easily be settled....
> > Indeed. In some cases L2 detects the failure, in other cases L3 detects
> > the failure. Still confused as to why we can't stick to standard L3
> > mechanisms to detect the failure...
>
> Can you please elaborate on what "other" L3 mechanisms you're referring to
> here? How would you cover the case of an IP routed control channel?
I did not speak about "other" L3 mechanisms. Just standard L3 mechanisms.
> I think the WG has already agreed upon the control channel management
> procedure within the scope of LMP. I am not sure what is the value of
> this discussion at this point. I'll let some one else comment on it.
Personally, I found our discussion very useful. Thanks for the to-the-point
answers !
Best regards,
Michiel
Zafar Ali wrote:
>
> Hi Michiel:
>
> Please see comments in-lined.
>
> Thanks
>
> Regards... Zafar
>
> At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:
>
> > Hello Zafar,
> >
> >
> > > > I'm still confused as to why standard network layer mechanisms would not
> > > > be sufficient.
> > >
> > > I think this answer depends on how we define sufficient;-)
> >
> > As control channel management is a mandatory part of LMP, I would define
> > "sufficient" as "minimally needed to run LMP" or maybe "minimally needed
> > to run GMPLS".
>
> I don't see if we can cover all cases of control channel failure detection after removing this functionality from LMP (e.g., the case of routed control channels or control channels where L2 failure detection is not feasible). Please note that control channel failure detection is currently a
> requirement for the GMPLS framework, which is already agreed upon, AFAIK.
>
> > > LMP control channel management brings some features into picture, e.g.,
> > > when we’ve hidden control channels, how can we guarantee that the neighbor
> > > is listening to the channel we’re sending your control messages to? With
> > > the configuration handshake, LMP guarantees that the two ends are ready
> > > to exchange messages on the control channel in question.
> >
> > I guess control messages will use either TCP, UDP or IP. Correct ?
>
> LMP will be using UDP, as indicated in an earlier email from Jonathan.
>
> > In case of TCP, I'm assuming TCP's connection establishment phase takes
> > care that the neighbour is listening.
> >
> > In case the control messages are sent using UDP or IP, I agree that the
> > application has to make sure that the neighbour is listening. For the
> > LMP control messages this seems no problem as they are acknowledged
> > anyway by LMP (e.g. linkSummaryAck for the linkSummary message). The
> > application can then simply resent the message until it receives a
> > '(N)Ack'.
>
> Yes, also this is because LMP does not assume a reliable transport for the control traffic (over the control channel).
>
> > > Similarly, it provides a way by which failure on a routed control
> > > channel (control channel is not bound to a physical interface) or a
> > > control channel where L2 cannot detect the failure.
> >
> > Indeed. In some cases L2 detects the failure, in other cases L3 detects
> > the failure. Still confused as to why we can't stick to standard L3
> > mechanisms to detect the failure...
>
> Can you please elaborate on what "other" L3 mechanisms you're referring to here? How would you cover the case of an IP routed control channel?
>
> > > Without LMP control channel management, how you would suggest
> > > management and health check for such control channels? Skipping
> > > such tests will IMO lead to a more ad hoc procedures/ protocols.
> >
> > See above.
> > For inter operability reasons, we could specify which mechanism has
> > to be used as a minimum (e.g. I-ISIS ?). Additional mechanisms
> > (like MPLS protection, ML-PPP, ...) are then optional.
> >
> >
> > > Signaling channel is a term I used to specify the following:
> > > Signaling channel is the logical channel over which signaling
> > > (say RSVP-TE) messages are exchanged between RSVP peering entities.
> > > The signaling channel is realized using the collection of all
> > > control channels between the two RSVP peers.
> > > A signaling channel failure could be the result of the concurrent
> > > failure of all control channels or the failure of one of the peering
> > > signaling entities or one of the peering nodes. Hence, signaling
> > > channel failure is different than failure of all control channels.
> > >
> > > Using the above mentioned definition, a nodal failure always imply
> > > the failure of the signaling channel as well as control channels.
> > > However, failure of the last control channel does not imply a nodal
> > > failure. For the sake of completeness, a signaling channel failure
> > > could be due to failure of the
> > > peering RSVP process or due to the neighbor node failure. The
> > > draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
> > > failure to cover both cases: i.e., the case where peering RSVP
> > > entity restarts or the entire node fails. In either case, non-stop
> > > forwarding is assumed. In short, failure of
> > > the last control channel is different from the nodal failures.
> >
> > Thanks for the definitions !
> >
> > Just to check: a signalling channel failure is different from a nodal
> > failure. A nodal failure implies a signalling channel failure, but not
> > the other way around. Correct ?
>
> Yes, failure of a peering signaling process also leads to signaling channel failure.
> But, the actions taken in the restart procedure are the same, for the obvious reasons.
>
> > In these definitions, how would an RSVP-TE "notify message" be sent
> > between non-adjacent (at transmission plane) nodes in case it is
> > "encapsulated in a new IP header whose destination is equal to
> > the target IP address." [RSVP-TE, section 4.3] ? Is it routed
> > over a series of signalling channels ? By which routing protocol ?
> >
> >
> > > In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP recovery
> > > procedure treats nodal failure and control channel failure differently
> > > (please see above for how they are related to the failure of the
> > > individual processes).
> > >
> > > I think what you’re proposing is that we don’t need to distinguish
> > > between the two and we can always apply the signaling channel failure
> > > (draft uses the term nodal failure to refer to a more general case)
> > > mechanisms, even in the case of control channel failure?
> >
> > My proposal would be to use non-GMPLS specific mechanisms to route
> > control packets to the intended destination.
> >
> >
> > > Clearly in the absence of LMP, failure of all control channels can
> > > only be detected by the signaling layer, hence will be treated as
> > > nodal failures. However, with failure detection on the control channel,
> > > we can do a better job in recovering.
> >
> > Could we agree that the whole "control channel management" mechanism
> > is only for faster recovery of the control plane ? The idea would be
> > that failure of one control channel does not change the topology of
> > the control plane as the associated signalling channel does not get
> > affected.
> >
> > If we could agree on this understanding, I would still opt for non-
> > GMPLS specific mechanisms.
>
> I think the WG has already agreed upon the control channel management procedure within the scope of LMP. I am not sure what is the value of this discussion at this point. I'll let some one else comment on it.
>
> <snip>
> ===============
> Zafar Ali
> Cisco Systems
> (734) 276-2459
> 100 S Main St. #200
> Ann Arbor, MI 48104.
> email: zali@cisco.com
--
+------------------------------------------------------------------+
| Michiel van Everdingen |
| Systems Engineer |
| Lucent Technologies - Optical Networking Group |
| Botterstraat 45, 1271 XL Phone : +31 35 687 4883 |
| P.O. Box 18, 1270 AA Fax : +31 35 687 5976 |
| Huizen, The Netherlands mailto:MvanEverdingen@lucent.com |
+------------------------------------------------------------------+