Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)

[Y Prasad <[e-mail]>]

Thanks for the response, James.

I think there is a room for compliance issue with regard to LCP keelp
alives on the bundle.

RFC1990 page 5:
-------------
   LCP negotiations are not permitted on the bundle itself.  An
   implementation MUST NOT transmit LCP Configure-Request, -Reject,
   -Ack, -Nak, Terminate-Request or -Ack packets via the multilink
   procedure, and an implementation receiving them MUST silently discard
   them.  (By "silently discard" we mean to not generate any PPP packets
   in response; an implementation is free to generate a log entry
   registering the reception of the unexpected packet).  By contrast,
   other LCP packets having control functions not associated with
   changing the defaults for the bundle itself are permitted.  An
   implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-
   Request, Echo-Reply and Discard-Request Packets.
--------------

It says LCP echo-req/reply on the bundle is optional. Assume that an
implementation sends LCP ECHO req. on the bundle and the remote chooses
not to reply (as it is optional) then sender would likely to drop the
bundle. Perhaps mentioning one of the following clauses help.

 1. Let the peer negotiate "LCP-echo req on the bundle" during LCP req
and subsequently send LCP echo req on the bundle only if it is accepted
by the remote peer.

OR

 2. Sending LCP ECHO-req on the bundle is option. But LCP ECHO-reply on
the bundle need to be mandatory.

First choice above would be more appropriate as there might be already
installations that would not send lcp-echoreply-on-the-bundle.

Regards
yp

-----Original Message-----
From: James Carlson [mailto:[e-mail]] 
Sent: Tuesday, February 23, 2010 8:05 PM
To: Y Prasad
Cc: [e-mail]
Subject: Re: [Pppext] LCP echo request/reply support over multilink
interface (RFC 1990)

Y Prasad wrote:
> "Bundle interface is a virtual interface. If there has to be LCP keep
> alive on it, it has to go through one of the underlying physical
links.
> But LCP keep alive packet format does not seem to specify any
interface
> details. How does the remote identify that the LCP echo received on a
> physical link belongs to bundle?

If you run those non-negotiation LCP messages on the bundle, they may
need to be encapsulated using RFC 1990 fragment headers if you want to
segregate bundle and link level traffic.  You're not required to do
that, though.

In general, this is more of an implementation issue than anything else.
 For example, you need to inspect LCP Protocol-Reject messages to
deliver them properly.  If the rejected protocol is one of the few
per-link protocols, then it should be handled at the link level.  If
not, then it should be communicated upwards to the bundle head for
processing.

Some implementations will deliver LCP errors at the link level that are
targeting problems detected at the bundle level.  You must be prepared
to handle that.

In the case of LCP Echo Request, if you implement that only at the
bundle level, then you can send requests without encapsulation and
simply have all of the received LCP Echo Reply messages forwarded up to
the bundle head.  If you implement only at the link level, then process
them there, again without encapsulation.  In short, since you know how
you send your requests, you can decide how you want to process the
replies.  (And since implementing at both levels at the same time would
likely not serve much of a purpose, it would probably be wise to choose
one and stick with it.  I'd recommend link-level, as it's links that
usually run into trouble, but it's your code ...)

Note that packets sent at the bundle level are _not_ required to have MP
fragment headers.  Using those headers guarantees ordering and
reassembly where needed, but it's not a requirement -- either for
signaling messages or for user data.

The only special action needed to ensure interoperability is that when
an implementation receives a bare LCP Echo-Request, it must reply on the
same link.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>