Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol
Network Working Group G. Malkin
Request for Comments: 2701 Nortel Networks
Category: Informational September 1999
Multi-link Multi-node PPP Bundle Discovery Protocol
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document specifies a standard way for Multi-link PPP to operate
across multiple nodes. Both the mechanism by which the Bundle Head
is discovered and the PPP fragment encapsulation are specified.
I would like to thank Joe Frazier for filling in some of the details
and reviewing this document.
Multi-link PPP [MP] allows a dial-in user to open multiple PPP
connections to a given host. In general, this is done on an on-
demand basis. That is, a secondary link, or multiple secondary
links, are established when the data load on the primary link, and
any previously established secondary links, nears capacity. As the
load decreases, the secondary link(s) may be disconnected.
Many dial-in hosts which support multi-link PPP dial the same phone
number for all links. This implies that there exists a rotary at the
Point Of Presence (POP) which routes incoming calls to a bank of
modems. These may be physically independent modems connected to
Remote Access Server (RAS) and a rotary of analog phone lines, or a
RAS with internal modems connected to analog lines or a T1/E1 or
T3/E3 channel. In any case, a given RAS can only handle just so many
simultaneous connections. A typical POP may need to support hundreds
of connections, but no RAS today can handle that many. This creates
a problem when a user's primary PPP connection is established to one
Malkin Informational [Page 1]
RFC 2701 MMP September 1999
RAS in a POP and a secondary connection is established to another.
This may occur because the first RAS has no available modems, or
because incoming calls are assigned to ports in a round-robin
fashion, for example, and the second call is simply assigned to
The solution to this problem is to provide a mechanism by which a RAS
can determine if a Multi-link PPP connection is a primary or
secondary and, if a secondary, where the Bundle Head (the process
within a RAS which reassembles the PPP fragments transmitted over the
primary and secondary links) resides. If the Bundle Head resides on
a different RAS, a protocol must be used to transfer the PPP
fragments to the RAS containing the Bundle Head so that the PPP frame
can be reassembled.
Section 2 of this document specifies the Discovery Mechanism.
Section 3 specifies the Transfer Protocol. Section 4 specifies the
configuration parameters needed for the Discovery Protocol.
2. Bundle Head Discovery Mechanism
When a user dials into a RAS and negotiates Multi-link PPP (MP)
during the Link Control Protocol (LCP) phase, the RAS must determine
which one of the following three cases exists:
1- This is the primary (first) link of the MP connection. In this
case, the RAS should create the Bundle Head.
2- This is a secondary link of the MP connection and the Bundle Head
resides on this RAS. In this case, the RAS should add the link to
the Bundle (standard MP).
3- This is a secondary link of the MP connection and the Bundle Head
resides on a different RAS. In this case, the RAS should
establish a path (see section 3) to the RAS that has the Bundle
Head, and use that path to transfer MP fragments.
In operation, a RAS will make the determination for case 2 first
(because it is the easiest and requires no communication with other
RASes. If the Bundle Head is not local, the Discovery Protocol is
used to determine where the Bundle Head is, if it exists at all.
Malkin Informational [Page 2]
RFC 2701 MMP September 1999
2.1 Packet Format
See "IANA Considerations" (section 6) for UDP port number assignment.
A Discovery Message has the following format:
| type |length| random ID | hash | endpoint ID |
type - 2 octets
Message type: 1-query, 2-response.
length - 2 octets
The length (in octets) of the endpoint ID.
Random ID - 4 octets
A random identifier generated by the RAS used to resolve
Show full document text