Subject: An update to LBD

From: James Carlson <[email-masked]>
Date: Fri, 17 Apr 1998 11:46:46 -0400

Before sending off for publication, I'd like to expose this to the
criticism of the wg list.  I've incorporated suggestions from Craig
Fox and John Bray at Cisco (separate negotiation of fragmentation and
header usage) and Vernon Schryver at SGI (refinements of reordering
implications and MRRU/MRU).

====

PPP Working Group                                             J. Carlson
Internet Draft                                       IronBridge Networks
expires in six months                                         April 1998

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

Status of this Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

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
   physical links.  This document defines an extension to MP called Link
   Balancing Detection (LBD) and the LCP options which control this
   extension.

Carlson                   expires October 1998                  [Page 1]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

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.      Bundle Establishment ...................................    5
   6.      Bundle Tear-Down .......................................    5
   7.      Message Distribution ...................................    6
   8.      Security Issues ........................................    7
   9.      References .............................................    7
   10.     Authors' Addresses .....................................    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 farther.  Also, routing system stability
   in the face of link failures is usually higher when individual links
   are not visible to the routing protocols.

   The main disadvantage to the current MP technique is that it does not
   constrain the fragmentation which 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, this is often
   not a problem.  For systems with very high bandwidth capabilities,
   these features are often infeasible, and this problem makes MP unus-
   able.

   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 con-
   venient manner, including based on a hash or on round-robbin service.

Carlson                   expires October 1998                  [Page 2]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

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 a Configure-Request message is indicat-
   ing to its peer that it cannot support reassembly, and, thus the peer
   must not fragment messages that it sends.  If MP without reassembly
   is supported in an implementation, then every LCP Configure-Request
   message MUST carry this option until rejected by the peer.

   If the peer Configure-Ack's this option, then it MUST NOT fragment
   frames using standard 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.

Carlson                   expires October 1998                  [Page 3]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

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 a Configure-Request message is indicat-
   ing 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.  If
   standard MP is not supported but MP without headers (termed "Link
   Balancing Detection," or LBD, by this specification) is supported in
   an implementation, then every LCP Configure-Request message MUST
   carry this option until rejected by the peer.

   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.  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.

   This option SHOULD not be used on links which are intended to carry
   network protocols which cannot tolerate reordering.  See section blah
   for details.

Carlson                   expires October 1998                  [Page 4]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

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 standard 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.  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
   repair the error.

6.  Bundle Tear-Down

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

Carlson                   expires October 1998                  [Page 5]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

7.  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 which 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 which cannot withstand mes-
   sage reordering MUST be sent over a single link within the bundle, as
   with PPP negotiation above.  Standard MP is preferred over LBD in
   these cases.

   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.

Carlson                   expires October 1998                  [Page 6]

INTERNET DRAFT        PPP Link Balancing Detection            April 1998

8.  Security Issues

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

9.  References

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

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

   [3] J. Postel, "Internet Protocol", RFC 791, 09/01/1981

10.  Author's Address

   James Carlson
   IronBridge Networks
   55 Hayden Avenue
   Lexington MA  02173-7999

   Phone:  +1 781 402 8032
   Fax:    +1 781 402 8092
   Email:  [email-masked]

Carlson                   expires October 1998                  [Page 7]


-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp

---

From: Archie Cobbs <[email-masked]>
Date: Fri, 17 Apr 1998 12:35:12 -0700 (PDT)

>    network interface.  An MP link appears as a single network interface
                               ^^^^
>    to the network layer and to routing protocols.

Shouldn't that word be "bundle" ?

>    resources when link-layer detection is employed, allowing current
                    ^^^^^^^^^^^^^^^^^^^^
>    are not visible to the routing protocols.

The phrase "link-layer detection" is not a familiar to me.
What does it mean?

>    This option SHOULD not be used on links which are intended to carry
                 ^^^^^^^^^^
>    network protocols which cannot tolerate reordering.  See section blah

Nit: should not this be "SHOULD NOT" instead of "SHOULD not" ?
It just reads kinda funny.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com