rfc3057.txt

最新的RFC

   variable-length parameters contained in a message are defined in a
   Tag-Length-Value format as shown below.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Parameter Tag        |       Parameter Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                       Parameter Value                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Mandatory parameters MUST be placed before optional parameters in a
   message.

   Parameter Tag: 16 bits (unsigned integer)

   The Tag field is a 16 bit identifier of the type of parameter.  It
   takes a value of 0 to 65534.

   The value of 65535 is reserved for IETF-defined extensions.  Values
   other than those defined in specific parameter description are
   reserved for use by the IETF.



Morneault, et al.           Standards Track                    [Page 19]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   Parameter Length: 16 bits (unsigned integer)

   The Parameter Length field contains the size of the parameter in
   bytes, including the Parameter Tag, Parameter Length, and Parameter
   Value fields.  The Parameter Length does not include any padding
   bytes.

   Parameter Value: variable-length

   The Parameter Value field contains the actual information to be
   transferred in the parameter.

   The total length of a parameter (including Tag, Parameter Length and
   Value fields) MUST be a multiple of 4 bytes.  If the length of the
   parameter is not a multiple of 4 bytes, the sender pads the Parameter
   at the end (i.e., after the Parameter Value field) with all zero
   bytes. The length of the padding is NOT included in the parameter
   length field.  A sender SHOULD NEVER pad with more than 3 bytes.  The
   receiver MUST ignore the padding bytes.

3.2 IUA Message Header

   In addition to the common message header, there will be a specific
   message header for QPTM and the TEI Status MGMT messages.  The IUA
   message header will immediately follow the Common header in these
   messages.

   This message header will contain the Interface Identifier and Data
   Link Connection Identifier (DLCI).  The Interface Identifier
   identifies the physical interface terminating the signaling channel
   at the SG for which the signaling messages are sent/received.  The
   format of the Interface Identifier parameter can be text or integer.
   The Interface Identifiers are assigned according to network operator
   policy.  The integer values used are of local significance only,
   coordinated between the SG and ASP.

   The integer formatted Interface Identifier MUST be supported.  The
   text formatted Interface Identifier MAY optionally be supported.













Morneault, et al.           Standards Track                    [Page 20]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x1)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier (integer)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |              Spare            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4 IUA Message Header (Integer-based Interface Identifier)

   The Tag value for the Integer-based Interface Identifier is 0x1.  The
   length is always set to a value of 8.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x3)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                   Interface Identifier (text)                 |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |             Spare             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5  IUA Message Header (Text-based Interface Identifier)

   The Tag value for the Text-based Interface Identifier is 0x3.  The
   length is variable.

   The DLCI format is shown below in Figure 6.

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  0  | SPR |      SAPI                         |
   +-----------------------------------------------+
   |  1  |            TEI                          |
   +-----------------------------------------------+

              Figure 6  DLCI Format

   SPR:  Spare 2nd bit in octet 1, (1 bit)



Morneault, et al.           Standards Track                    [Page 21]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
      1 (6 bits)

   TEI:  Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
      (7 bits)

   The DLCI field (including the SAPI and TEI) is coded in accordance
   with Q.921.

3.3 IUA  Messages

   The following section defines the messages and parameter contents.
   The IUA messages will use the common message header (Figure 3) and
   the IUA message header (Figure 4 and Figure 5).

3.3.1 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages

3.3.1.1  Establish Messages (Request, Confirm, Indication)

   The Establish Messages are used to establish a data link on the
   signaling channel or to confirm that a data link on the signaling
   channel has been established.  The MGC controls the state of the D
   channel.  When the MGC desires the D channel to be in-service, it
   will send the Establish Request message.

   When the MGC sends an IUA Establish Request message, the MGC MAY
   start a timer.  This timer would be stopped upon receipt of an IUA
   Establish Confirm or Establish Indication.  If the timer expires, the
   MGC would re-send the IUA Establish Request message and restart the
   timer.  In other words, the MGC MAY continue to request the
   establishment of the data link on periodic basis until the desired
   state is achieved or take some other action (notify the Management
   Layer).

   When the SG receives an IUA Establish Request from the MGC, the SG
   shall send the Q.921 Establish Request primitive to the its Q.921
   entity.  In addition, the SG shall map any response received from the
   Q.921 entity to the appropriate message to the MGC.  For example, if
   the Q.921 entity responds with a Q.921 Establish Confirm primitive,
   the IUA layer shall map this to an IUA Establish Confirm message.  As
   another example, if the IUA Layer receives a Q.921 Release Confirm or
   Release Indication as an apparent response to the Q.921 Establish
   Request primitive, the IUA Layer shall map these to the corresponding
   IUA Release Confirm or Release Indication messages.

   The Establish messages contain the common message header followed by
   IUA message header.  It does not contain any additional parameters.




Morneault, et al.           Standards Track                    [Page 22]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


3.3.1.2  Release Messages (Request, Indication, Confirmation)

   The Release Request message is used to release the data link on the
   signaling channel.  The Release Confirm and Indication messages are
   used to indicate that the data link on the signaling channel has been
   released.

   If a response to the Release Request message is not received, the MGC
   MAY resend the Release Request message.  If no response is received,
   the MGC can consider the data link as being released.  In this case,
   signaling traffic on that D channel is not expected from the SG and
   signaling traffic will not be sent to the SG for that D channel.

   The Release messages contain the common message header followed by
   IUA message header.  The Release confirm message is in response to a
   Release Request message and it does not contain any additional
   parameters.  The Release Request and Indication messages contain the
   following parameter:

     REASON

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xf)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Reason                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The valid values for Reason are shown in the following table.

      Define     Value           Description
   RELEASE_MGMT   0x0     Management layer generated release.
   RELEASE_PHYS   0x1     Physical layer alarm generated release.
   RELEASE_DM     0x2     Specific to a request.  Indicates Layer 2
                          SHOULD release and deny all requests from
                          far end to establish a data link on the
                          signaling channel (i.e., if SABME is
                          received send a DM)
   RELEASE_OTHER  0x3     Other reasons

   Note:  Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid
   reason codes for a Release Request message.

3.3.1.3 Data Messages (Request, Indication)

   The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU)
   corresponding to acknowledged information transfer service.



Morneault, et al.           Standards Track                    [Page 23]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   The Data messages contain the common message header followed by IUA
   message header.  The Data message contains the following parameters:

     PROTOCOL DATA

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xe)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          Protocol Data                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The protocol data contains upper layer signaling message e.g.  Q.931,
   QSIG.

3.3.1.4 Unit Data Messages (Request, Indication)

   The Unit Data message contains an ISDN Q.921-User Protocol Data Unit
   (PDU) corresponding to unacknowledged information transfer service.

   The Unit Data messages contain the common message header followed by
   IUA message header.  The Unit Data message contains the following
   parameters

     PROTOCOL DATA

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xe)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          Protocol Data                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.2  Application Server Process Maintenance (ASPM) Messages

   The ASPM messages will only use the common message header.

3.3.2.1  ASP Up (ASPUP)

   The ASP Up (ASPUP) message is sent by an ASP to indicate to an SG
   that it is ready to receive traffic or maintenance messages.




Morneault, et al.           Standards Track                    [Page 24]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   The ASPUP message contains the following parameters:

     Info String (optional)

   The format for ASPUP Message parameters is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x4)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The optional INFO String parameter can carry any meaningful 8-bit
   ASCII character string along with the message.  Length of the INFO
   String parameter is from 0 to 255 characters.  No procedures are
   presently identified for its use but the INFO String MAY be used for
   debugging purposes.

3.3.2.2 ASP Up Ack

   The ASP Up Ack message is used to acknowledge an ASP Up message
   received from a remote IUA peer.

   The ASPUP Ack message contains the following parameters:

      INFO String (optional)

   The format for ASPUP Ack Message parameters is as follows:

    0                   1                   2                   3