[j-nsp] MLPPP Overhead Question

[EVAN WILLIAMS]

i have always found this to be a excellent resource, when looking into the operation and format of protocols. In general not much meat but enough in the morsel to help.
http://www.protocols.com/pbook/ppp4.htm#MultiPPP

hope this may but as useful for you as it has been for me, and still is.

Evan 


Scott Weeks <surfer at mauigateway.com> wrote: 

--- bbird at dream2cook.com wrote:----------------
On Thu, 28 Jun 2007 14:54:44 -0700, "Scott Weeks"  wrote:

>I'm searching the web for data on the overhead of using MLPPP and 
> not having too much success.  If I'm gluing two T1s together do I 
> still get 1.536 times two or is there impact on this from the MLPPP?

Enabling MLPPP will not change the clock-rate of the constituent-links.  
But the PPP frame overhead will be increased by either 4 or 2 bytes, 
per multilink fragment.  This depends on whether long or short sequence 
number fragment format is negotiated for the bundle.

See RFC 1990, section 3.
----------------------------------------------------



I knew it wouldn't "change the clock-rate of the constituent-links", but I was unaware of the "PPP frame overhead will be increased by either 4 or 2 bytes" part.  I had found things on old NANOG posts like "...PPP framing overhead is close to negligible...", done some stoopid math and I wondered what the extra impact would be caused by what I now understand is called the MP header.  I read the part of the RFC you mentioned to get that name.  So, the 30000 foot level is that impact is probably even less than "close to negligible"... :-)

Thanks,
scott














_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp