rfc1934.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

           2 octets fixed length

   call service type:
           Defines the type of service, switched, nailed,
           or other, associated with a phone number.
           1       Nailed
           2       Switched
           >=3     Undefined

   Phone number:
           The null terminated phone number of this channel.
           Fixed length 21 octets. Each octet contains IA5 character
           representation of a digit (or #, *).

   Must be 0:
           Filler to force alignment to 32-bit boundary.

3.3.4 ADD_RSP Message Format

   A message of this type gives permission to dial some number of
   channels and, when sent by the answerer of the original call, gives
   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 Response






Smith                        Informational                     [Page 15]

RFC 1934                Multilink Protocol Plus               April 1996


   A message sent by either caller or answerer to indicate the number of
   channels that may be added to a session.

   Number of channels allowed:
           The actual number of channels to add.  This
           may be less than the number requested.
           2 octets fixed length.

   Number of phone numbers:
           The number of phone numbers provided.  This
           value will always be zero when sent by the
           caller and will be at least channelCount
           when sent by the answerer.
           2 octets fixed length.

   Phone number list:
           A list of up to 32 phone number lists
           containing the phone numbers to call.
           Each description is of fixed length as described above.

3.3.5. ADD_COMPLETE Message Format

   This message is sent by the caller to the answerer after all calls
   have been placed.  The message is used to notify the answerer that
   the add transaction is complete and it may return to the idle state.

   +---------------+---------------+
   |         Message type          |
   |          0x00000005           |
   +---------------+---------------+
   |       Channels added          |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 9: Add Complete

   A message sent by caller to indicate the number of channels that were
   added successfully. This message was added in MP+ Version 1.1.

   Channels added:
           The actual number of channels added.
           2 octets fixed length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length




Smith                        Informational                     [Page 16]

RFC 1934                Multilink Protocol Plus               April 1996


3.3.6. REMOVE_REQ Message Format

   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 tell
   the remote end of the remove and give it a chance to adjust the
   number of channels to remove.

   +---------------+---------------+
   |         Message type          |
   |          0x00000006           |
   +---------------+---------------+
   | Number of channels to remove  |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 10: Remove Request

   A message sent by either caller or answerer to request that bandwidth
   be removed from a session.

   Number of channels to remove:
           The maximum number of channels to remove.
           2 octets fixed length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length

3.3.7. REMOVE_RSP Message Format

   This message is sent in response to a remove request.  The responder
   specifies the number of channels that can be removed.  If the
   response specifies 0 channels the remove is cancelled.

   +---------------+---------------+
   |         Message type          |
   |          0x00000007           |
   +---------------+---------------+
   | Number of channels to remove  |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 11: Remove Response






Smith                        Informational                     [Page 17]

RFC 1934                Multilink Protocol Plus               April 1996


   A message sent in response to a remove request specifying the number
   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 is
           cancelled.
           2 octets fixed length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length

3.3.8. REMOVE_COMPLETE Message Format

   This message is sent by the initiator of a remove transaction when
   the agreed upon number of channels have been removed.  The message is
   used to notify the peer that the remove transaction is complete and
   it may return to the idle state.

   +---------------+---------------+
   |         Message type          |
   |          0x00000008           |
   +---------------+---------------+
   | Number of channels removed    |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 12: Remove Complete

   A message sent by the caller or answerer to indicate how many channels
   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 length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length










Smith                        Informational                     [Page 18]

RFC 1934                Multilink Protocol Plus               April 1996


3.3.9. CLOSE_REQ Message Format

   This message is sent when the peer requests to close the whole
   session.  This is typically due to a configuration option that
   indicates when a system should request to close the session (an
   example being, a link has been idle for greater than a preconfigured
   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 Format

   If the peer agrees that closing the session is acceptable based on
   it's own configuration (an example reject reason would be that the
   peer is configured with a *minimum* number of channels to keep
   active).

   +---------------+---------------+
   |         Message type          |
   |          0x0000000a           |
   +---------------+---------------+
   |          OK To Close          |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 14: MP+ close response

   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 length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length







Smith                        Informational                     [Page 19]

RFC 1934                Multilink Protocol Plus               April 1996


3.3.11. REMOTE_MGMT_REQ Message Format

   This message is sent from a master station to a slave station when
   the master wishes to manage the remote station.  The message is also
   used to cancel remote management once it's been started.

   +---------------+---------------+
   |         Message type          |
   |          0x0000000b           |
   +---------------+---------------+
   |              Mode             |
   +---------------+---------------+
   |          Must be zero         |
   +---------------+---------------+

   Figure 15: Remote Management Request

   A message sent from master to slave to initiate or clear a remote
   management session.

   Mode:
           One to start session. Zero to stop session.
           2 octets fixed length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length

3.3.12. REMOTE_MGMT_RSP Message Format

   The slave side of a remote management session has the opportunity to
   reject remote management.  The master side is informed of accept/deny
   status via the remote management response.

   +---------------+---------------+
   |         Message type          |
   |          0x0000000c           |
   +---------------+---------------+
   |              Mode             |
   +---------------+---------------+

   Figure 16: Remote Management Response

   A message sent from slave to master to allow or deny initiation of a
   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 length

   Must be zero:
           Padding to 32-bit boundary.
           2 octets fixed length

3.3.13. REMOTE_MGMT_RX_REQ Message Format

   This message type is used to convey keyboard input from the
   management master to be processed by the management slave.  The
   message format consists of an octet count (in network byte order) and
   then an array of octets to be processed.  It looks like:

   +---------------+---------------+
   |         Message type          |
   |          0x0000000d           |
   +---------------+---------------+
   |         character count       |
   +---------------+---------------+
   |      array of characters      |
   |               .               |
   |               .               |
   |               .               |
   +---------------+---------------+

   Figure 17: Remote Management Receive Request

   A message sent from master to slave, conveying keystrokes typed on the
   masters keyboard that will be processed by the slave.

   character count:
           Number of characters to process.
           2 octets fixed length

   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 Format

   The remote management slave conveys output to be displayed on the
   masters terminal with a remote management transmit request message.
   Only one message may be outstanding.  The next transmit request may
   not be sent until the previous has been acknowledged.

   +---------------+---------------+
   |         Message type          |
   |          0x0000000e           |
   +---------------+---------------+
   |         character count       |