[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
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".
> 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 ?
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'.
> 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...
> 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 ?
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.
Best regards,
Michiel
Zafar Ali wrote:
>
> Hi Michiel,
>
> Please see comments in-lined.
>
> Thanks
>
> Regards… Zafar
>
> At 11:47 AM 4/24/2002 +0200, Michiel van Everdingen wrote:
>
> > Hello Zafar,
> >
> >
> > > No, I think the main source of confusion is that LMP Hellos are NOT the
> > > only thing that is part of the control channel management.
> >
> > What else ?
> > Control Channel Management seems to only set up a communication mechanism
> > (in the control plane) between two nodes that are neighbours at the
> > transmission plane, i.e. that are neighbours regarding dataLinks.
> > Also, if I look at the definition of the config messages, I can only find
> > parameters that deal with this communication mechanism.
> >
> > 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;-) 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.
>
> 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. 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.
>
> > > > Is there a need to distinguish between signalling channels and control
> > > > channels ?
> > >
> > > Yes, e.g., RSVP recovery procedure differentiate between the control
> > > channel failures and the signalling channel (Nodal) failure.
> >
> > My understanding is that a nodal failure "relates to the case where a node
> > losses its control state (e.g., after a restart) but does not loose its data
> > forwarding state."
> >
> > A nodal failure is therefore something else than a failure in a communication
> > mechanism. Correct ?
> >
> > Why do you relate nodal failure with the failure of a communication
> > mechanism (the 'signalling channel') ?
>
> 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.
>
> > > > Can't they make use of the same IP network ?
> > >
> > > Yes, they use the same IP (Control) network, but there are differences in
> > > the two failure cases, e.g., when a peering RSVP process fails vs. peering
> > > LMP process fails, control channel(s) failure due to peering node failure
> > > vs. control channel(s) failure due to an event that made neighboring node
> > > unreachable, etc.
> >
> > Is there a (mandatory) need to distinguish between a failure of the RSVP-TE
> > process and a failure of the LMP process ? I guess in a lot of cases they fail
> > together (e.g. in case of a nodal failure).
>
> 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? 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.
>
> > Why are process failures related to communication channel failures ?
> > This might indeed lead to the need for two distinct communication
> > channels ('control channel' and 'signalling channel'), which seems to be
> > a disadvantage to me.
>
> Please see my definition of a signaling channel failure in the above. I'm sorry that the absence of the definition in the earlier email caused some confusion.
>
> > > When we lose the last control channel with a given neighbor, we lose LMP
> > > adjacency with that neighbor. This is an event that IMO requires proper
> > > treatment from GMPLS control plane.
> >
> > I'm only arguing that standard network layer mechanisms can handle
> > loosing some links in the control plane. We don't need - in my mind -
> > something specific for LMP.
> >
> >
> > Thanks,
> >
> > Michiel
> >
--
+------------------------------------------------------------------+
| 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 |
+------------------------------------------------------------------+