rfc1934.txt

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

______________________________________________________________________
Transmit Request from call      -,*        3,Pending    8,*
management layer
______________________________________________________________________
Stop                            9,Start    9,Start      9,Start
______________________________________________________________________

                  Table 1: Error Control State Machine

Legend:

        -       No action

        *       Stay in same state

        **      Invalid or meaningless event for state, ignored.

Notes:

   [1] Data from the call management layer will always be copied before
       being queued for transmission.  The call management layer is
       responsible for its own buffers.

   [2] MP always copies data for transmission and returns immediately.
       Any buffers allocated to build control messages MUST be released
       immediately upon return from MP transmission requests.

Actions:

   1       Reset rx sequence number
           Reset tx sequence number
           Reset tx retransmit count
           Stop retransmit timer

   2       Report error to user
           Stop retransmit timer
           Stop frame transmit timer
           Free buffers

   3       Save call management message in pending transmit queue
           Build DATA_MSG from first message in pending transmit
           queue using current tx sequence number.
           Send message to MP for transmission.
           Reset tx retransmit count







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


   4       Increment tx retransmit count
           If tx retransmit count >= RETRANSMIT_COUNT
                   Action 2 (followed by state change to the Start state)
           else
                   Build DATA_MSG from first message in pending
                   transmit queue using current tx sequence number.
                   Send message to MP for transmission.

   5       Dequeue first element on pending transmit queue and release
           its buffer
           Increment the tx sequence number
           Stop the retransmit timer
           if pending transmit queue not empty
                   Build DATA_MSG from first message in pending
                   transmit queue using current tx sequence number.
                   Send message to MP for transmission.
                   Reset tx retransmit count

   6       Build ACK_MSG using the current rx sequence number
           Send ack message to MP for transmission
           Pass message to call managment layer
           Increment rx sequence number

   7       Build ACK_MSG using the previous rx sequence number
           Send the ack message to MP for transmission

   8       Add the message to the end of the pending transmit queue

   9       Stop retransmit timer
           Free buffers

3.2. Multilink Plus Control Messages

    Message Type                Value
    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 Formats

   The fields of all messages defined here MUST be encoded/decoded in
   Network Byte Order (big endian).

3.3.1. VERSION_EXCHANGE_REQ Message Format

   The version exchange message is sent by the call originator to inform
   the answerer the version of the MP+ protocol being used as well as
   any other information that may need to be conveyed outside of the
   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 Request

   A message sent from call originator to call answerer specifying the
   callers protocol version and other state info and requesting the
   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 trunk
           groups.
           2 octets fixed length

   Descriptor Length:
           length of the end point descriptor.
           2 octets fixed length

   Descriptor:
           the end point descriptor. This field allows for vendor
           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 Format

   The version exchange response message is sent by the call answerer in
   response to a version exchange request message.   The answerer uses
   the message to inform the caller the version of the MP+ protocol
   being used as well as any other information that needs to be conveyed
   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 Response

   A message sent from call answerer to the call originator specifying
   the answerers protocol version and other state info.  Sent in
   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 length

   Descriptor Length:
           length of the remote descriptor in 4-octet units.
           2 octets fixed length

   Descriptor:
           the remote unit descriptor. This field allows for vendor
           specific identification of the peer.
           Variable length Nx4 octets long - total length defined above.

3.3.3. ADD_REQ Message Format

   A message of this type is sent by either caller or answerer to
   initiate an increase of bandwidth.  When sent by the caller the
   request is asking for permission to dial a certain number of
   channels; the response will contain permission and the phone numbers
   of the channels to dial.  When sent by the answerer, this message
   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 Request





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


   A message sent by either caller or answerer to request that additional
   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.  This
           value will always be zero when the caller
           initiates an add and will be at least
           Number of channels requested when the answerer
           initiates the add.
           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 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 list






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


   A structure containing information about a connection within the
   system.

   in use flag:
           non-zero if the phone number indicated
           in this descriptor is currently in use.