[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
Hi Michiel,
Please see some comments in-lined.
Thanks
Regards... Zafar
At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
Hello Manoj, Ravi, Jonathan, Zafar,
I'm somewhat confused on the state of this thread. As far as I
can see, the following questions are still open:
- why is control channel management needed at all
?
The control channel failure detection mechanism is required
if lower-level mechanisms are NOT available to detect control channel
failures. E.g., when control channel is (IP) routed and not bound with
a particular interface. Furthermore, a control channel failure is an
event on which applications are interested in from various prospective.
E.g., we would like to distinguish between signalling channel failure and
control channel failure during RSVP-TE recovery process, etc.
- why does control channel management need to
be fast ?
A note on the frequency of LMP
Hellos: Please note that we need to distinguish between a signaling
channel failure and the control channel failure. Hence, LMP Hellos should
be faster than RSVP Hellos or the mechanism used to detect signaling
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.
- is control channel management fast
?
I think the LMP Hello frequency need to follow the above
mentioned criteria. By fast, do you mean O(milliseconds)? If yes, I don't
think LMP Hellos need to be "fast".
As stated in section 13 of the LMP draft, all
LMP messages are
IP encoded. So a standard general purpose IP network should
perfectly well be capable to transport such IP encoded LMP
messages to the intended destination. Am I missing something
here ?
I am sorry but I did not understand what you meant here?
One of the advantages of using a general
purpose IP network is
that there is no need for a point-to-point direct communication
channel between sender and destination. point-to-point direct
communication can become a problem, e.g. when the dataLink is a
VC-12 or a VT-1.5.
Moreover, control channel management seems to give unnecessary
overhead in case there is only one interface between two
neighbouring switches.
IMO when control channels are interface bound (i.e., failure
of the interface means failure in the control channel) and L2 mechanism
are available to for failure detection, we can run LMP Hellos at a lower
frequency and rely on L2 control channel failure detection. But please
note that this is not always the case that your control channel are bound
to a particular interface (e.g., IP routed control channels), hence the
need for failure detection within the scope of LMP.
Just for my curiosity: has MultiLink-PPP
(RFC1990) been considered
as alternative for "control channel management" ? This seems
to
logically extend the current stack used for IP over DCN. From
ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
framing shall be used as the data-link layer protocol."
Regards,
Michiel
Zafar Ali wrote:
>
> At 03:22 PM 4/15/2002 +0530, Manoj Sontakke wrote:
>
> > Hi Jonathan,
> >
> > Thanks for the quick response. Please see my comments
inline.
> >
> > Manoj
> >
> > Jonathan Lang wrote:
> > >
> > > Manoj,
> > > Please see inline.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Manoj Sontakke
[mailto:manojs@sasken.com]
> > > > Sent: Thursday, April 11, 2002 7:02 AM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Question on LMP.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have two questions on LMP.
> > > >
> > > >
--------------------------------------------------------------
> > > > -----------------------------
> > > > Q1. Control Channel Question
> > > >
> > > > Assuming a configuration as shown.
> > > >
> > > >
> > >
>
-----------------
-----------------
> > >
>
|
|
|
|
> > >
>
|
if1|---------------|if1
|
> > >
>
|
if2|---------------|if2
|
> > >
>
| OXC 1
|
| OXC 2 |
> > >
>
|
d1|---------------|d1
|
> > >
>
|
d2|---------------|d2
|
> > >
>
-----------------
> > > > -----------------
> > > >
> > > >
> > > > I have two OXCs connected by four links. Consider d1,
d2 are configured
> > > > to carry data and if1 and if2 are configured to carry
control data ( LMP
> > > > messages and RSVP and OSPF messages).
> > > >
> > > > The LMP document defines control channels with an
unique identifier (
> > > > control channel identifier ) between the negibouring
nodes.
> > > > So also, the LMP messages are IP encapsulated.
> > > >
> > > > Now, I have a couple of questions
> > > >
> > > > 1. Is there any association between the LMP control
channels to the
> > > > physical interfaces( if1, if2). Because all the IP
packets are routed on
> > > > the physical interfaces according to the routing
table. The control
> > > > channel messages like ( config and configAck
etc.. ) can go on the any
> > > > physical interface which is decided by the routing
table.
> > > >
> > > > In such case, are the control channels a pure logical
concept or do they
> > > > have any physical interface significance &
correlation [ mapping between
> > > > control channles ( ccid ) and interfaces ( if1 and
if2 )] ?
> >
> > > Control channels are associated with interfaces.
> >
> > Manoj-> The draft does not say so explicitly. Besides, all
the LMP
> > messages are IP encoded. So the routing table decides the
outgoing
> > interface for sending the LMP messages (any packet for that
matter)
> > depending upon the destination IP address.
> >
> > So is it possible to make such an association between the LMP
control
> > channel and a physical interface (though it is
desirable)?
>
> Hi Manoj, et all:
>
> The association between the CC and data bearer link is neither
prevented nor enforced by the specification, as you also mentioned. IMO,
the association between the CC and data bearer link is a vendor specific
question. Vendors can manage the available set of CCs in the way they
would like to.
> I.e., a vendor may choose a specific CC to send all messages that
are pertaining to a data bearer link, etc. The key is that the receiver
node for the LMP messages should be able to receive LMP messages from any
CC that it’s running with a given neighbor. This is of course with the
exception of
> LMP Hellos messages.
>
> > Are we
> > deviating from the standard IP implementation ?
>
> In selecting the CC by making an association between the CC and the
data link, one will NOT be diverting from IP. Specifically, one may
consider CC to be of two different types: interface bound or routed.
E.g., SDCC/ LDCC based CCs can be regarded as interface bound IPCCs. LMP
application can
> select a specific egress interface while using interface bound CCs,
etc.
>
> Thanks
>
> Regards… Zafar
>
> <snip>