Subject: [Pppext] Doubt in rfc 1990..

From: Hariharasubramanian CS <[email-masked]>
Date: Tue, 11 Oct 2005 11:55:39 +0530

I went through RFC 1990 (MP)...

It doesn't state clearly if IP packets MUST be encapsulated in
Multilink Headers....

There is roundabout statement in the RFC :

"Note that network protocols that are not sent using multilink headers
cannot be sequenced.  (And consequently will be delivered in any 
convenient way). "

 What is the ietf's stand ?
Can somebody cast some light?

Thanks
Hari.

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Oct 2005 03:41:26 -0400

it is perfectly legal to send some packets in PPP headers and some  
packets in Multilink headers.

You'll find my name in the Acknowledgments; I (among others) spent a  
lot of time and email in discussion with the authors getting this  
right. When we designed PPP Multilink, we recognized that there were  
applications that might send IP packets that were small enough to not  
need fragmentation and for which the delays imposed by the  
fragmentation and reassembly procedures might be detrimental - voice  
on IP being the obvious example. We explicitly chose to permit them  
to be sent around the multilink channel. I think you will find  
several implementations that literally do that. Cisco's is called  
"Low Latency Queuing" by the marketing folks.

---

From: James Carlson <[email-masked]>
Date: Tue, 11 Oct 2005 07:15:17 -0400

> packets in Multilink headers.

More generally, with most PPP options, successful negotiation of the
option allows but does not compel the sender to use the feature.

If you negotiate away the HDLC Address and Control fields, or use PPP
Protocol Field compression, or enable data compression via CCP, you
may still send uncompressed data if you have a need to do so.

The exceptions are fairly rare and straightforward, such as the use of
ECP, where unencrypted packets are very likely to be dropped by the
receiver for security reasons.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677