I ..,.
`
`I"
`
`•r
`'-1
`,-..;;;;<_.~\
`
`-
`
`rfcl990
`
`Network Working Group
`Request
`for Comments:
`Obsoletes:
`1717
`Category:
`Standards
`
`1990
`Track
`
`University
`
`of California,
`
`K. Sklower
`Berkeley
`B. Lloyd
`G. McGregor
`Internetworking
`Lloyd
`D. Carr
`Networks
`Corporation
`T. Coradetti
`Sidewalk
`Software
`August
`1996
`
`Newbridge
`
`The PPP Multilink
`
`Protocol
`
`(MP)
`
`for
`protocol
`track
`for
`and
`suggestions
`"Internet
`edition
`of
`the
`state
`standardization
`the
`of
`this memo is unlimited.
`
`the
`
`this Memo
`of
`Status
`document
`specifies
`This
`standards
`Internet
`an
`Internet
`community,
`discussion
`and
`requests
`improvements.
`Please
`current
`refer
`to
`the
`Official
`Protocol
`Standards"
`(STD 1)
`for
`and
`status
`this
`protocol.
`Distribution
`of
`Abstract
`recombining
`splitting,
`for
`a method
`proposes
`document
`This
`and
`data
`links.
`logical
`across
`multiple
`sequencing
`datagrams
`This work
`multiple
`by
`the
`desire
`to exploit
`was originally
`motivated
`bearer
`channels
`ISDN, but
`is
`equally
`applicable
`to
`any
`situation
`in
`in which
`multiple
`PPP
`links
`connect
`two
`systems,
`including
`async
`links.
`This
`is
`accomplished
`by means
`of new PPP
`[2] options
`and protocols.
`(RFC
`The differences
`between
`the
`current
`PPP Multilink
`specification
`1717)
`and
`this memo are
`explained
`in Section
`11.
`Any system
`implementing
`additional
`restrictions
`required
`by
`this memo will
`the
`be backwards
`compatible
`with
`conforming
`RFC 1717
`implementations.
`Acknowledgements
`of ACC, Craig
`Fred Baker
`thank
`to
`wish
`specifically
`The authors
`Dan Brennan
`Gerry Meyer of Spider
`Systems,
`of Network
`Systems,
`(for
`the
`Penril
`Datability
`Networks,
`Vernon
`Schryver
`of SGI
`comprehensive
`discussion
`of padding),
`and
`the members
`of
`the
`Large
`Public
`Data Networks
`and PPP Extensions
`working
`groups,
`much useful
`discussion
`the
`subject.
`on
`
`Fox
`of
`IP over
`for
`
`Page 1
`
`EX 1006 Page 1
`
`

`

`o)
`
`rfc1990
`
`et.
`
`al.
`
`Sklower,
`1
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`l]
`[Page
`August
`1996
`
`of Contents
`Table
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Introduction
`1.
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`1.1. Motivation
`Description
`.............
`......
`.........
`......
`..
`1.2.
`Functional
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`1.3. Conventions
`2. General
`Overview
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`3 . Pa c k et Format s
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`3.1.
`Padding
`Considerations
`.........
`....
`..
`.....
`....
`...
`...
`...
`. ..
`4. Trading
`Buffer
`Space Against
`Fragment
`Loss
`. . .....
`..
`......
`...
`4 .1. Detecting
`Fragment
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Loss
`4.2. Buffer
`Space Requirements
`..
`..............
`...........
`...
`...
`5. PPP Link Control
`Protocol
`Extensions
`.....
`..
`. .......
`......
`...
`5 .1. Configuration
`Option
`Types
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`5.1.1. Multilink
`MRRU LCP option
`. ...........
`...
`.......
`......
`...
`5.1.2.
`Short
`Sequence
`Number Header
`Format Option
`..
`...
`......
`...
`5.1.3.
`Endpoint
`Discriminator
`Option
`........
`...
`......
`......
`....
`6.
`Initiating
`use of Multi
`link Headers
`. . . . . . . . . . . . . . . . . . . . . . . . .
`7. Closing Member
`links
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`8.
`Interaction
`with Other
`Protocols
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`9. Security
`Considerations
`...
`..
`..............
`.........
`......
`..
`10. References
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`11. Differences
`from RFC 1 717
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`11.1. Negotiating
`Multilink,
`per
`se
`..
`..
`. ....
`..
`. ..
`. .......
`...
`. ..
`11. 2.
`Initial
`Sequence
`Number defined
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`11.3. Default
`Value
`of
`the MRRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`11.4.
`Config-Nak
`of EID prohibited
`..
`. .......
`..
`..
`......
`...
`..
`.
`...
`11.5. Uniformity
`of Sequence
`Space
`......
`...
`...
`. . ..
`..
`.....
`...
`. ..
`11.6.
`Commencing
`and Abating
`use of Multilink
`Headers
`. . ......
`..
`11.7. Manual Configuration
`and Bundle Assignment
`......
`...
`...
`...
`12. Authors'
`Addresses
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Introduction
`Motivation
`of
`possibility
`the
`offer
`ISDN both
`Rate
`and Primary
`Basic Rate
`users
`giving
`systems,
`between
`channels
`opening multiple
`simultaneous
`Previous
`cost).
`additional
`bandwidth
`on demand
`(for
`additional
`over
`ISDN have
`proposals
`for
`transmission
`of
`internet
`protocols
`the
`stated
`as a goal
`the
`ability
`to make use of
`capability,
`this
`(e.g.,
`Leifer
`et al.
`[ 1] ) .
`,
`advanced
`There
`are proposals
`being
`at
`the bit
`between multiple
`streams
`such
`features
`are
`not
`as yet widely
`additional
`hardware
`for
`end
`system.
`purely
`software
`solution,
`or at
`least
`
`synchronization
`providing
`for
`level
`(the BONDING proposals);
`deployed,
`and may require
`Thus,
`it may be useful
`to have
`an
`interim
`measure.
`
`1.
`1.1.
`
`2
`2
`3
`4
`4
`7
`10
`10
`11
`12
`13
`13
`14
`15
`15
`19
`2 0
`20
`21
`21
`22
`22
`22
`22
`22
`22
`23
`23
`24
`
`a
`
`Page 2
`
`EX 1006 Page 2
`
`

`

`rfcl990
`
`et.
`
`al.
`
`Sklower,
`-=r
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`2)
`[Page
`August
`1996
`
`bandwidth
`where
`instances
`other
`are
`There
`can be exploited,
`on demand
`at 28,800
`async
`line
`a dialup
`as using
`such
`baud
`to back
`up a
`leased
`or opening
`additional
`synchronous
`line,
`X.25 SVCs where
`the window
`size
`is
`limited
`to
`two by
`international
`agreement.
`The simplest
`possible
`algorithms
`of alternating
`between
`packets
`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.
`synchronization
`s'imple
`and
`header,
`sequencing
`By means of a four-byte
`circuits
`between
`virtual
`packets
`among parallel
`rules,
`one can
`split
`that
`packets
`do not become
`reordered,
`or at
`systems
`in
`such
`a way
`least
`the
`likelihood
`of
`this
`is greatly
`reduced.
`Functional
`Description
`protocol
`the multilink
`to
`similar
`is
`The method
`discussed
`here
`ability
`the
`but
`described
`in
`ISO 7776
`[4),
`offers
`additional
`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
`link
`layer,
`although
`that
`is optionally
`permitted.
`a system
`permits
`that
`Multilink
`is based
`on an LCP option
`negotiation
`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
`bundle
`connecting
`them.
`negotiation.
`LCP option
`initial
`the
`during
`Multilink
`is negotiated
`it
`is willing
`to do multilink
`that
`peer
`system
`indicates
`to
`its
`of
`initial
`LCP option
`as part
`the
`option
`sending
`the multilink
`indicates
`three
`things:
`negotiation.
`This
`negotiation
`option
`is
`capable
`of combining
`1.
`The system
`offering
`the
`logical
`link;
`physical
`links
`into
`one
`data
`protocol
`layer
`receiving
`upper
`The system
`is
`capable
`of
`header
`units
`(PDU) fragmented
`using
`the multilink
`(described
`later)
`and
`reassembling
`the
`fragments
`back
`into
`the
`original
`for
`processing;
`capable
`The system
`is
`as part
`is
`specified
`unit
`maximum
`receive
`
`to
`
`split
`
`on
`
`the
`
`one
`
`A
`
`by
`
`multiple
`
`PDU
`
`1.2.
`
`2.
`
`3.
`
`size N octets
`PDUs of
`receiving
`of
`even
`if N is
`the
`option
`of
`larger
`(MRU) for
`a single
`physical
`link.
`
`where N
`than
`the
`
`Page 3
`
`EX 1006 Page 3
`
`

`

`1.3.
`
`o
`
`o
`
`2.
`
`are
`
`used
`
`in
`
`the
`
`items
`
`of
`
`the
`
`item
`
`is
`
`an absolute
`
`requirement
`
`should
`
`generally
`
`be
`
`followed
`
`and may be
`the
`implementor.
`
`of
`
`rfc1990
`
`et.
`
`al.
`
`Sklower,
`-=r
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`3)
`[Page
`August
`1996
`
`negotiated,
`and/or
`fragmented
`
`the
`
`sending
`with
`the
`
`system
`
`successfully
`has been
`Once multilink
`is
`free
`to
`send PDUs encapsulated
`multilink
`header.
`Conventions
`conventions
`language
`following
`The
`document:
`in
`this
`specification
`o
`MUST, SHALL or MANDATORY --
`of
`the
`specification.
`item
`the
`SHOULD or RECOMMENDED --
`circumstances.
`for
`all
`but
`exceptional
`optional
`item
`is
`truly
`MAY or OPTIONAL --
`the
`followed
`or
`ignored
`according
`to
`the needs
`General
`Overview
`each
`a point-to-point
`over
`communications
`In order
`to establish
`link,
`data
`end of
`the PPP
`link must
`first
`send LCP packets
`to
`configure
`the
`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.
`multiple
`The goal
`of multilink
`operation
`is
`to coordinate
`independent
`a virtual
`links
`between
`a fixed
`pair
`of
`systems,
`providing
`link with
`members.
`greater
`bandwidth
`than
`any of
`the
`constituent
`The aggregate
`for
`link,
`or bundle,
`is named by
`the
`pair
`of
`identifiers
`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
`ISDN, X.25 or Frame Relay.
`The
`as
`links
`may also
`be of different
`kinds,
`such
`as pairing
`dialup
`async
`links
`with
`leased
`synchronous
`links.
`as a virtual
`can be modeled
`PPP
`We suggest
`that multilink
`operation
`received
`over
`different
`physical
`link-layer
`entity
`wherein
`packets
`as belonging
`to a separate
`PPP
`link-layer
`entities
`are
`identified
`Protocol,
`or MP) and
`recombined
`and
`network
`protocol
`(the Multilink
`present
`in a multilink
`sequenced
`according
`to
`information
`received
`over
`links
`identified
`as
`fragmentation
`header.
`All packets
`belonging
`to
`the multilink
`arrangement
`are presented
`to
`the
`same
`
`Page 4
`
`EX 1006 Page 4
`
`

`

`rfc1990
`
`network-layer
`multilink
`
`processing
`protocol
`headers
`or not.
`
`machine,
`
`whether
`
`they
`
`have
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`4]
`[Page
`August
`1996
`
`are
`procedure
`the
`following
`
`Compression
`
`the multilink
`using
`transmitted
`to be
`The packets
`the
`for
`PPP where
`rules
`according
`encapsulated
`to
`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
`o
`Protocol
`Field
`Compression
`o No Compound Frames
`o No Self-Describing-Padding
`an
`that
`this means
`in RFC1661,
`According
`to
`the
`rules
`specified
`with
`and without
`implementation
`MUST accept
`reassembled
`packets
`of
`the
`reassembled
`leading
`zeroes
`present
`in
`the Protocol
`Field
`below
`to
`include
`packet.
`Although
`it
`is
`explicitly
`forbidden
`Address
`and Control
`fields
`(usually,
`the
`two bytes
`FF 03)
`in
`material
`to be
`fragmented,
`it
`is
`a good defensive
`programming
`practice
`to accept
`the
`packet
`anyway,
`ignoring
`the
`two bytes
`present,
`as
`that
`is what RFC1661
`specifies.
`better
`As a courtesy
`to
`implementations
`that
`perform
`when certain
`alignment
`obtains,
`it
`is
`suggested
`that
`a determination
`be made when
`a bundle
`is
`created
`on whether
`transmit
`leading
`to
`zeroes
`by
`examining
`whether
`PFC has been
`negotiated
`on
`the
`first
`link
`admitted
`into
`a bundle.
`This
`determination
`should
`be kept
`in
`force
`so
`long
`a bundle
`persists.
`settings
`different
`to have
`permitted
`are
`links
`Of course,
`individual
`below, member
`As described
`links
`SHOULD negotiate
`for
`these
`options.
`even
`though
`pre-fragmented
`packets MUST NOT
`Self-Describing-Padding,
`the Protocol
`Field
`Compression
`mode on
`the member
`be padded.
`Since
`system
`to
`include
`a
`leading
`byte
`of zero
`or not
`link
`allows
`a sending
`at
`its
`discretion,
`this
`is
`an alternative
`mechanism
`for
`generating
`even-length
`packets.
`An
`itself.
`bundle
`the
`on
`not permitted
`LCP negotiations
`are
`-Reject,
`LCP Configure-Request,
`implementation
`MUST NOT transmit
`-Ack packets
`via
`the multilink
`-Ack,
`-Nak, Terminate-Request
`or
`discard
`receiving
`them MUST silently
`procedure,
`and an
`implementation
`them.
`(By
`''silently
`discard"
`we mean
`to not generate
`any PPP packets
`in
`response;
`an
`implementation
`free
`to generate
`a log
`entry
`is
`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
`
`the
`the
`if
`
`as
`
`Page 5
`
`EX 1006 Page 5
`
`

`

`rfc1990
`
`Protocol-Reject,
`LCP Code-Reject,
`MAY transmit
`implementation
`Request,
`Echo-Reply
`and Discard-Request
`Packets.
`
`Echo-
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`5]
`[Page
`August
`1996
`
`an
`via
`is negotiated
`entity
`Network Control
`Protocol
`headers
`or not,
`or even over
`link
`identifies
`itself
`as
`
`the
`MRU for
`logical-link
`The effective
`It
`is
`irrelevant
`whether
`LCP option.
`encapsulated
`in multilink
`packets
`are
`they
`are
`sent,
`that
`which
`link
`once
`belonging
`to a multilink
`arrangement.
`Note
`that
`network
`protocols
`that
`are
`cannot
`be sequenced.
`(And consequently
`convenient
`way).
`in Figure
`case
`the
`For example,
`consider
`network
`layers
`NL 1, NL 2, and MP between
`systems
`then
`negotiate
`MP over Link
`2.
`link
`data
`the
`at
`Frames
`received
`on
`link
`1 are
`demultiplexed
`layer
`sent
`and can be
`according
`the PPP network
`protocol
`identifier
`to NL
`all
`network
`1, NL 2, or MP.
`Link 2 will
`accept
`frames with
`protocol
`identifiers
`that
`Link 1 does.
`demultiplexed
`Frames
`received
`by MP are
`further
`according
`to
`the PPP network
`protocol
`identifier
`NL 2. Any frames
`received
`by MP for
`any other
`protocols
`are
`rejected
`using
`the
`normal
`protocol
`
`not
`
`sent
`will
`
`headers
`using multilink
`be delivered
`in any
`
`1.
`two
`
`1 has negotiated
`Link
`systems.
`The
`two
`
`layer
`network
`the
`at
`and
`sent
`to NL 1 or
`network
`layer
`reject
`mechanism.
`
`Page 6
`
`EX 1006 Page 6
`
`

`

`rfcl990
`
`et.
`
`al.
`
`Sklower,
`-:r
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`6]
`[Page
`August
`1996
`
`Figure
`
`1. Multilink
`
`Overview.
`
`Network
`
`Layer
`
`\
`I
`I NL 2
`\
`I
`I
`+-------------0-0-0-+
`+------+
`+-----+
`I
`I
`+------0--0-------+
`I
`I
`I
`I
`/
`I MLCP
`I
`I
`\
`I
`I
`I
`I
`I
`I
`I
`I
`\
`I
`
`I
`I NL 1
`\
`
`I
`
`\
`/
`
`<---
`
`+
`I
`I
`1------+-----I
`
`I
`I
`\
`
`LCP
`
`Link
`
`1
`
`I
`
`Link
`
`I <---
`
`Link Layer
`Demultiplexing
`
`2
`
`\
`I
`I
`I
`I
`I
`I
`+
`I
`I
`I
`I
`I
`Link Layer
`I <---
`Demultiplexing
`I
`I
`I
`I
`Virtual
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`\
`LCP
`_/
`I
`I
`Link
`
`I
`I
`
`/
`\
`
`3.
`
`Formats
`Packet
`which
`fragments,
`individual
`of
`layout
`the
`we describe
`section
`In
`this
`Protocol
`Network
`Protocol.
`in
`the Multilink
`"packets"
`are
`the
`(but
`not
`framed)
`according
`to normal
`encapsulated
`are
`first
`packets
`are
`broken
`up
`into multiple
`and
`large
`packets
`PPP procedures,
`the multiple
`physical
`links.
`appropriately
`segments
`sized
`for
`Although
`it would
`otherwise
`be permitted
`by
`the
`PPP spec,
`in
`implementations
`MUST NOT include
`the Address
`and Control
`Field
`of
`logical
`entity
`to be
`fragmented.
`A new PPP header
`consisting
`Multilink
`Protocol
`Identifier,
`and
`the Multilink
`header
`is
`inserted
`
`the
`the
`
`Page 7
`
`EX 1006 Page 7
`
`

`

`rfcl990
`
`t.l
`
`each
`before
`in PPP will
`header
`for
`
`J
`(Thus
`section.
`have
`two headers,
`the
`packet
`itself).
`
`first
`the
`one
`for
`
`of a multilink
`fragment
`the
`fragment,
`followed
`
`packet
`by
`the
`
`et.
`
`al.
`
`Sklower,
`-:r
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`7)
`[Page
`August
`1996
`
`all.
`
`to
`
`Systems
`to
`required
`not
`are
`procedure
`the multilink
`implementing
`fragment
`the
`that
`requirement
`also
`no
`is
`There
`small
`packets.
`segments
`up at
`must
`be broken
`packets
`that
`sizes,
`or
`be of equal
`A possible
`with member
`links
`of differing
`contending
`strategy
`for
`transmission
`the
`packets
`into
`segments
`rates
`would
`to divide
`be
`proportion
`be
`to
`the
`transmission
`rates.
`Another
`strategy
`might
`divide
`them
`into many equal
`fragments
`and distribute
`multiple
`fragments
`per
`link,
`the
`numbers
`being
`proportional
`to
`the
`relative
`speeds
`of
`the
`links.
`protocol
`the
`using
`encapsulated
`are
`PPP multilink
`fragments
`a four
`identifier
`Following
`the protocol
`identifier
`Ox00-0x3d.
`is
`fields
`two one bit
`a sequence
`number,
`and
`byte
`header
`containing
`a packet.
`or
`terminates
`fragment
`begins
`a packet
`indicating
`that
`the
`byte
`After
`negotiation
`of an additional
`PPP LCP option,
`the
`four
`only
`a 12
`header may be optionally
`replaced
`by a
`two byte
`header
`with
`bit
`sequence
`space.
`Address
`& Control
`and Protocol
`ID compression
`are
`assumed
`to be
`in
`effect.
`Individual
`fragments
`will,
`therefore,
`have
`the
`following
`format:
`Figure
`Long Sequence
`2:
`Number Fragment
`+---------------+---------------+
`I Address
`Oxff
`I Control
`Ox03
`+---------------+---------------+
`J PID(H)
`OxOO
`I PID{L)
`Ox3d
`+-+-+-+-+-+-+-+-+~--------------+
`IBIEIOIOIOIOIOIOlsequence
`number!
`+-+-+-+-+-+-+-+-+---------------+
`I
`sequence
`number
`(L)
`+---------------+----
`-----------+
`fragment
`data
`I
`I
`I
`I
`+---------------+---------------+
`FCS
`I
`+---------------+---------------+
`
`PPP Header:
`
`MP Header:
`
`PPP FCS:
`
`Format.
`
`I
`I
`
`I
`I
`I
`I
`I
`I
`
`Page
`
`8
`
`EX 1006 Page 8
`
`

`

`rfc1990
`
`et.
`
`al.
`
`Sklower,
`-:r
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`8]
`[Page
`August
`1996
`
`Format.
`
`PPP Header:
`
`MP Header:
`
`PPP FCS:
`
`Figure
`3:
`Short
`Sequence
`Number Fragment
`+---------------+---------------+
`I Address
`Oxff
`I Control
`Ox03
`I
`+---------------+---------------+
`I PID ( H) OxOO
`I PID (L) Ox3d
`I
`+-+-+-+-+-------+---------------+
`IBIEIOIOI
`sequence
`number
`I
`+-+-+-+-+-------+---------------+
`I
`fragment
`data
`I
`I
`I
`I
`I
`I
`I
`+---------------+---------------+
`FCS.
`I
`I
`+---------------+---------------+
`set
`(B)eginning
`The
`fragment
`bit
`is
`a one bit
`field
`fragment
`derived
`from
`a PPP packet
`and
`set
`to O for
`fragments
`from
`the
`same PPP packet.
`to 1 on
`field
`The
`(E)nding
`fragment
`bit
`is
`a one bit
`set
`A fragment
`fragment
`and
`set
`to O for
`all
`other
`fragments.
`set
`to 1.
`both
`the
`{B)eginning
`and
`(E}nding
`fragment
`bits
`that
`is
`incremented
`is
`The sequence
`field
`a 24 bit
`or 12 bit
`number
`sequence
`transmitted.
`for
`every
`fragment
`By default,
`the
`field
`is 24
`bits
`long,
`but
`can be negotiated
`to be only
`12 bits
`with
`an LCP
`configuration
`option
`described
`below.
`sequence
`the
`Between
`the
`(E)nding
`fragment
`bit
`and
`defined,
`reserved
`field,
`whose use
`is not
`currently
`to zero.
`It
`is 2 bits
`long when
`the
`use of
`short
`has been negotiated,
`6 bits
`otherwise.
`structure
`reassembly
`In
`this multilink
`protocol,
`a single
`associated
`with
`the bundle.
`The multilink
`headers
`are
`the
`context
`of
`structure.
`this
`The FCS field
`shown
`in
`the
`
`to 1 on
`all
`other
`
`the
`
`first
`
`last
`the
`may have
`
`a
`is
`number
`which MUST be set
`sequence
`numbers
`
`is
`interpreted
`
`in
`
`diagram
`
`is
`
`inherited
`
`from
`
`the
`
`normal
`
`Page 9
`
`EX 1006 Page 9
`
`

`

`rfc1990
`
`i
`the member
`from
`framing mechanism
`transmitted.
`There
`is no separate
`packet
`as a whole
`if
`transmitted
`
`is
`packet
`the
`on which
`link
`to
`the
`FCS applied
`reconstituted
`in more
`than
`one
`fragment.
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`9)
`[Page
`August
`1996
`
`3.1.
`
`4.
`
`Self-
`SHOULD implement
`protocol
`the multilink
`self-describing-padding
`implements
`A system
`that
`option
`in
`its
`initial
`the padding
`either
`include
`of a Configure-Reject)
`the
`delay
`or
`(to
`avoid
`option
`after
`receiving
`a NAK containing
`the
`
`link,
`of
`its
`
`Considerations
`Padding
`support
`Systems
`that
`Describing-Padding.
`by definition
`will
`LCP Configure-Requests,
`include
`the padding
`option.
`not use Self-
`does
`but
`transmissions
`own
`its
`pad
`that must
`A system
`MAY continue
`when not using multilink,
`to not use
`Describing-Padding
`if
`it
`ensures
`by careful
`choice
`of
`fragment
`Self-Describing-Padding
`(E)nding
`fragments
`of packets
`are padded.
`A system
`lengths
`that
`only
`to any packet
`that
`cannot
`recognized
`as
`MUST NOT add padding
`be
`padded
`by
`the peer.
`Non-terminal
`fragments
`MUST NOT be padded with
`trailing
`material
`by any other method
`than
`Self-Describing-Padding.
`A system MUST ensure
`that
`Self-Describing-Padding
`as described
`in RFC
`on
`1570
`[11]
`is negotiated
`the
`individual
`link
`before
`transmitting
`any multilink
`data
`packets
`if
`it might
`pad non-terminal
`fragments
`or
`if
`it would
`use network
`or compression
`protocols
`that
`are
`vulnerable
`to padding,
`as described
`in RFC 1570.
`If necessary,
`system
`the
`that
`adds padding MUST use LCP Configure-NAK's
`to elicit
`a Configure-
`Request
`for Self-Describing-Padding
`from
`the peer.
`on any
`time
`Note
`that
`LCP Configure-Requests
`can be sent
`at
`any
`and
`that
`the peer will
`always
`respond
`with
`a Configure-Request
`own. A system
`that
`pads
`its
`transmissions
`but
`uses
`no protocols
`other
`than multilink
`that
`are
`vulnerable
`to padding
`MAY delay
`ensuring
`that
`the
`peer
`has Configure-Requested
`Self-Describing-
`Padding
`until
`it
`seems
`desireable
`to negotiate
`the
`use of Multilink
`itself.
`This
`permits
`the
`interoperability
`of a system
`that
`pads with
`older
`peers
`that
`support
`neither
`Multilink
`nor Self-Describing-
`Padding.
`Fragment
`Space Against
`Buffer
`Trading
`procedure
`one channel
`In a multilink
`the other
`channels
`in
`the bundle.
`received
`out of order,
`thus
`increasing
`
`Loss
`may be delayed
`This
`can
`lead
`to
`the
`difficulty
`
`to
`respect
`with
`fragments
`being
`in detecting
`
`Page
`
`10
`
`EX 1006 Page 10
`
`

`

`rfcl990
`
`•
`loss
`the
`required
`of
`this.
`fragment
`required,
`
`of a fragment.
`space
`of
`amount
`the
`of estimating
`task
`The
`on
`for
`buffering
`because
`complex
`receiver
`the
`becomes more
`In
`this
`section
`declaring
`that
`we discuss
`a
`technique
`for
`is
`lost,
`with
`the
`intent
`of minimizing
`the buffer
`space
`yet minimizing
`the
`number
`of avoidable
`packet
`losses.
`
`a
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`[Page
`August
`
`10]
`1996
`
`4.1.
`
`Loss
`Fragment
`Detecting
`fragments
`sender MUST transmit
`the
`in a bundle,
`On each member
`link
`of
`the
`numbers
`(modulo
`the
`size
`with
`strictly
`increasing
`sequence
`the
`supports
`a strategy
`for
`sequence
`space).
`This
`requirement
`based
`on comparing
`sequence
`receiver
`to detect
`lost
`fragments
`numbers.
`The
`sequence
`number
`is not
`reset
`upon each
`new PPP packet,
`and a sequence
`number
`consumed
`even
`for
`those
`fragments
`which
`is
`contain
`an entire
`PPP packet,
`i.e.,
`one
`in which
`both
`the
`(B)eginning
`and
`(E)nding
`bits
`are
`set.
`sequence
`the
`An implementation
`MUST set
`bundle
`transmited
`on a newly-constructed
`bundle
`is
`secondary
`link
`to an exisiting
`and an
`implementation
`MUST NOT reset
`the
`this
`situation).
`of
`track
`keeps
`The
`receiver
`incoming
`the
`link
`in a bundle
`and maintains
`the
`current
`recently
`received
`sequence
`number
`over
`all
`bundle
`(call
`this M).
`The
`receiver
`detects
`it
`receives
`a fragment
`bearing
`the
`(E}nding
`packet
`is
`complete
`if
`all
`sequence
`numbers
`been
`received.
`A lost
`fragment
`number
`sequence
`the
`past
`when M advances
`is detected
`which
`has not been
`(E)nding
`bit
`of a packet
`bearing
`an
`of a fragment
`numbers
`between
`not
`all
`the
`sequence
`completely
`reassembled
`(i.e.,
`fragment
`bearing
`the
`the
`fragment
`bearing
`the
`(B)eginning
`bit
`and
`the
`of
`the
`increasing
`(E}nding
`have been
`received).
`This
`is because
`bit
`sequence
`number
`rule
`over
`the bundle.
`Any sequence
`number
`so
`detected
`is
`assumed
`to
`correspond
`to a fragment
`which
`has been
`lost.
`An implementation
`MUST assume
`that
`if
`a fragment
`bears
`a
`(B)eginning
`bit,
`that
`the
`previously
`numbered
`fragment
`bore
`an
`(E}nding
`bit.
`Thus
`if
`a packet
`is
`lost
`bearing
`the
`(E)nding
`bit,
`and
`the packet
`whose
`fragment
`number
`is M contains
`a
`(B)eginning
`bit,
`the
`implementation
`MUST discard
`fragments
`for
`all
`unassembled
`packets
`through M-1, but SHOULD NOT discard
`the
`fragment
`bearing
`the
`new
`
`of
`number
`to
`zero.
`invisible
`sequence
`
`fragment
`first
`the
`a
`(Joining
`to
`the protocol,
`number
`space
`in
`
`on each
`numbers
`sequence
`minimum of
`the most
`the member
`links
`in
`the
`the
`end of a packet
`when
`bit.
`Reassembly
`of
`the
`up
`to
`that
`fragment
`have
`
`Page 11
`
`EX 1006 Page 11
`
`

`

`rfcl990
`
`alone.
`basis
`this
`on
`bit
`(B)eginning
`fragment,
`whose
`lost
`of a
`The detection
`receiver
`the
`to discard
`to be U, causes
`fragment
`with
`an ending
`lowest
`numbered
`greater
`than
`or equal
`to U. However,
`the middle
`of a chain
`of packets
`which
`
`number was deduced
`sequence
`all
`fragments
`up
`to
`the
`bit
`(possibly
`deduced)
`the
`quantity
`M may
`jump
`into
`can be successful
`completed.
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`[Page
`August
`
`11]
`1996
`
`or
`packets
`in one
`no
`mandates
`link
`The PPP
`of LCP echo-
`
`early
`of Mis
`among
`the
`
`individual
`of
`to corruption
`due
`lost
`may be
`Fragments
`link
`(which may occur
`only
`the
`of
`loss
`catastrophic
`of
`the multilink
`protocol
`version
`This
`direction).
`the
`detection
`of
`failed
`links.
`for
`procedures
`specific
`or
`the
`periodic
`issuance
`facility,
`management
`quality
`could
`be used
`to achieve
`this.
`requests
`to maximize
`idle
`links
`SHOULD avoid
`keeping
`any member
`Senders
`the
`value
`since
`of
`lost
`fragments
`detection
`by
`the
`receiver,
`not
`incremented
`on
`idle
`links.
`Senders
`SHOULD rotate
`traffic
`the member
`links
`if
`there
`isn't
`sufficient
`traffic
`to overflow
`capacity
`of one
`link
`to avoid
`idle
`links.
`receiver
`the
`cause
`can
`Loss of
`the
`final
`fragment
`of a transmission
`this may be
`of
`to
`stall
`until
`new packets
`arrive.
`The
`likelihood
`in a bundle.
`decreased
`by sending
`a null
`fragment
`on each member
`link
`that would
`otherwise
`become
`idle
`immediately
`after
`having
`transmitted
`a fragment
`bearing
`the
`(E)nding
`bit,
`where
`a null
`fragment
`is one
`consisting
`only
`of a multilink
`header
`bearing
`both
`the
`(B)egin
`and
`(E)nding
`bits
`(i.e.,
`having
`no payload).
`Implementations
`concerned
`about
`either
`wasting
`bandwidth
`or per packet
`costs
`are
`not
`required
`a
`to
`send null
`fragments
`and may elect
`to defer
`sending
`them until
`timer
`expires,
`with
`the marginally
`increased
`possibility
`of
`lengthier
`stalls
`in
`the
`receiver.
`The
`receiver
`SHOULD implement
`some
`type
`of
`link
`idle
`timer
`to guard
`against
`indefinite
`stalls.
`reallocation
`The
`increasing
`sequence
`per
`link
`rule
`prohibits
`the
`a
`fragments
`queued
`up behind
`a failing
`link
`to a working
`one,
`practice
`which
`is not unusual
`for
`implementations
`of
`ISO multilink
`over LAPB [4].
`Buffer
`Space Requirements
`detection
`correct
`guarantee
`that will
`There
`is no amount
`of buffering
`a fragment
`of
`fragment
`loss,
`since
`an adversarial
`peer may withhold
`For
`the
`on one channel
`and
`send
`arbitrary
`amounts
`on
`the
`others.
`usual
`case where
`all
`channels
`are
`transmitting,
`you can
`show
`that
`there
`detect
`a minimum
`amount
`below which
`you could
`not
`correctly
`is
`
`4.2.
`
`of
`
`Page 12
`
`EX 1006 Page 12
`
`

`

`rfc1990
`
`packet
`depends
`The amount
`loss.
`channels,
`(D[channel-i,channel-j]),
`R[c],
`the maximum
`fragment
`size
`the
`total
`amount
`of buffering
`the
`channels.
`could
`channels
`between
`delay
`the
`PPP,
`When using
`reply
`packets.
`and echo
`request
`using
`LCP echo
`the
`round
`trip
`of different
`transmission
`rates,
`adjusted
`to
`take
`this
`into
`account.)
`The slippage
`
`relative
`the
`on
`the data
`rate
`permitted
`on each
`transmitter
`has
`the
`
`the
`between
`delay
`of each
`channel,
`channel,
`F[c],
`and
`allocated
`amongst
`
`be estimated
`(In
`the
`case
`times
`should
`for
`each
`
`by
`links
`of
`be
`channel
`
`et.
`
`al.
`
`Sklower,
`RFC 1990
`
`Track
`Standards
`PPP Multilink
`
`(Page
`August
`
`12]
`1996
`
`that
`for
`delay
`S[c] = R[c)
`
`relative
`channel
`* D[c,c-worst].
`
`5.
`
`5.1.
`
`Transmission
`prior
`to
`
`the
`
`links,
`over
`
`an
`the
`
`run over
`or
`separately)
`[5] but with
`
`the
`times
`the bandwidth
`as
`is defined
`delay,
`with
`the
`longest
`to
`the
`channel
`(S[c-worst]
`will
`be zero,
`of course!)
`oe one
`skew would
`number
`sequence
`A situation
`which would
`exacerbate
`allowing
`all
`(almost
`traffic
`in which
`there
`is
`extremely
`bursty
`would
`first
`queue
`the
`transmitter
`channels
`to drain),
`and
`then where
`link
`as
`could,
`it
`packets
`on one
`up as many consecutively
`numbered
`so on.
`Since
`then
`queue
`up
`the
`next
`batch
`on a second
`link,
`and
`transmitters
`must be able
`to buffer
`at
`least
`a maximum-
`sized
`fragment
`for
`each
`link
`(and will
`usually
`buffer
`up at
`least
`two) A
`receiver
`allocates
`any
`less
`than
`S(l]
`that
`+ S(2]
`+ S[N] + F[l]
`+
`...
`+ F[N], will
`be at
`risk
`for
`incorrectly
`assuming
`packet
`loss,
`+
`•..
`and
`therefore,
`SHOULD allocate
`least
`twice
`that.
`at
`PPP Link Control
`Protocol
`Extensions
`PPP Reliable
`If
`reliable
`multilink
`operation
`is desired,
`[6]
`(essentially
`the
`use of
`ISO LAPB) MUST be negotiated
`use of
`the Multilink
`Protocol
`on each member
`link.
`Whether
`or not
`reliable
`delivery
`is
`employed
`over member
`implementation
`MUST present
`a signal
`to
`the NCP's
`running
`multilink
`arrangement
`that
`a
`loss
`has occurred.
`link,
`Compression
`may be used
`separately
`on each member
`link).
`the bundle
`(as a
`logical
`group
`The use of multiple
`compression
`streams
`under
`the bundle
`(i.e.,
`on each
`link
`is
`indicated
`by
`running
`the Compression
`Control
`Protocol
`an alternative
`PPP protocol
`ID.
`Configuration
`Option
`Types
`The Multilink
`Protocol
`introduces
`Configuration
`Options:
`o Multilink
`Maximum Received
`
`the
`
`use of additional
`
`LCP
`
`Reconstructed
`
`Unit
`
`Page 13
`
`EX 1006 Page 13
`
`

`

`rfcl990
`
`o Multilink
`o Endpoint
`
`Sequence
`Short
`Discriminator
`
`Number Header
`
`Format
`
`et.
`
`al.
`
`Sklower,
`"T
`RFC 1990
`
`5.1.1.
`
`Multilink
`
`Track
`Standards
`PPP Multilink
`
`[Page
`August
`
`13]
`1996
`
`MRRU LCP option
`Figure
`4: Multilink
`
`MRRU LCP option
`0
`3
`2
`1
`0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Type=
`17
`Length=
`4
`I Max-Receive-Reconstructed-Unit
`I
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`system
`the
`The presence
`of
`this
`LCP option
`indicates
`that
`it
`sending
`rejected,
`implements
`the
`PPP Multilink
`Protocol.
`If not
`the
`system
`as being
`will
`construe
`all
`packets
`received
`on
`link
`this
`able
`to be
`processed
`by a common protocol
`machine
`with
`any other
`packets
`received
`from
`the
`same peer
`on any other
`link
`on which
`this
`option
`has been
`accepted.
`is
`field
`specifies
`and
`two octets,
`unit
`The Max-Receive-Reconstructed
`Information
`of
`reassembled
`fields
`in
`the
`the maximum number
`of octets
`receive
`the
`full
`1500 octet
`to
`packets.
`A system MUST be able
`PPP packet
`although
`it MAY
`Information
`field
`of
`any
`reass