rfc1717.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,180 行 · 第 1/4 页

Network Working Group                                         K. Sklower
Request for Comments: 1717            University of California, Berkeley
Category: Standards Track                                       B. Lloyd
                                                             G. McGregor
                                                   Lloyd Internetworking
                                                                 D. Carr
                                          Newbridge Networks Corporation
                                                           November 1994


                    The PPP Multilink Protocol (MP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document proposes a method for splitting, recombining and
   sequencing datagrams across multiple logical data links.  This work
   was originally motivated by the desire to exploit multiple bearer
   channels in ISDN, but is equally applicable to any situation in which
   multiple PPP links connect two systems, including async links.  This
   is accomplished by means of new PPP [2] options and protocols.

Acknowledgements

   The authors specifically wish to thank Fred Baker of ACC, Craig Fox
   of Network Systems, Gerry Meyer of Spider Systems, Tom Coradetti of
   Digiboard (for the Endpoint Discriminator option), Dan Brennan of
   Penril Datability Networks, Vernon Schryver of SGI (for the
   comprehensive discussion of padding), and the members of the IP over
   Large Public Data Networks and PPP Extensions working groups, for
   much useful discussion on the subject.

Table of Contents

   1. Introduction ................................................    2
   1.1. Motivation ................................................    2
   1.2. Functional Description ....................................    3
   1.3. Conventions ...............................................    3
   2. General Overview ............................................    4
   3. Packet Formats ..............................................    6
   3.1. Padding Considerations ....................................    9



Sklower, Lloyd, McGregor & Carr                                 [Page 1]

RFC 1717                     PPP Multilink                 November 1994


   4. Trading Buffer Space Against Fragment Loss ..................    9
   4.1. Detecting Fragment Loss ...................................   10
   4.2. Buffer Space Requirements .................................   11
   5. PPP Link Control Protocol Extensions ........................   12
   5.1. Configuration Option Types ................................   12
   5.1.1. Multilink MRRU LCP option ...............................   13
   5.1.2. Short Sequence Number Header Format Option ..............   13
   5.1.3. Endpoint Discriminator Option ...........................   14
   6. Closing Member links ........................................   18
   7. Interaction with Other Protocols ............................   19
   8. Security Considerations .....................................   19
   9. References ..................................................   20
   10. Authors' Addresses .........................................   21

1.  Introduction

1.1.  Motivation

   Basic Rate and Primary Rate ISDN both offer the possibility of
   opening multiple simultaneous channels between systems, giving users
   additional bandwidth on demand (for additional cost).  Previous
   proposals for the transmission of internet protocols over ISDN have
   stated as a goal the ability to make use of this capability, (e.g.,
   Leifer et al., [1]).

   There are proposals being advanced for providing synchronization
   between multiple streams at the bit level (the BONDING proposals);
   such features are not as yet widely deployed, and may require
   additional hardware for end system.  Thus, it may be useful to have a
   purely software solution, or at least an interim measure.

   There are other instances where bandwidth on demand can be exploited,
   such as using a dialup async line at 28,800 baud to back up a leased
   synchronous line, or opening additional X.25 SVCs where the window
   size is limited to two by international agreement.

   The simplest possible algorithms of alternating packets between
   channels on a space available basis (which might be called the Bank
   Teller's algorithm) may have undesirable side effects due to
   reordering of packets.

   By means of a four-byte sequencing header, and simple synchronization
   rules, one can split packets among parallel virtual circuits between
   systems in such a way that packets do not become reordered, or at
   least the likelihood of this is greatly reduced.






Sklower, Lloyd, McGregor & Carr                                 [Page 2]

RFC 1717                     PPP Multilink                 November 1994


1.2.  Functional Description

   The method discussed here is similar to the multilink protocol
   described in ISO 7776 [4], but offers the additional ability to split
   and recombine packets, thereby reducing latency, and potentially
   increase the effective maximum receive unit (MRU).  Furthermore,
   there is no requirement here for acknowledged-mode operation on the
   link layer, although that is optionally permitted.

   Multilink is based on an LCP option negotiation that permits a system
   to indicate to its peer that it is capable of combining multiple
   physical links into a "bundle".  Only under exceptional conditions
   would a given pair of systems require the operation of more than one
   bundle connecting them.

   Multilink is negotiated during the initial LCP option negotiation.  A
   system indicates to its peer that it is willing to do multilink by
   sending the multilink option as part of the initial LCP option
   negotiation.  This negotiation indicates three things:

   1.   The system offering the option is capable of combining
        multiple physical links into one logical link;

   2.   The system is capable of receiving upper layer protocol data
        units (PDU) fragmented using the multilink header (described
        later) and reassembling the fragments back into the original
        PDU for processing;

   3.   The system is capable of receiving PDUs of size N octets
        where N is specified as part of the option even if N is larger
        than the maximum receive unit (MRU) for a single physical
        link.

   Once multilink has been successfully negotiated, the sending system
   is free to send PDUs encapsulated and/or fragmented with the
   multilink header.

1.3.  Conventions

   The following language conventions are used in the items of
   specification in this document:

   o    MUST, SHALL or MANDATORY -- the item is an absolute requirement
        of the specification.

   o    SHOULD or RECOMMENDED -- the item should generally be followed
        for all but exceptional circumstances.




Sklower, Lloyd, McGregor & Carr                                 [Page 3]

RFC 1717                     PPP Multilink                 November 1994


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

2.  General Overview

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure the data
   link during Link Establishment phase.  After the link has been
   established, PPP provides for an Authentication phase in which the
   authentication protocols can be used to determine identifiers
   associated with each system connected by the link.

   The goal of multilink operation is to coordinate multiple independent
   links between a fixed pair of systems, providing a virtual link with
   greater bandwidth than any of the constituent members.  The aggregate
   link, or bundle, is named by the pair of identifiers for two systems
   connected by the multiple links.  A system identifier may include
   information provided by PPP Authentication [3] and information
   provided by LCP negotiation.  The bundled links can be different
   physical links, as in multiple async lines, but may also be instances
   of multiplexed links, such as ISDN, X.25 or Frame Relay.  The links
   may also be of different kinds, such as pairing dialup async links
   with leased synchronous links.

   We suggest that multilink operation can be modeled as a virtual PPP
   link-layer entity wherein packets received over different physical
   link-layer entities are identified as belonging to a separate PPP
   network protocol (the Multilink Protocol, or MP) and recombined and
   sequenced according to information present in a multilink
   fragmentation header.  All packets received over links identified as
   belonging to the multilink arrangement are presented to the same
   network-layer protocol processing machine, whether they have
   multilink headers or not.

   The packets to be transmitted using the multilink procedure are
   encapsulated according to the rules for PPP where the following
   options would have been manually configured:

        o  No async control character Map
        o  No Magic Number
        o  No Link Quality Monitoring
        o  Address and Control Field Compression
        o  Protocol Field Compression
        o  No Compound Frames
        o  No Self-Describing-Padding






Sklower, Lloyd, McGregor & Carr                                 [Page 4]

RFC 1717                     PPP Multilink                 November 1994


   Of course, individual links are permitted to have different settings
   for these options.  As described below, member links SHOULD negotiate
   Self-Describing-Padding, even though pre-fragmented packets MUST NOT
   be padded.

   LCP negotiations are not permitted on the bundle itself.  An
   implementation MUST NOT transmit LCP Configure-Request, -Reject,
   -Ack, -Nak, Terminate-Request or -Ack packets via the multilink
   procedure, and an implementation receiving them MUST silently discard
   them.  (By "silently discard" we mean to not generate any PPP packets
   in response; an implementation is free to generate a log entry
   registering the reception of the unexpected packet).  By contrast,
   other LCP packets having control functions not associated with
   changing the defaults for the bundle itself are permitted.  An
   implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-
   Request, Echo-Reply and Discard-Request Packets.

   The effective MRU for the logical-link entity is negotiated via an
   LCP option.  It is irrelevant whether Network Control Protocol
   packets are encapsulated in multilink headers or not, or even over
   which link they are sent, once that link identifies itself as
   belonging to a multilink arrangement.

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

   For example, consider the case in Figure 1.  Link 1 has negotiated
   network layers NL 1, NL 2, and MP between two systems.  The two
   systems then negotiate MP over Link 2.

   Frames received on link 1 are demultiplexed at the data link layer
   according the PPP network protocol identifier and can be sent to NL
   1, NL 2, or MP.  Link 2 will accept frames with all network protocol
   identifiers that Link 1 does.

   Frames received by MP are further demultiplexed at the network layer
   according to the PPP network protocol identifier and sent to NL 1 or
   NL 2.  Any frames received by MP for any other network layer
   protocols are rejected using the normal protocol reject mechanism.











Sklower, Lloyd, McGregor & Carr                                 [Page 5]

RFC 1717                     PPP Multilink                 November 1994


                      Figure 1.  Multilink Overview.

     Network Layer
     -------------
                    ______           ______
                   /      \         /      \
                  |  NL 1  |       |  NL 2  |
                   \______/         \______/
                     | | |             | | |