[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
Dear Michiel,
Sorry for the delay in the reply, please see comments in-lined.
Thanks
Regards... Zafar
At 05:57 PM 4/29/2002 +0200, Michiel van Everdingen wrote:
Hello Zafar,
> > 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]
>
> The notify message with the above mentioned option is also sent over
the
> control network, like other signaling messages. I did not see
the
> relationship here. Can you please elaborate a bit further why you
are
> mentioning this here?
You talk here about "control network". I tried to focus on the
"network"
part in that "control network".
From a.o. the following sentences of the LMP draft, I deduce that
"control channels" are only present between two nodes that are
neighbors
at the transmission plane:
Yes, this is correct. Control channels are between the LMP peers running
on the adjacent nodes. But please note that such nodes may not be
adjacent in the control network topology.
"This draft specifies a link
management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links."
"In GMPLS, the control channels between two adjacent nodes
..."
However, it seems that not all signaling messages are between
adjacent
nodes (adjacent at the transmission plane). I used the "notify
message"
as an example: "The Notify message provides a mechanism to inform
non-
adjacent nodes of LSP related events" [RSVP-TE, section
4.3].
The notify message can be sent as an IP packet over the control network,
whose processing will be similar to the similar ResvConf
message. In the case you like to avoid a L3 entity (RSVP) to be
involved at each hop, the option of encapsulating them in a
new IP header whose destination is equal to the target IP address can be
used, as you quoted in your email.
So, assuming a "control network" is
built from "control channels",
No, instead I would say that control channels are established over a
control network.
this
"control network" needs to be able to route signaling messages
through
a series of "control channels".
No, it's the applications (e.g., LMP) that have a view of the control
channels; the network does not know about them or does not use them in
routing.
This makes it a real network
layer in my
mind, with associated routing protocol etc.
> > 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 ?
>
> No, I don't think so. Just because we've a peer to peer protocol
for
> detecting health of the control channels, IMO, does not mean that
we've
> introduced an extra "network layer". Control network is
still managed
> like any other (IP) network.
As mentioned above: I assumed that a "control network" is built
from "control
channels".
No, please see comments above.
If this assumption is correct: I
think we are building a "control network" (L3)
on top of "control channels" (L2). "Control channels"
(L2) make use of any
generic network layer (L3, e.g. DCN).
If this assumption is wrong: I can now only deduce that "control
channels"
are a kind if "ping" mechanism to detect point-to-point
aliveness of the
"control network".
I would like to refer to Jonathan's reply to this.
Please consider the following very simple
topology:
+-----+
+-----+
| | ...................
| |
| A
|
| B |
|
|
| |
+-----+
+-----+
\
.
. /
\
.
. /
\
.
. /
\
.
. /
\ . . /
\ . +-----+ . /
\ .| |. /
\ | C | /
| |
+-----+
....: DCN topology (e.g. using a LAN connection between A&B)
----: transmission topology (the "dataLink"s)
In case the fibre A-C (with associated DCC channel) breaks, the DCN
network can still find a path between A and C: A-B-C. Correct ?
So in case of such a fibre failure, you would say that the (routed)
"control channel" is still alive. Correct ?
If "control channels" are nothing more than the standard
"ping" mechanism,
why not use this standard "ping" mechanism
?
Again, I would like to refer to Jonathan's reply.
If "control channels" does provide
more than standard "ping", could you
please let me know what that would be (and why that would be
mandatorily
needed) ?
I think I first need clarity on the relation between "control
network" and
"control channel" before being able to comment on your other
points.
Thanks !
Michiel
<snip>
<...snip...>
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com