[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on LMP.



Hi All,

Q. What does the control channl management achieve?

A. 1. IP reachability confirmation.
   2. Negotiation of Hello and Dead intervals.

I don't see anything else being achieved by the control channel
management.
Now, lets try to answer the questions.

Regards,
Manoj


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 ?
> - why does control channel management need to be fast ?
> - is control channel management 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 ?
> 
> 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.
> 
> 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>