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

From: Y Prasad <[email-masked]>
Date: Tue, 23 Feb 2010 15:32:26 +0530

Hi 

Can you please help me to understand how LCP echo request/response can
be supported on a bundle? 

Page no.4 of RFC 1990 says below.

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.

"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?

Regards

yp

---

From: James Carlson <[email-masked]>
Date: Tue, 23 Feb 2010 09:34:34 -0500

Y Prasad wrote:
> “Bundle interface is a virtual interface. If there has to be LCP keep

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         <[email-masked]>