[Pppext] Proposal to solve ML-PPP ambiguity

[Vineet kumar Garg <[e-mail]>]

Hi All

While working with ML-PPP over some time, I have come across some problems which I think should be solved at the protocol level. Please review the abstract below and let me know your valuable opinions:

As per existing RFC, following are the key characteristics of LCP negotiation for multi-link parameters:

•       MRRU option is considered as mandatory option for a link to join a MC/ML-PPP bundle
•       Endpoint discriminator is optional and can be used to identify different PPP peers
•       Short-sequence number as an option is negotiated as part of LCP although same value has to be negotiated on all the links

        Problem that current protocol creates is that it allows a scope for bundle level parameters to be negotiated with different values on different links. This leads to an implementation ambiguity about which values to be chosen for the bundle. Some of the ways applications can implement this choice are:
                                        - Choose the negotiated value from the latest link that came
                                        - Choose the first value that was negotiated
                                        - Choose the one matching operator configuration etc.

Is there already a solution to this problem as part of protocol that I am missing?

-> Proposed solution

          Since the bundle level parameters like MRRU & sequence number length are applicable to all bundles in a link, it is better to negotiate them like an NCP after LCP has already been done. So, like other NCP protocols, there can be a new protocol called ML-CP which will configure all bundle level parameters for all the links in the bundle. This will remove the ambiguity about choosing the values of bundle level parameters and also prevent different values being negotiated for same parameter in case of some mis-configuration.

          However, still there is a need to have some parameter in LCP which determines the bundle association of a link. In order to do that we can use endpoint discriminator as a mandatory option in LCP for links which want to join a bundle.

Maintaining backward compatibility with existing implementations might be a challenge, however in this case. However, that can be resolved by including a simple version number option in LCP.

Regards
Vineet

"DISCLAIMER: This message is proprietary to the Aricent Group and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. The Aricent Group accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."