As per Relevance of the word channels, we have this rfc below:
Network Working Group K.
Request For Comments: 1934 Ascend
Category: Informational April 1996
Ascend's Multilink Protocol Plus (MP+)
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document proposes an extension to the PPP Multilink
(MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol
managing multiple data links that are bundled by MP
Table Of
1. Introduction.................................................2
1.1 Functional Description...............................2
1.2 Conventions..........................................3
2. General Overview.............................................3
2.1 Operation............................................4
3. MP+ Frame Formats............................................4
3.1 Error Control (EC) Layer.............................6
3.1.1 Error Control State Machine..................7
3.2 Multilink Plus Control Messages......................9
3.3 Multilink Plus Message Formats......................10
3.3.1 VERSION_EXCHANGE_REQ Message Format.........10
3.3.2 VERSION_EXCHANGE_RSP Message Format.........12
3.3.3 ADD_REQ Message Format......................13
3.3.4 ADD_RSP Message Format......................15
3.3.5 ADD_COMPLETE Message Format.................16
3.3.6 REMOVE_REQ Message Format...................17
3.3.7 REMOVE_RSP Message Format...................17
3.3.8 REMOVE_COMPLETE Message Format..............18
3.3.9 CLOSE_REQ Message Format....................19
3.3.10 CLOSE_RSP Message Format....................19
3.3.11 REMOTE_MGMT_REQ Message Format..............20
3.3.12 REMOTE_MGMT_RSP Message Format..............20
3.3.13 REMOTE_MGMT_RX_REQ Message Format...........21
3.3.14 REMOTE_MGMT_TX_REQ Message Format...........22
3.3.15 REMOTE_MGMT_TX_RSP Message Format...........22
3.3.16 CLEAR_REQ Message Format....................23
3.4 Events..............................................23
Smith Informational [Page 1]
RFC 1934 Multilink Protocol Plus April 1996
3.5 State Machine.......................................25
3.5.1 States......................................25
3.5.2 Common Actions..............................26
3.5.3 MP+STATE_INITIAL state machine..............32
3.5.4 MP+STATE_IDLE state machine.................35
3.5.5 MP+STATE_ADD state machine..................37
3.5.6 MP+STATE_REMOVE state machine...............41
3.5.7 MP+STATE_CLOSE state machine................44
4. PPP LCP Extensions..........................................46
5. Security Considerations.....................................47
6. References..................................................47
7. Author's Address............................................47
1.
The PPP Multilink Protocol (MP), is a set of features that
inverse multiplexing at the packet/fragment level by
multiple independent links between a fixed pair of systems,
a virtual link with greater bandwidth than any of the
members
Once multiple channels have been established MP is responsible
managing channel use to insure in-sequence delivery of user packets
MP+ is an extension to MP that adds an inband control channel
provide a new level of session management and control
MP+ also allows remote device management of (unconfigured) systems
This feature allows a network operations center to dial into
unconfigured system and remotely manage it, before
interface, IP address, and other LCP and system
information is entered. (This does require local configuration
the WAN interfaces to the extent required to answer an
call).
1.1 Functional
The features of MP+ include
* Ability to negotiate to add and subtract channels when
needs change
* Phone number management so calling stations need not know
possible number; answering stations can manage their own resources
* A simple remote management interface
Smith Informational [Page 2]
RFC 1934 Multilink Protocol Plus April 1996
To perform the above functions MP+ is split into a call
layer and a reliable delivery layer. The call management layer
the source and sink of MP+ control messages. The reliable
layer adds a simple acknowledge and retry mechanism
MP+ only takes network bandwidth when in the process of performing
user request, e.g. adding and subtracting bandwidth
NOTE: Neither MP, or MP+ define the process that makes the
requirement determination. That is outside the scope of either
these protocols and will likely be implementation dependent
1.2
The following language conventions are used in the items
specification in this document
MUST, SHALL or MANDATORY -- the item is an absolute
of the specification
SHOULD or RECOMMENDED -- the item should generally be
for all but exceptional circumstances
MAY or OPTIONAL -- the item is truly optional and may be
or ignored according to the needs of the implementor
2. General
In order to establish communications over a point-to-point link
each end of the PPP [2] link must first send LCP packets
configure the data link during link establishment phase.
the link has been established, PPP provides for an
phase
MP The goal of multilink operation is to bundle
independent links between a fixed pair of systems, providing
virtual link with greater bandwidth than any of the
members
MP+ MP+ is also negotiated during initial LCP option negotiation.
system indicates to its peer that it is willing to do MP+
sending the MP+ option as part of the initial LCP
negotiation. The MP+ option MUST NOT be negotiated unless MP
also negotiated. When used, MP+ adds a virtual unit-to-
control channel
A peer may elect to
Smith Informational [Page 3]
RFC 1934 Multilink Protocol Plus April 1996
Acknowledge both the MP and MP+ options, indicating that both MP
MP+ will be used
Acknowledge the MP option and reject the MP+ option. Operation
fall back to MP
Reject both options. Standard PPP will be used for this connection
2.1.
Standard
In standard PPP the LCP negotiation phase is followed by
optional authentication phase, and then one or more NCPs
initiated
PPP with MP The LCP negotiation phase and authentication phase
identical to standard PPP. The ability to initiate an
aggregate data link is indicated by sending an MP option -
described in [1].
PPP with MP and MP+ When MP+ is negotiated at LCP startup, the
procedures are followed as when MP is negotiated alone. The MP
LCP option is negotiated to indicate the ability to use the MP
feature.The first connection between endpoints causes the MP
process to be started for the connection
3. MP+ Frame
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP Header: |1|1|0|0|0|0|0|1| seq # high |
+-+-+-+-+-------+---------------+
| sequence number low bits |
+---------------+---------------+
| control data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Figure 1: Multilink Plus Frame Format (long sequence number format
Smith Informational [Page 4]
RFC 1934 Multilink Protocol Plus April 1996
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP Header: |1|1|0|1| sequence number |
+-+-+-+-+-------+---------------+
| control data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Figure 2: Multilink Plus Frame Format (short sequence number format
MP+ frames use a similar structure to MP fragments
The MP+ assigned PID is designated 00 73.
MP+ control uses the following two rules
- MP+ control frames have their own sequence number space
controlled by MP+.
- MP+ control frames MUST NOT be fragmented
NOTE: Implementations of this protocol prior to the date of
of this specification to the IETF use the same PID as MP,
sets the LSB of the reserved bits in the MP header to 1 -
is how the MP+ packets are discriminated from MP fragments
So the header of the MP+ packet looks like
00 3d c1 ......
As compared to an MP packet that looks like
00 3d c0 ......
00 3d 80 ......
00 3d 40 ......
Smith Informational [Page 5]
RFC 1934 Multilink Protocol Plus April 1996
3.1. Error Control (EC) Layer (MP+ control only
The error control layer that runs over the virtual inband channel
as simple as it can get, while handling the possibility of errors
the line
An assumption is made that errors are infrequent, and that at
same time messages are rarely, if ever, dropped on the floor.
implication of this is that "timing out" on retransmission
messages does no harm. If a message cannot get through, then
simply is retried some number of times. After giving up, the
recourse is to notify the call management layer (of MP) that
session has died
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP+ Header: |1|1|0|0|0|0|0|1| seq # high |
+-+-+-+-+-------+---------------+
| sequence number low bits |
+---------------+---------------+
EC Header: | Error Control Message Type |
| 32 bits reserved |
+---------------+---------------+
MP+ Data: | MP+ Message | May not
| | present
Figure 3: MP+ control message format (shown long sequence
format
Error Control Message Type
1 DATA_MSG: This message contains MP+ data
between the peers
2 ACK_MSG: An acknowledgement of a previous data message
When set to DATA_MSG, the remainder of the frame contains an MP
Control message
When set to ACK_MSG, the remainder of the frame consists only of
PPP Frame Check Sum (FCS).
Smith Informational [Page 6]
RFC 1934 Multilink Protocol Plus April 1996
3.1.1. Error Control State
This layer is controlled by a simple state machine. There are
states
Stopped There is no connection between peers
Idle There is a connection between peers
no unacknowledged messages pending
Pending There is a connection between peers
awaiting an acknowledgement to
last message sent
Messages from the call management layer are queued for
whenever the link is in the pending state. For simplicity,
one outstanding message may be in the link at any given time.
entire procedure is defined in table 1.
Event
______________________________________________________________________
Stopped Idle
======================================================================
Start 1,Idle -,* -,*
______________________________________________________________________
Received ACK_MSG ** 2,Start 5,Idle|
current tx sequence
______________________________________________________________________
Received ACK_MSG ** -,* -,*
last tx sequence
______________________________________________________________________
Received ACK_MSG ** 2,Start 2,
other tx sequence
______________________________________________________________________
Received DATA_MSG ** 6,* 6,*
current rx sequence
______________________________________________________________________
Received DATA_MSG ** 7,* 7,*
previous rx sequence
______________________________________________________________________
Received DATA_MSG ** 2,Start 2,
other rx sequence
______________________________________________________________________
Receive Invalid Frame ** 2,Start 2,
______________________________________________________________________
Retransmit Timer Expire ** ** 4,Start|*
______________________________________________________________________
Smith Informational [Page 7]
RFC 1934 Multilink Protocol Plus April 1996
______________________________________________________________________
Transmit Request from call -,* 3,Pending 8,*
management
______________________________________________________________________
Stop 9,Start 9,Start 9,
______________________________________________________________________
Table 1: Error Control State
Legend
- No
* Stay in same
** Invalid or meaningless event for state, ignored
Notes
[1] Data from the call management layer will always be copied
being queued for transmission. The call management layer
responsible for its own buffers
[2] MP always copies data for transmission and returns immediately
Any buffers allocated to build control messages MUST be
immediately upon return from MP transmission requests
Actions
1 Reset rx sequence
Reset tx sequence
Reset tx retransmit
Stop retransmit
2 Report error to
Stop retransmit
Stop frame transmit
Free
3 Save call management message in pending transmit
Build DATA_MSG from first message in pending
queue using current tx sequence number
Send message to MP for transmission
Reset tx retransmit
Smith Informational [Page 8]
RFC 1934 Multilink Protocol Plus April 1996
4 Increment tx retransmit
If tx retransmit count >= RETRANSMIT_
Action 2 (followed by state change to the Start state
Build DATA_MSG from first message in
transmit queue using current tx sequence number
Send message to MP for transmission
5 Dequeue first element on pending transmit queue and
its
Increment the tx sequence
Stop the retransmit
if pending transmit queue not
Build DATA_MSG from first message in
transmit queue using current tx sequence number
Send message to MP for transmission
Reset tx retransmit
6 Build ACK_MSG using the current rx sequence
Send ack message to MP for
Pass message to call managment
Increment rx sequence
7 Build ACK_MSG using the previous rx sequence
Send the ack message to MP for
8 Add the message to the end of the pending transmit
9 Stop retransmit
Free
3.2. Multilink Plus Control
Message Type
VERSION_EXCHANGE_REQ 1
VERSION_EXCHANGE_RSP 2
ADD_REQ 3
ADD_RSP 4
ADD_COMPLETE 5
REMOVE_REQ 6
REMOVE_RSP 7
REMOVE_COMPLETE 8
CLOSE_REQ 9
CLOSE_RSP 10
REMOTE_MGMT_REQ 11
REMOTE_MGMT_RSP 12
REMOTE_MGMT_RX_REQ 13
REMOTE_MGMT_TX_REQ 14
Smith Informational [Page 9]
RFC 1934 Multilink Protocol Plus April 1996
REMOTE_MGMT_TX_RSP 15
CLEAR_REQ 16
3.3. Multilink Plus Message
The fields of all messages defined here MUST be encoded/decoded
Network Byte Order (big endian).
3.3.1. VERSION_EXCHANGE_REQ Message
The version exchange message is sent by the call originator to
the answerer the version of the MP+ protocol being used as well
any other information that may need to be conveyed outside of
normal PPP parameter negotiation
+---------------+---------------+
| Message type |
| 0x00000001 |
+---------------+---------------+
| Protocol Version |
+---------------+---------------+
| Protocol Revision |
+---------------+---------------+
| Session Identifier |
+---------------+---------------+
| Hardware Type |
+---------------+---------------+
| Nailed Mode |
+---------------+---------------+
| Use Multiple Trunk Groups |
+---------------+---------------+
| Descriptor Length |
+---------------+---------------+
| Descriptor |
+---------------+---------------+
Figure 4: Version Exchange
A message sent from call originator to call answerer specifying
callers protocol version and other state info and requesting
answerer to respond with its version info
Protocol Version
caller MP+ protocol version number
2 octets fixed length (initially 1)
Smith Informational [Page 10]
RFC 1934 Multilink Protocol Plus April 1996
Protocol Revision
caller MP+ protocol revision number
2 octets fixed length (initially 4)
Session Identifier
A non-zero identifier unique to the caller
2 octets fixed length
Hardware Type
caller hardware type (can be vendor defined).
2 octets fixed length
Nailed Mode
caller nailed mode from the session profile
2 octets fixed length
Use Multiple Trunk Groups
non-zero if the call may use channels from multiple
groups
2 octets fixed
Descriptor Length
length of the end point descriptor
2 octets fixed
Descriptor
the end point descriptor. This field allows for
specific identification of the peer
Variable length as defined above
Smith Informational [Page 11]
RFC 1934 Multilink Protocol Plus April 1996
3.3.2. VERSION_EXCHANGE_RSP Message
The version exchange response message is sent by the call answerer
response to a version exchange request message. The answerer
the message to inform the caller the version of the MP+
being used as well as any other information that needs to be
outside of the normal PPP parameter negotiation
+---------------+---------------+
| Message type |
| 0x00000002 |
+---------------+---------------+
| Protocol Version |
+---------------+---------------+
| Protocol Revision |
+---------------+---------------+
| Session Identifier |
+---------------+---------------+
| Hardware Type |
+---------------+---------------+
| Nailed Mode |
+---------------+---------------+
| Use Multiple Trunk Groups |
+---------------+---------------+
| Descriptor Length |
+---------------+---------------+
| Descriptor |
+---------------+---------------+
Figure 5: Version Exchange
A message sent from call answerer to the call originator
the answerers protocol version and other state info. Sent
response to receiving a version exchange request
Protocol Version
caller MP+ protocol version number
2 octets fixed length (initially 1)
Protocol Revision
caller MP+ protocol revision number
2 octets fixed length (initially 4)
Session Identifier
A non-zero identifier unique to the answerer
2 octets fixed length
Smith Informational [Page 12]
RFC 1934 Multilink Protocol Plus April 1996
Hardware Type
caller hardware type (can be vendor defined).
2 octets fixed length
Nailed Mode
caller nailed mode from the session profile
2 octets fixed length
Use Multiple Trunk Groups
non-zero if call may use channels from multiple trunk groups
2 octets fixed
Descriptor Length
length of the remote descriptor in 4-octet units
2 octets fixed
Descriptor
the remote unit descriptor. This field allows for
specific identification of the peer
Variable length Nx4 octets long - total length defined above
3.3.3. ADD_REQ Message
A message of this type is sent by either caller or answerer
initiate an increase of bandwidth. When sent by the caller
request is asking for permission to dial a certain number
channels; the response will contain permission and the phone
of the channels to dial. When sent by the answerer, this
contains the phone numbers to dial. The message looks like
+---------------+---------------+
| Message type |
| 0x00000003 |
+---------------+---------------+
| Number of channels requested |
+---------------+---------------+
| Number of phone numbers |
+---------------+---------------+
| A phone number list for |
| each phone number |
| . |
| . |
| . |
+---------------+---------------+
Figure 6: Add
Smith Informational [Page 13]
RFC 1934 Multilink Protocol Plus April 1996
A message sent by either caller or answerer to request that
bandwidth be added to a session
Number of channels requested
The maximum number of channels to add
2 octets fixed length
Number of phone numbers
The number of phone numbers provided.
value will always be zero when the
initiates an add and will be at
Number of channels requested when the
initiates the add
2 octets fixed length
Phone number list
A list of up to 32 phone number
containing the phone numbers to call
Each description is of fixed length as described below
Each phone number is represented by a phone number list
The format of a phone number list is
+---------------+---------------+
| in use flag |
+---------------+---------------+
| call service type |
+---------------+---------------+
| Phone number |
| 20 octets |
| plus null terminator |
| (21 octet total) |
| |
| |
| |
| |
| |
| |
| +---------------+
| | Must be 0 |
+---------------+---------------+
| must be 0 |
+---------------+---------------+
Figure 7: Phone number
Smith Informational [Page 14]
RFC 1934 Multilink Protocol Plus April 1996
A structure containing information about a connection within
system
in use flag
non-zero if the phone number
in this descriptor is currently in use
2 octets fixed
call service type
Defines the type of service, switched, nailed
or other, associated with a phone number
1
2
>=3
Phone number
The null terminated phone number of this channel
Fixed length 21 octets. Each octet contains IA5
representation of a digit (or #, *).
Must be 0:
Filler to force alignment to 32-bit boundary
3.3.4 ADD_RSP Message
A message of this type gives permission to dial some number
channels and, when sent by the answerer of the original call,
the phone numbers of channels to dial
+---------------+---------------+
| Message type |
| 0x00000004 |
+---------------+---------------+
| Number of channels allowed |
+---------------+---------------+
| Number of phone numbers |
+---------------+---------------+
| A phone number list for |
| each phone number |
| . |
| . |
| . |
+---------------+---------------+
Figure 8: Add
Smith Informational [Page 15]
RFC 1934 Multilink Protocol Plus April 1996
A message sent by either caller or answerer to indicate the number
channels that may be added to a session
Number of channels allowed
The actual number of channels to add.
may be less than the number requested
2 octets fixed length
Number of phone numbers
The number of phone numbers provided.
value will always be zero when sent by
caller and will be at least
when sent by the answerer
2 octets fixed length
Phone number list
A list of up to 32 phone number
containing the phone numbers to call
Each description is of fixed length as described above
3.3.5. ADD_COMPLETE Message
This message is sent by the caller to the answerer after all
have been placed. The message is used to notify the answerer
the add transaction is complete and it may return to the idle state
+---------------+---------------+
| Message type |
| 0x00000005 |
+---------------+---------------+
| Channels added |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 9: Add
A message sent by caller to indicate the number of channels that
added successfully. This message was added in MP+ Version 1.1.
Channels added
The actual number of channels added
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
Smith Informational [Page 16]
RFC 1934 Multilink Protocol Plus April 1996
3.3.6. REMOVE_REQ Message
A message of this type is sent when a peer decides, for any reason
to remove channels from use. The purpose of the message is to
the remote end of the remove and give it a chance to adjust
number of channels to remove
+---------------+---------------+
| Message type |
| 0x00000006 |
+---------------+---------------+
| Number of channels to remove |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 10: Remove
A message sent by either caller or answerer to request that
be removed from a session
Number of channels to remove
The maximum number of channels to remove
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
3.3.7. REMOVE_RSP Message
This message is sent in response to a remove request. The
specifies the number of channels that can be removed. If
response specifies 0 channels the remove is cancelled
+---------------+---------------+
| Message type |
| 0x00000007 |
+---------------+---------------+
| Number of channels to remove |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 11: Remove
Smith Informational [Page 17]
RFC 1934 Multilink Protocol Plus April 1996
A message sent in response to a remove request specifying the
of channels that the peer agrees can be removed
Number of channels to remove
The maximum number of channels to remove
May be zero, in which case the remove
cancelled
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
3.3.8. REMOVE_COMPLETE Message
This message is sent by the initiator of a remove transaction
the agreed upon number of channels have been removed. The message
used to notify the peer that the remove transaction is complete
it may return to the idle state
+---------------+---------------+
| Message type |
| 0x00000008 |
+---------------+---------------+
| Number of channels removed |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 12: Remove
A message sent by the caller or answerer to indicate how many
were actually removed. This message was added in MP+ CM version 1.1.
Number of channels removed
The number of channels that were removed
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
Smith Informational [Page 18]
RFC 1934 Multilink Protocol Plus April 1996
3.3.9. CLOSE_REQ Message
This message is sent when the peer requests to close the
session. This is typically due to a configuration option
indicates when a system should request to close the session (
example being, a link has been idle for greater than a
time period).
+---------------+---------------+
| Message type |
| 0x00000009 |
+---------------+---------------+
Figure 13: MP+ close request
There are no data fields associated with this message
3.3.10. CLOSE_RSP Message
If the peer agrees that closing the session is acceptable based
it's own configuration (an example reject reason would be that
peer is configured with a *minimum* number of channels to
active).
+---------------+---------------+
| Message type |
| 0x0000000a |
+---------------+---------------+
| OK To Close |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 14: MP+ close
The response to a close request. May be sent by caller or answerer
OK To Close
If non-zero, peer said I can close all channels
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
Smith Informational [Page 19]
RFC 1934 Multilink Protocol Plus April 1996
3.3.11. REMOTE_MGMT_REQ Message
This message is sent from a master station to a slave station
the master wishes to manage the remote station. The message is
used to cancel remote management once it's been started
+---------------+---------------+
| Message type |
| 0x0000000b |
+---------------+---------------+
| Mode |
+---------------+---------------+
| Must be zero |
+---------------+---------------+
Figure 15: Remote Management
A message sent from master to slave to initiate or clear a
management session
Mode
One to start session. Zero to stop session
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
3.3.12. REMOTE_MGMT_RSP Message
The slave side of a remote management session has the opportunity
reject remote management. The master side is informed of accept/
status via the remote management response
+---------------+---------------+
| Message type |
| 0x0000000c |
+---------------+---------------+
| Mode |
+---------------+---------------+
Figure 16: Remote Management
A message sent from slave to master to allow or deny initiation of
remote management session
Smith Informational [Page 20]
RFC 1934 Multilink Protocol Plus April 1996
Mode
One to accept session. Zero to deny session
2 octets fixed
Must be zero
Padding to 32-bit boundary
2 octets fixed
3.3.13. REMOTE_MGMT_RX_REQ Message
This message type is used to convey keyboard input from
management master to be processed by the management slave.
message format consists of an octet count (in network byte order)
then an array of octets to be processed. It looks like
+---------------+---------------+
| Message type |
| 0x0000000d |
+---------------+---------------+
| character count |
+---------------+---------------+
| array of characters |
| . |
| . |
| . |
+---------------+---------------+
Figure 17: Remote Management Receive
A message sent from master to slave, conveying keystrokes typed on
masters keyboard that will be processed by the slave
character count
Number of characters to process
2 octets fixed
array of characters
Array of characters to process
Smith Informational [Page 21]
RFC 1934 Multilink Protocol Plus April 1996
3.3.14. REMOTE_MGMT_TX_REQ Message
The remote management slave conveys output to be displayed on
masters terminal with a remote management transmit request message
Only one message may be outstanding. The next transmit request
not be sent until the previous has been acknowledged
+---------------+---------------+
| Message type |
| 0x0000000e |
+---------------+---------------+
| character count |
+---------------+---------------+
| array of characters |
| . |
| . |
| . |
+---------------+---------------+
Figure 18: Remote Management Transmit
A message sent from slave to master, conveying output to be output
the master's display
Character count
Number of characters to process
2 octets fixed
array of characters
Array of characters to process
3.3.15. REMOTE_MGMT_TX_RSP Message
This message is used to acknowledge remote management
requests. The slave may send the next transmit request once
message has been received
+---------------+---------------+
| Message type |
| 0x0000000f |
+---------------+---------------+
Figure 19: Remote Management Transmit
There are no data fields associated with this message
Smith Informational [Page 22]
RFC 1934 Multilink Protocol Plus April 1996
3.3.16. CLEAR_REQ Message
A message sent to initiate a friendly shutdown of an MP+ link.
sender will stop sending data immediately. The receiver of
message will also stop sending user data and start a clean
of all NCPs and the LCP of each member link of the bundle. When
last member link terminates, the session is completely closed
+---------------+---------------+
| Message type |
| 0x00000010 |
+---------------+---------------+
Figure 20: Clear
There are no data fields associated with this message
3.4.
The MP+ state machine is event driven. Reception of an event
an action and possibly a state change. The events processed by
MP+ state machine can be roughly classed into two types
Events that originate within the unit, e.g. notification that
call has cleared, an MP+ session may be started, etc
Events that originate with the reception of an MP+
message from the peer unit
Both types are processed by the state machine in the sequence
occurred. The events processed are
MP+START_SESSION: Notification from PPP/MP that
MP+ session is starting
MP+SESSION_DOWN: Notification from the error-
layer that end-to-end
has been lost and control messages
not be delivered
MP+SESSION_TERM: Session termination notification
PPP/MP. This event is not sent
the last channel of a multi-
session is cleared
MP+TIMER_EXPIRED: Timers are used in various states
sub-states. This event is signaled
a timer expires
Smith Informational [Page 23]
RFC 1934 Multilink Protocol Plus April 1996
MP+CALL_COMPLETE: A call placed during an add request
completed. The call may have succeeded
failed
MP+UTILIZATION: Notification from MP/PPP that
utilization has crossed a threshold and
channels may need to be added/removed
(The number of channels to add/remove will
passed with the notification).
MP+RX_VERSION_REQ: A Version Exchange request message
been received from the peer
MP+RX_VERSION_RSP: A Version Exchange response message
been received from the peer
MP+ADD_REQ: An Add request message has been
from the peer
MP+ADD_RSP: An Add response message has been
from the peer
MP+ADD_COMP: An Add Complete message has been
from the peer
MP+REMOVE_REQ: A Remove request message has been
from the peer
MP+REMOVE_RSP: A Remove response message has
received from the peer
MP+REMOVE_COMP: A Remove Complete message has been
from the peer
MP+RX_RM_REQ: A Remote Management request has been
from the peer
MP+RX_RM_RSP: A Remote Management response has been
from the peer
MP+RX_RM_RX_REQ: A Remote Management Receive Request has
received from the far end
MP+RX_RM_TX_REQ: A Remote Management Transmit Request
been received from the peer
Smith Informational [Page 24]
RFC 1934 Multilink Protocol Plus April 1996
MP+RX_RM_TX_RSP: A Remote Management Transmit Response
been received from the peer
MP+RX_CLEAR: A request to shut down the session has
received from the peer
MP+CLOSE_REQ: A Close Request message has been
from the peer
MP+CLOSE_RSP: A Close Response message has been
from the peer
MP+START_RM Request to start a remote management
with this station being the master
MP+SEND_RMS: Request to send data to a remote
master from a slave
MP+SEND_RMM: Request to send data to a remote
slave from a master
MP+RECV_RMM: Request to send an ack to a remote
slave for data received from the slave
MP+STOP_RM: Request to stop a remote management session
3.5. State
3.5.1
To ease readability and understanding the major states are
as separate state machines, each having two to four sub-states.
sub-states are named by the letters, A, B, C, and D.
information is maintained for every interface
The major states are
MP+STATE_INITIAL: The state of an unused session. Session
entries are intialized to this state at
and return to this state when sessions
terminated
MP+STATE_IDLE: The state of an active session that is
performing any MP+ function
MP+STATE_ADD: The state of a session when an add transaction
in progress
Smith Informational [Page 25]
RFC 1934 Multilink Protocol Plus April 1996
MP+STATE_REMOVE: The state of a session when a remove transaction
in progress
MP+STATE_CLOSE: The state of a session that is in the process
being closed
State transitions are triggered by the reception of an event.
2 through 6 contain the state tables for the major states. All
tables use the following symbols
- No
* Stay in same
+ Target state is defined by the action
** An error has occurred, log an error message but
state change
States and sub-state transitions are noted as state:sub-state, e.g.,
initial:A. Alternative transitions are listed on separate lines
3.5.2 Common
Some actions are common to all states, they are defined here
Error Close
Called to close a session when an error occurs. Actions are
[1] Stop timer if running
[2] Log an error message
[3] Close the MP+EC layer for this session
[4] Close MP for this
[5] Clean up, restore state variables to their initial state
Term
Processed when a MP+SESSION_TERM event occurs in most states
Actions are
[1] Stop timer if running
[2] Close the MP+EC layer for this session
Smith Informational [Page 26]
RFC 1934 Multilink Protocol Plus April 1996
[3] Call the passed termination callback function if not null
[4] Clean up, restore state variables to their initial state
Ignore
We don't care about this event in this state. Do nothing
Timer
This action is called when a timer expires in one of the on-
states. The timer is used to implement add and remove locks.
lock is set when an add or remove fails and is not cleared
a bandwidth change or the timer expires. This keeps us
retrying add's and subtracts until there is a likelyhood that
will succeed
[1] Check add lock flag
[1] If set an add lock occured last timeout period
triple the timeout value (to a max of 81 minutes).
[2] If not set restore the timeout value to its
value of one minute
[2] Clear the add lock flag
[3] Clear the remove lock flag
[4] Restart the retry timer
Enter Remove [local]
The local unit is initiating a remove transaction. The
bandwidth is given
[1] Restart the idle timer
[2] Calculate number of channels to remove (difference
number in use and number in desired).
[3] Build and send a remove request and send to remote
[4] Go to REMOVE:A
Smith Informational [Page 27]
RFC 1934 Multilink Protocol Plus April 1996
Enter Remove [remote]
The remote unit is initiating a remove transaction. The
message contains the number of channels to remove
[1] Restart the idle timer
[2] Request the number of channels required. If greater than
number available after removing the number of channels
in the incoming message reduce the number of channels to
and set a remove lock
[3] Build a remove response message indicating the number
channels we will allow the requester to remove and send to
remote
[4] Go to REMOVE:B
Enter Add [local]
The local unit is initiating an add transaction. We are
the number of channels desired. The steps are
[1] Restart the idle timer
[2] Calculate number of channels to add (difference
number desired and number in use).
[3] Reserve number of channels, retrieving their phone numbers
[4] If number of channels reserved less than the number
set an add lock
[5] If number of channels reserved greater than zero
[1] Build an add request. If the answerer the
includes the phone numbers for the caller to dial
[2] If caller, go to ADD:A
[3] If answerer, go to ADD:C
[6] Go to IDLE state
Smith Informational [Page 28]
RFC 1934 Multilink Protocol Plus April 1996
Enter Remove [remote]
The remote unit is initiating a remove transaction.
incoming message contains the number of channels to remove
[1] Clear the remove lock
[2] Restart the idle timer
[3] Request the number of channels required. If
than the number available after removing the number
channels indicated in the incoming message reduce
number of channels to remove
[4] Build a remove response message indicating the
of channels we will allow the requester to remove
send to the remote
[5] Go to REMOVE, sub-state B
Enter Add [remote answerer]
We've received a message from the remote requesting
bandwidth be added. The message contains the number
channels to add. Since the remote is the answerer, the mes
sage also contains the phone nubmers to dial. We may
less than the number requested
[1] Restart idle timer
[2] If the number of channels requested will put us
the maximum number of channels allowed for the
reduce the channel count
[3] For each channel to add
[1] Integrate the phone number returned from
answerer with the original phone number dialed
[2] Request that a session be extended by
the integrated phone number. A callback
passed with the request so call success or fail
ure can be reported back to MP+.
[4] Go to ADD:B. Note: This change must actu
ally occur before requesting the first outgoing call
If not, the callback could be called (and ignored
because the session is not in the correct state
Smith Informational [Page 29]
RFC 1934 Multilink Protocol Plus April 1996
Enter Add [remote caller]
We've received a message from the remote requesting
bandwidth be added. The message contains the number
channels to add. Since the remote is the caller, it
us to send the phone numbers to dial. We may send
phone numbers than
[1] Restart idle timer
[2] If the number of channels requested will put us
the maximum number of channels allowed for the
reduce the channel count
[3] Reserve the adjusted number of channels,
their phone numbers
[4] If the number of channels reserved is less than
adjusted number requested
[5] Build an add response message, including the
numbers for the channels we will let the caller
and send it to the far end
[6] Go to ADD:C
Enter Idle
The IDLE state is entered at the end of normal transactions
At entry the current status of the connection should
checked and new transactions initiated if necessary. To
safe, we can also use this state as a catch all place
release any bandwidth reserved for adds. The functions
perform are
[1] Restart the idle timer using the current retry value
[2] Release any reserved bandwidth not actually in use
[3] Check if bandwidth change reqested during last trans
action. If change indicated
[1] Query channel counts
[2] If current bandwidth less than suggested band
width and removes are not locked, store
requested bandwidth and initiate a remove trans
action (Enter Remove Action).
Smith Informational [Page 30]
RFC 1934 Multilink Protocol Plus April 1996
[3] If current bandwidth greater than
bandwidth and adds are not locked
[1] Store the requested bandwidth
[2] Intiate an add transaction (Enter
[local] Action).
[4] Go to the IDLE state
Remote Management Request
We received a request to start/stop remote management
If this is a start
If we can/allow remote management
Build and send a Remote management response
message
Build and send a Remote management response
message
Else (this is a stop
Notify the remote management slave process to terminate
Remote Management Response
We received a response to our remote management start request
If the response was an Allow
Notify the remote management master process, we
start sending keystrokes/
The peer denied the request, so notify the
management master process of failure
Remote Management Receive Data
We (the slave) received data from the remote management master
Pass the received data to the remote management slave process
This is typically keystroke data received from the remote
interface
Remote Management Transmit Data
We (the master) received data from the remote management slave
Pass the received data to the remote management master process
This is typically screen-updates to be passed to the
interface
Smith Informational [Page 31]
RFC 1934 Multilink Protocol Plus April 1996
Remote Management Transmit Data Response
We (the slave) received an ack to data we previously sent to
master. Notify the remote management slave process so that
can queue further transmissions
Remote management (Master) start
Build a REMOTE_MGMT_REQ start message and send to the far end
Send a proceeding message to the RM master process
Remote management (Slave) data
Build a REMOTE_MGMT_TX_REQ message with the data passed
the remote management slave process, send it to the far end
Remote management (Master) data
Build a REMOTE_MGMT_RX_REQ message with data passed from
remote management master process, send it to the far end
Remote management data acknowledgement
Build a REMOTE_MGMT_TX_RSP message and send it so the slave
send the next block. There is no data associated with
message
Remote management (Master) stop
Build a REMOTE_MGMT_REQ stop message and send to the far end
3.5.3. MP+STATE_INITIAL state
All sessions start from this state, sub-state A. The state is
exited until version exchange succeeds
The sub-states are
A Initial
B Sent version request, waiting for version response
C Waiting for version request
Smith Informational [Page 32]
RFC 1934 Multilink Protocol Plus April 1996
Event Sub-
______________________________________________________________________
A B
======================================================================
MP+START_SESSION 1,+ ** **
______________________________________________________________________
MP+SESSION_DOWN ** 2,Initial:A 2,Initial:
______________________________________________________________________
MP+SESSION_TERM ** 3,Initial:A 3,Initial:
______________________________________________________________________
MP+TIMER_EXPIRED ** 4,Initial:A 7,Initial:
______________________________________________________________________
MP+RX_VERSION_REQ ** 8,Initial:A 5,+
______________________________________________________________________
MP+RX_VERSION_RSP ** 6,+ **
______________________________________________________________________
MP+START_RM 9,* 9,* 9,*
______________________________________________________________________
All other events ** ** **
______________________________________________________________________
Table 2: Initial State
Actions
1 Start timer, 60 seconds if originator, 30 seconds if answerer
Start MP
If
Build and send version exchange
Go to INITIAL, sub-state B
Go to INITIAL, sub-state C
2 Do Error Close Action, go to INITIAL, sub-state A
3 Do Term Action, go to INITIAL, sub-state A
4 Do Error Close Action, go to INITIAL, sub-state A
5 Stop the idle timer
Compare protocol versions, if they do not match Do Error
Action, go to INITIAL, sub-state A
Smith Informational [Page 33]
RFC 1934 Multilink Protocol Plus April 1996
Store off info received from remote
Build a version exchange response and send to remote end
Do Enter Idle Action which causes a state change
6 Stop the retry timer
Compare protocol versions, if they do not match Do Error
Action, go to INITIAL, sub-state A
Store off info received from remote
Check the base channel count in the callers profile
If greater than 1
Set the requested bandwidth to the base channel count
Do Enter Add Caller action which causes a state change
Do Enter Idle Action which causes a state change
7 Both sides think they are the answerer. This is possible if
dial each other at the same time and the first channel
completed PPP negotiation happened to be the channel
with the incoming call on both units. We resolve this by
to become the originator
If both sides try to become the originator the one with
largest endpoint discriminator will fall back to being
answerer
Restart Idle timer at 60
Build and send Version Exchange Request
Go to Initial:
8 Both sides think they are the originator. This can happen
both dial each other at the same time and the first
that completed PPP negotiation happened to be the
associated with the originating call on both units. MP
determines which will be the caller and which the answerer
comparing the endpoind discriminator in the version
request with the local endpoint discriminator. The unit
the smaller endpoint is arbitrarily called the originator.
actions are
Smith Informational [Page 34]
RFC 1934 Multilink Protocol Plus April 1996
Compare local endpoint discriminator with endpoint
in message
If local endpoint discriminator is less than the remote
we are the caller, ignore the incoming message
Otherwise, if local endpoint discriminator is greater than
remote value we are the answerer
Compare protocol versions, if they do not
Do Error Close Action, go to INITIAL, sub-state A
Store off info received from remote
Build a version exchange response and send to remote end
Do Enter Idle Action which causes a state change
If the two values match, there is a problem, Do Error
Action,go to INITIAL, sub-state A
9 Log an error message
Notify the user interface of remote management failure
3.5.4. MP+STATE_IDLE state
The Idle state is the state of an active session with no
management activity in progress
There are no sub-states
Event
_____________________________________________
=============================================
MP+SESSION_DOWN 1,Initial:
_____________________________________________
MP+SESSION_TERM 2,Initial:
_____________________________________________
MP+TIMER_EXPIRED 3,*
_____________________________________________
MP+UTILIZATION 4,+
_____________________________________________
MP+RX_ADD_REQ 5,+
_____________________________________________
MP+RX_REMOVE_REQ 6,Remove:
_____________________________________________
MP+RX_RM_REQ 7,+
Smith Informational [Page 35]
RFC 1934 Multilink Protocol Plus April 1996
_____________________________________________
MP+RX_RM_RSP 8,+
_____________________________________________
MP+RX_RM_RX_REQ 9,+
_____________________________________________
MP+RX_RM_TX_REQ 10,+
_____________________________________________
MP+RX_RM_TX_RSP 11,+
_____________________________________________
MP+RX_CLOSE_REQ 12,+
_____________________________________________
MP+START_RM 13,*
_____________________________________________
MP+SEND_RMS 14,*
_____________________________________________
MP+SEND_RMM 15,*
_____________________________________________
MP+RECV_RMM 16,*
_____________________________________________
MP+STOP_RM 17,*
_____________________________________________
All other events **
_____________________________________________
Table 3: Idle State
Actions
1 Do Error Close Action, go to INITIAL, sub-state A
2 Do Term Action, go to INITIAL, sub-state A
3 Do Timer Action
4 Note that a bandwidth change has been reqested
Do Enter Idle Action which may cause a state change
5 If we are the caller
Do Enter Add [remote answerer] Action
Do Enter Add [remote caller] Action
6 Do Enter Remove [remote]
7 Do Remote Management Request
8 Do Remote Management Response
Smith Informational [Page 36]
RFC 1934 Multilink Protocol Plus April 1996
9 Do Remote Management Receive Data
10 Do Remote Management Transmit Data
11 Do Remote Management Transmit Data Response
12 Clear remove lock
If local recommended channels == 0, then
send a Close Response message with OK To
set to TRUE
send a Close Response message with OK To
set to FALSE
Do Enter Idle Action
13 Do Remote management (Master) start
14 Do Remote management (Slave) data
15 Do Remote management (Master) data
16 Do Remote management data acknowledgement
17 Do Remote management (Master) stop
3.5.5. MP+STATE_ADD state
The add state is used by both caller and answerer when an
transaction is in progress
The sub-states are
A Add request sent to answerer, waiting for add
from the answerer
B Caller waiting for call complete notification for
placed
C Answerer waiting for add complete message from caller
Smith Informational [Page 37]
RFC 1934 Multilink Protocol Plus April 1996
Event Sub-
______________________________________________________________________
A B
======================================================================
MP+SESSION_DOWN 1,Initial:A 7,Closing:A 1,Initial:
______________________________________________________________________
MP+SESSION_TERM 2,Initial:A 7,Closing:B 2,Initial:
______________________________________________________________________
MP+TIMER_EXPIRED 3,+ 3,+ 3,+
______________________________________________________________________
MP+UTILIZATION 4,* 4,* 4,*
______________________________________________________________________
MP+CALL_COMPLETE ** 8,Idle:A **
______________________________________________________________________
MP+RX_VERSION_REQ -,* ** **
______________________________________________________________________
MP+ADD_REQ 5,Add:B ** **
______________________________________________________________________
MP+ADD_RSP 6,+ ** **
______________________________________________________________________
MP+ADD_COMP ** ** 9,Idle:
______________________________________________________________________
MP+RX_RM_REQ 10,+ 10,+ 10,+
______________________________________________________________________
MP+RX_RM_RSP 11,+ 11,+ 11,+
______________________________________________________________________
MP+RX_RM_RX_REQ 12,+ 12,+ 12,+
______________________________________________________________________
MP+RX_RM_TX_REQ 13,+ 13,+ 13,+
______________________________________________________________________
MP+RX_RM_TX_RSP 14,+ 14,+ 14,+
______________________________________________________________________
MP+RX_REMOVE_REQ -,* ** **
______________________________________________________________________
MP+START_RM 15,* 15,* 15,*
______________________________________________________________________
MP+SEND_RMS 16,* 16,* 16,*
______________________________________________________________________
MP+SEND_RMM 17,* 17,* 17,*
______________________________________________________________________
MP+RECV_RMM 18,* 18,* 18,*
______________________________________________________________________
MP+STOP_RM 19,* 19,* 19,*
______________________________________________________________________
All other events ** ** **
______________________________________________________________________
Table 4: Add State
Smith Informational [Page 38]
RFC 1934 Multilink Protocol Plus April 1996
Actions
1 Phone numbers (may) have been reserved, they must be
before the normal error processing occurs
Release all reserved phone
Do Error Close Action
2 Phone nubmers (may) have been reserved, they must be
before the normal close processing occurs
Release all reserved phone
Do Term Action
3 Do Timer
4 Note that a bandwidth change has been reqested. This will
processed the next time IDLE state is entered
5 An add collision has occured. Since the answerer has sent
numbers we will try to use what he as sent, within the limits
the local system
Compare local channels to add with current channels
add
If the local channels to add is less than the
channels to
If the remote number of channels requested
put us over the maximum number of
allowed for the session reduce the channel
and set an add lock
Re-reserve the channels. If the number
are less than the number of phone
provided by the far end, set an add lock
reduce the number of channels to add to what
could reserve
Now treat the remote add request as if it were an
response and process by
Integrate the phone number returned from
answerer with the original phone number dialed
Smith Informational [Page 39]
RFC 1934 Multilink Protocol Plus April 1996
Request that a session be extended by
the integrated phone number. A callback
passed with the request so call success
failure can be reported back to MP+.
Go to ADD:B. Note: This change must
occur before requesting the first outgoing call
If not, the callback could be called (
ignored) because the session is not in
correct state
6 If the answerer provided fewer phone numbers than requested
an add lock
If the number of channels is zero send an add complete
(there's nothing to do) and go to the IDLE state
For each phone number
Integrate the phone number returned from the
with the original phone number dialed
Request that a session be extended by dialing
integrated phone number. A callback is passed with
request so call success or failure can be reported
to MP+.
Go to ADD:B. Note: This change must actually occur
requesting the first outgoing call. If not, the callback
be called (and ignored) because the session is not in the
state
7 Restart idle timer for abort
8 Increment the count of calls completed
If the call succeeded, increment the count of calls
succeeded
If the count of calls completed equals the number of calls
If number of calls completed is not the same as
nubmer that succeeded set an add lock
Build an add complete message and send it to the far end
If at least one channel was added clear any remove lock
Smith Informational [Page 40]
RFC 1934 Multilink Protocol Plus April 1996
Go to the IDLE state
9 If number of channels requested not equal to number
set add lock
If at least one channel was added clear any remove lock
Go to the IDLE state
10 Do Remote Management Request
11 Do Remote Management Response
12 Do Remote Management Receive Data
13 Do Remote Management Transmit Data
14 Do Remote Management Transmit Data Response
15 Do Remote management (Master) start
16 Do Remote management (Slave) data
17 Do Remote management (Master) data
18 Do Remote management data acknowledgement
19 Do Remote management (Master) stop
3.5.6. MP+STATE_REMOVE state
The state of a session while processing a remove transaction
The sub-states are
A Remove request sent, waiting for rem