Internet Draft
Network Working Group                                         J. Carlson
INTERNET-DRAFT                                          Sun Microsystems
Expires January 2001                                           July 2000
Updates RFC 1990


                   PPP Link Balancing Detection (LBD)
                     <draft-ietf-pppext-lbd-02.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is the product of the Point-to-Point Protocol
   Extensions Working Group of the Internet Engineering Task Force
   (IETF).  Comments should be submitted to the ietf-ppp@merit.edu
   mailing list.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   also defines an extensible Link Control Protocol (LCP), which allows
   the detection of optional link handling procedures, as well as a
   Multilink procedure (MP) [2], which allows operation over multiple
   parallel links.  This document defines an extension to MP called Link
   Balancing Detection (LBD) and the LCP options that control this
   extension.  This extension allows high-speed implementations to use
   the single-NCP negotiation model of MP without requiring prohibitive
   datagram buffering and reordering costs.




Carlson                   expires January 2001                  [Page 1]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


Table of Contents

   1.      Introduction ...........................................    2
   1.1.    Conventions ............................................    3
   2.      No-Fragmentation Configuration Option Format ...........    3
   3.      No-MP-Headers Configuration Option Format ..............    4
   4.      Interaction With MRRU ..................................    5
   5.      Interaction With CCP and ECP ...........................    5
   6.      Bundle Establishment ...................................    5
   7.      Bundle Tear-Down .......................................    6
   8.      Message Distribution ...................................    6
   9.      Security Issues ........................................    7
   10.     References .............................................    7
   11.     Author's Address .......................................    7


1.  Introduction

   Standard PPP negotiation allows for two types of links with regard to
   multiple link layer entities.  The standard type of PPP link is nego-
   tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option
   and appears as a separate network interface to the network layer and
   to routing protocols.  The Multilink PPP (MP) [2] type of link uses
   the MRRU option and allows multiple PPP links to be bundled into one
   network interface.  An MP link appears as a single network interface
   to the network layer and to routing protocols.

   There are many advantages having multiple links between two nodes
   appear at the network layer to be a single link.  While equal-cost
   multi-path balancing is certainly possible with modern interior gate-
   way protocols, less stress is placed on scarce routing system
   resources when link-layer detection is employed, allowing current
   routing protocols to scale better.  Also, routing system stability is
   usually higher in the face of link failures when individual links are
   not visible to link-state routing protocols.

   The main disadvantage to the current MP technique is that it does not
   constrain the fragmentation that may be done by the peer.  For sys-
   tems employing general purpose CPUs in the data path and with
   scatter-gather direct memory access (DMA) capability, the reassembly
   process is often not a problem.  For systems with very high bandwidth
   capabilities, these features are often infeasible, and this problem
   makes regular MP unusable.

   This draft describes a method similar to and compatible with MP for
   detecting multiple links to the same node, but without the fragmenta-
   tion or reordering protection of MP.  Instead, datagrams are distri-
   buted without MP headers among the links in the bundle in any



Carlson                   expires January 2001                  [Page 2]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


   convenient manner, including based on a hash or on round-robbin ser-
   vice.

   This technique is also referred to as "load balancing."  The differ-
   ence between LBD and traditional load balancing is that MP's single-
   NCP (and associated single address negotiation model) is used and
   that the configuration is made automatic.  This allows peers to dis-
   cover during LCP negotiation that, for example, links within a con-
   figured bundle violate a hardware design constraint by having dif-
   ferent MRU values, or are provisioned to terminate on the wrong net-
   work node.


1.1.  Conventions

   The following language conventions are used in the items of specifi-
   cation in this document:

      o  MUST, SHALL, or MANDATORY -- This item is an absolute require-
         ment of the specification.

      o  SHOULD or RECOMMEND -- This item should generally be followed
         for all but exceptional circumstances.

      o  MAY or OPTIONAL -- This item is truly optional and may be fol-
         lowed or ignored according to the needs of the implementor.


2.  No-Fragmentation Configuration Option Format

   A summary of the No-Fragmentation Configuration Option format for LCP
   is shown below.  The fields are transmitted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      2

   The sender of this option in an LCP Configure-Request message is



Carlson                   expires January 2001                  [Page 3]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


   indicating to its peer that it cannot support MP reassembly, and,
   thus the peer must not fragment messages that it sends.

   If the peer Configure-Ack's this option, then the peer MUST NOT frag-
   ment frames using MP fragmentation.  It MAY still use MP headers to
   preserve frame sequencing.  If the peer Configure-Reject's this
   option, then the sender must remove this option from its next
   Configure-Request message and MAY decline to run MP by also removing
   its MRRU Configuration Option.  Implementations MUST NOT Configure-
   Nak this option if it appears in the peer's Configure-Request.


3.  No-MP-Headers Configuration Option Format

   A summary of the No-MP-Headers Configuration Option format for LCP is
   shown below.  The fields are transmitted from left to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      2

   The sender of this option in an LCP Configure-Request message is
   indicating to its peer that it cannot support standard MP headers,
   and, thus the peer must not use MP headers on the messages that it
   sends, and must send network layer messages using their assigned pro-
   tocol numbers rather than inside protocol 003D.

   If this option is specified, then the No-Fragmentation option is
   unnecessary.  Fragmentation without MP headers is not supported.

   If the peer Configure-Ack's this option, then it MUST NOT add MP
   headers or fragment frames using MP.  If the peer Configure-Reject's
   this option, then the sender must remove this option from its next
   Configure-Request message and MAY decline to run MP by also removing
   its MRRU Configuration Option.  Implementations MUST NOT Configure-
   Nak this option if it appears in the peer's Configure-Request.

   This option SHOULD not be used on links that are intended to carry



Carlson                   expires January 2001                  [Page 4]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


   network protocols that cannot tolerate reordering.  See section 8,
   "Message Distribution," for details.


4.  Interaction With MRRU

   The MRRU option from MP is still used to signal the desire to run MP,
   regardless of whether or not these options are present.  If MRRU is
   not negotiated, then these options have no effect.  If an MRRU is
   negotiated, then, as with RFC 1990 MP, the peer's MRRU is advertised
   to the network layer as the MTU for the interface.

   When No-Fragmentation is used but No-MP-Headers is not used, MRRU
   should be set to the LCP MRU minus 6 (for long sequence numbers) or
   minus 4 (for short sequence numbers).  When No-MP-Headers is used,
   MRRU should be set equal to the LCP MRU.


5.  Interaction With CCP and ECP

   The No-Fragmentation option has no effect on either CCP or ECP.  When
   the No-MP-Headers option is negotiated, the peers should restrict
   themselves to per-link CCP or ECP, or may use CCP or ECP algorithms
   supporting multiple contexts in an implementation-dependent manner by
   prior arrangement.


6.  Bundle Establishment

   As with MP, bundle establishment is based on a combination of the
   peer's supplied endpoint discriminator (ED) and the peer's identity
   as determined via link authentication.  The algorithm used for LBD is
   identical to the MP algorithm, and is documented here only for con-
   venience.

   When authentication (if any was negotiated via LCP) is complete, a
   check is made before attempting to negotiate any Network Control Pro-
   tocols (NCPs).  If an MRRU is agreed to by both peers and if there is
   an existing LBD bundle where the ED (or lack thereof) matches the new
   link's ED (or lack), and the authenticated peer name (or lack
   thereof) match the new link's peer name (or lack), then this new link
   should be made part of the bundle and no new NCPs are created.  Oth-
   erwise, this is a separate link, and NCPs should be started.

   If the local and remote MRRU values do not agree with the bundle or
   if the presence or absence of the No-Fragmentation or No-MP-Headers
   options does not agree with the bundle, then the link SHOULD be ter-
   minated.  An implementation MAY choose instead to renegotiate LCP to



Carlson                   expires January 2001                  [Page 5]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


   repair the error.



7.  Bundle Tear-Down

   Tear-down is identical to standard MP and is thus not covered here.



8.  Message Distribution

   To distribute messages among the links when LBD is in effect, a few
   simple rules must be followed.

   First, since PPP negotiation does not withstand reordering, all PPP
   negotiation messages MUST be sent over a single link to avoid possi-
   ble reordering.  The first link in a bundle MUST be used to transmit
   PPP messages until this link is terminated.  If the first link is
   terminated, then one remaining link in the bundle MUST be chosen for
   subsequent messages.  Once that link is chosen, an implementation
   MUST continue sending all PPP negotiation messages over that single
   link.  Any remaining link in the bundle MAY be chosen, and it is
   entirely possible that each peer may choose a different link without
   harm to the PPP protocol.

   Second, PPP negotiation messages MUST be handled when received on any
   link.  An implementation MAY choose to terminate the last link over
   which negotiation was received if negotiation is received over a dif-
   ferent link, since this transition implies that the peer has already
   terminated the prior link.

   Third, network datagrams SHOULD be distributed over all links as
   evenly as possible.  There are no requirements that any particular
   distribution algorithm be used.  Note, however, that some network
   protocols behave poorly when subjected to message reordering, so
   techniques that prevent reordering (such as deterministic hashes of
   network layer addresses) are encouraged.  (For TCP, reordering of IP
   datagrams usually causes a slow path in the state machine to be
   taken, and can trigger side-effects, such as fast retransmit.)

   Fourth, network datagrams from protocols that cannot withstand mes-
   sage reordering MUST be sent over a single link within the bundle.
   The link for each datagram may be chosen in any manner appropriate
   for that network layer, and is left to either the network layer
   specification or prior arrangement between the peers.  Standard MP
   may be preferred over LBD in these cases.




Carlson                   expires January 2001                  [Page 6]

INTERNET-DRAFT        PPP Link Balancing Detection             July 2000


   Fifth, the common but technically non-standard practice of using LCP
   Terminate-Request to gracefully terminate a link without data loss is
   encouraged in LBD implementations.  To do this, an implementation
   leaves Open state on sending LCP Terminate-Request, but, contrary to
   RFC 1661 [1], continues processing received datagrams until the peer
   replies with LCP Terminate-Ack.


9.  Security Issues

   The authentication and bundling techniques are identical to standard
   MP and the security issues are the same as with RFC 1990.


10.  References

   [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
       7/21/1994

   [2] K. Sklower, et al, "The PPP Multilink Protocol (MP)", RFC 1990,
       8/1996


11.  Author's Address

   James Carlson
   Sun Microsystems
   1 Network Drive MS UBUR02-212
   Burlington MA  01803-2757

   Phone:  +1 781 442 2084
   Fax:    +1 781 442 1677
   Email:  james.d.carlson@sun.com


















Carlson                   expires January 2001                  [Page 7]