tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3331

 Errata 
Proposed STD
Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIGTRAN

Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer

Part 1 of 5, p. 1 to 16
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                       K. Morneault
Request for Comments: 3331                                 Cisco Systems
Category: Standards Track                                       R. Dantu
                                                                 NetRake
                                                           G. Sidebottom
                                                   Signatus Technologies
                                                             B. Bidulock
                                                                 OpenSS7
                                                                J. Heitz
                                                                  Lucent
                                                          September 2002


       Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
                         User Adaptation Layer

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a protocol for the backhauling of Signaling
   System 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages
   over IP using the Stream Control Transmission Protocol (SCTP).  This
   protocol would be used between a Signalling Gateway (SG) and Media
   Gateway Controller (MGC).  It is assumed that the SG receives SS7
   signalling over a standard SS7 interface using the SS7 Message
   Transfer Part (MTP) to provide transport.  The Signalling Gateway
   would act as a Signalling Link Terminal.

Top       Page 2 
Table of Contents

   1.  Introduction.............................................. 2
     1.1  Scope.................................................. 3
     1.2  Terminology............................................ 3
     1.3  M2UA Overview.......................................... 5
     1.4  Services Provided by the M2UA Adaptation Layer......... 7
     1.5  Functions Provided by the M2UA Layer................... 9
     1.6  Definition of the M2UA Boundaries..................... 12
   2.  Conventions.............................................. 16
   3.  Protocol Elements........................................ 16
     3.1  Common Message Header................................. 16
     3.2  M2UA Message Header................................... 22
     3.3  M2UA Messages......................................... 23
   4.  Procedures............................................... 58
     4.1  Procedures to Support the M2UA-User Layer............. 58
     4.2  Receipt of Primitives from the Layer Management....... 59
     4.3  AS and ASP State Maintenance.......................... 61
     4.4  Link Key Management Procedures........................ 73
   5.  Examples of MTP2 User Adaptation (M2UA) Procedures....... 75
     5.1  Establishment of associations between SGP and MGC
          examples.............................................. 75
     5.2  ASP Traffic Fail-over Examples........................ 77
     5.3  SGP to MGC, MTP Level 2 to MTP Level 3 Boundary
          Procedures............................................ 78
   6.  Timer Values............................................. 85
   7.  Security Considerations.................................. 85
     7.1 Threats................................................ 85
     7.2 Protecting Confidentiality............................. 86
   8.  IANA Considerations...................................... 86
     8.1 SCTP Payload Protocol Identifier....................... 86
     8.2 M2UA Protocol Extensions............................... 86
   9.  Acknowledgements......................................... 87
   10. References............................................... 88
   Appendix A: Signalling Network Architecture.................. 90
   11. Authors' Addresses....................................... 92
   Full Copyright Statement..................................... 94

1.  Introduction

   This document defines a protocol for the backhauling of SS7 [1] MTP2
   User [2] [3] [4] (i.e. MTP3) signalling messages over IP using the
   Stream Control Transmission Protocol (SCTP) [8].  This protocol would
   be used between a Signalling Gateway (SG) and Media Gateway
   Controller (MGC).

Top      ToC       Page 3 
1.1 Scope

   There is a need for Switched Circuit Network (SCN) signalling
   protocol delivery from a Signalling Gateway (SG) to a Media Gateway
   Controller (MGC) [9].  The delivery mechanism addresses the following
   objectives:

   *  Support for MTP Level 2 / MTP Level 3 interface boundary
   *  Support for communication between Layer Management modules on SG
      and MGC
   *  Support for management of SCTP active associations between the SG
      and MGC

   The SG will terminate up to MTP Level 2 and the MGC will terminate
   MTP Level 3 and above.  In other words, the SG will transport MTP
   Level 3 messages over an IP network to a MGC.

1.2 Terminology

   Application Server (AS) - A logical entity serving a specific
   application instance.  An example of an Application Server is a MGC
   handling the MTP Level 3 and call processing for SS7 links terminated
   by the Signalling Gateways.  Practically speaking, an AS is modeled
   at the SG as an ordered list of one or more related Application
   Server Processes (e.g., primary, secondary, tertiary, ...).

   Application Server Process (ASP) - A process instance of an
   Application Server.  Examples of Application Server Processes are
   active or standby MGC instances.

   Association - An association refers to a SCTP association.  The
   association will provide the transport for the delivery of protocol
   data units for one or more interfaces.

   Backhaul - Refers to the transport of signalling from the point of
   interface for the associated data stream (i.e., SG function in the
   MGU) back to the point of call processing (i.e., the MGCU), if this
   is not local [9].

   Fail-over - The capability to reroute signalling traffic as required
   to an alternate Application Server Process within an Application
   Server in the event of failure or unavailability of a currently used
   Application Server Process.  Fail-back MAY apply upon the return to
   service of a previously unavailable Application Server Process.

   Host - The computing platform that the ASP process is running on.

Top      ToC       Page 4 
   Interface - For the purposes of this document, an interface is a SS7
   signalling link.

   Interface Identifier - The Interface Identifier identifies the
   physical interface at the SG for which the signalling messages are
   sent/received.  The format of the Interface Identifier parameter can
   be text or integer, the values of which are assigned according to
   network operator policy.  The values used are of local significance
   only, coordinated between the SG and ASP.

   Layer Management - Layer Management is a nodal function in an SG or
   ASP that handles the inputs and outputs between the M2UA layer and a
   local management entity.

   Link Key - The link key is a locally unique (between ASP and SG)
   value that identifies a registration request for a particular
   Signalling Data Link and Signalling Terminal pair.

   MTP - The Message Transfer Part of the SS7 protocol

   MTP2 - MTP Level 2, the signalling data link layer of SS7

   MTP3 - MTP Level 3, the signalling network layer of SS7

   MTP2-User - A protocol that uses the services of MTP Level 2 (i.e.
   MTP3).

   Network Byte Order: Most significant byte first, a.k.a Big Endian.

   Signalling Data Link - An SDL refers to a specific communications
   facility that connects two Signalling Link Terminals.

   Signalling Gateway (SG) - An SG is a signalling agent at the edge of
   the IP network.  An SG appears to the SS7 as one or more Signalling
   Link Terminals that are connected to one or more Signalling Data
   Links in the SS7 network.  An SG contains a set of one or more unique
   Signalling Gateway Processes, on which one or more is normally
   actively processing traffic.  Where an SG contains more than one SGP,
   the SG is a logical entity.

   Signalling Gateway Process (SGP) - A process instance that uses M2UA
   to communicate to and from a Signalling Link Terminal.  It serves as
   an active, backup or load-sharing process of a Signalling Gateway.

   Signalling Link Terminal (SLT) - Refers to the means of performing
   all of the functions defined at MTP level 2 regardless of their
   implementation [2,3].

Top      ToC       Page 5 
   Stream - A stream refers to an SCTP stream; a unidirectional logical
   channel established from one SCTP endpoint to another associated SCTP
   endpoint, within which all user messages are delivered in-sequence
   except for those submitted to the unordered delivery service.

1.3  M2UA Overview

   The framework architecture that has been defined for SCN signalling
   transport over IP [9] uses two components: a signalling common
   transport protocol and an adaptation module to support the services
   expected by a particular SCN signalling protocol from its underlying
   protocol layer.

   Within this framework architecture, this document defines a SCN
   adaptation module that is suitable for the transport of SS7 MTP2 User
   messages.  The only SS7 MTP2 User is MTP3.  The M2UA uses the
   services of the Stream Control Transmission Protocol [8] as the
   underlying reliable signalling common transport protocol.

   In a Signalling Gateway, it is expected that the SS7 MTP2-User
   signalling is transmitted and received from the PSTN over a standard
   SS7 network interface, using the SS7 Message Transfer Part Level 1
   and Level 2 [2,3,4] to provide reliable transport of the MTP3-User
   signalling messages to and from an SS7 Signalling End Point (SEP) or
   Signalling Transfer Point (STP).  The SG then provides an
   interworking of transport functions with the IP transport, in order
   to transfer the MTP2-User signalling messages to and from an
   Application Server Process where the peer MTP2-User protocol layer
   exists.

Top      ToC       Page 6 
1.3.1  Example - SG to MGC

   In a Signalling Gateway, it is expected that the SS7 signalling is
   received over a standard SS7 network termination, using the SS7
   Message Transfer Part (MTP) to provide transport of SS7 signalling
   messages to and from an SS7 Signalling End Point (SEP) or SS7
   Signalling Transfer Point (STP).  In other words, the SG acts as a
   Signalling Link Terminal (SLT) [2,3].  The SG then provides an
   interworking of transport functions with IP Signalling Transport, in
   order to transport the MTP3 signalling messages to the MGC where the
   peer MTP3 protocol layer exists, as shown below:

       ******    SS7    ******      IP     *******
       *SEP *-----------* SG *-------------* MGC *
       ******           ******             *******

       +----+                              +----+
       |S7UP|                              |S7UP|
       +----+                              +----+
       |MTP +                              |MTP |
       | L3 |            (NIF)             |L3  |
       +----+         +----+----+          +----+
       |MTP |         |MTP |M2UA|          |M2UA|
       |    |         |    +----+          +----+
       |L2  |         |L2  |SCTP|          |SCTP|
       |L1  |         |L1  +----+          +----+
       |    |         |    |IP  |          |IP  |
       +----+         +---------+          +----+

       NIF  - Nodal Interworking Function
       SEP  - SS7 Signalling Endpoint
       IP   - Internet Protocol
       SCTP - Stream Control Transmission Protocol (Reference [8])

           Figure 1  M2UA in the SG to MGC Application

   Note: STPs MAY be present in the SS7 path between the SEP and the SG.

   It is recommended that the M2UA use the services of the Stream
   Control Transmission Protocol (SCTP) [8] as the underlying reliable
   common signalling transport protocol.  The use of SCTP provides the
   following features:

   -  explicit packet-oriented delivery (not stream-oriented)
   -  sequenced delivery of user messages within multiple streams, with
      an option for order-of-arrival delivery of individual user
      messages,
   -  optional multiplexing of user messages into SCTP datagrams,

Top      ToC       Page 7 
   -  network-level fault tolerance through the support of multi-homing
      at either or both ends of an association,
   -  resistance to flooding and masquerade attacks, and
   -  data segmentation to conform to discovered path MTU size

   There are scenarios without redundancy requirements and scenarios in
   which redundancy is supported below the transport layer.  In these
   cases, the SCTP functions above MAY NOT be a requirement and TCP can
   be used as the underlying common transport protocol.

1.3.2  ASP Fail-over Model and Terminology

   The M2UA layer supports ASP fail-over functions in order to support a
   high availability of call and transaction processing capability.  All
   MTP2-User messages incoming to a SGP from the SS7 network are
   assigned to the unique Application Server, based on the Interface
   Identifier of the message.

   The M2UA layer supports a n+k redundancy model (active-standby, load
   sharing, broadcast) where n is the minimum number of redundant ASPs
   required to handle traffic and k ASPs are available to take over for
   a failed or unavailable ASP.  Note that 1+1 active/standby redundancy
   is a subset of this model.  A simplex 1+0 model is also supported as
   a subset, with no ASP redundancy.

1.3.3  Client/Server Model

   It is recommended that the SGP and ASP be able to support both client
   and server operation.  The peer endpoints using M2UA SHOULD be
   configured so that one always takes on the role of client and the
   other the role of server for initiating SCTP associations.  The
   default orientation would be for the SGP to take on the role of
   server while the ASP is the client.  In this case, ASPs SHOULD
   initiate the SCTP association to the SGP.

   The SCTP and TCP Registered User Port Number Assignment for M2UA is
   2904.

1.4  Services Provided by the M2UA Adaptation Layer

   The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
   point in the IP network, so that the M2UA protocol layer is required
   to provide the equivalent set of services to its users as provided by
   the MTP Level 2 to MTP Level 3.

Top      ToC       Page 8 
1.4.1  Support for MTP Level 2 / MTP Level 3 interface boundary

   M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that
   enables a seamless, or as seamless as possible, operation of the
   MTP2-User peers in the SS7 and IP domains.  An example of the
   primitives that need to be supported can be found in [10].

1.4.2  Support for communication between Layer Management modules on SG
       and MGC

   The M2UA layer needs to provide some messages that will facilitate
   communication between Layer Management modules on the SG and MGC.  To
   facilitate reporting of errors that arise because of the backhauling
   MTP Level 3 scenario, the following primitive is defined:

   M-ERROR

   The M-ERROR message is used to indicate an error with a received M2UA
   message (e.g., an interface identifier value is not known to the SG).

1.4.3  Support for management of active associations between SG and MGC

   The M2UA layer on the SG keeps the state of the configured ASPs.  A
   set of primitives between M2UA layer and the Layer Management are
   defined below to help the Layer Management manage the association(s)
   between the SG and the MGC.  The M2UA layer can be instructed by the
   Layer Management to establish a SCTP association to a peer M2UA node.
   This procedure can be achieved using the M-SCTP ESTABLISH primitive.

   M-SCTP_ESTABLISH

   The M-SCTP_ESTABLISH primitive is used to request, indicate and
   confirm the establishment of a SCTP association to a peer M2UA node.

   M-SCTP_RELEASE

   The M-SCTP_RELEASE primitives are used to request, indicate, and
   confirm the release of a SCTP association to a peer M2UA node.

   The M2UA layer MAY also need to inform the status of the SCTP
   association(s) to the Layer Management.  This can be achieved using
   the following primitive.

   M-SCTP_STATUS

   The M-SCTP_STATUS primitive is used to request and indicate the
   status of underlying SCTP association(s).

Top      ToC       Page 9 
   The Layer Management MAY need to inform the M2UA layer of an AS/ASP
   status (i.e., failure, active, etc.), so that messages can be
   exchanged between M2UA layer peers to stop traffic to the local M2UA
   user.  This can be achieved using the following primitive.

   M-ASP_STATUS

   The ASP status is stored inside the M2UA layer on both the SG and MGC
   sides.  The M-ASP_STATUS primitive can be used by Layer Management to
   request the status of the Application Server Process from the M2UA
   layer.  This primitive can also be used to indicate the status of the
   Application Server Process.

   M-ASP_MODIFY

   The M-ASP_MODIFY primitive can be used by Layer Management to modify
   the status of the Application Server Process.  In other words, the
   Layer Management on the ASP side uses this primitive to initiate the
   ASPM procedures.

   M-AS_STATUS

   The M-AS_STATUS primitive can be used by Layer Management to request
   the status of the Application Server.  This primitive can also be
   used to indicate the status of the Application Server.

1.5  Functions Provided by the M2UA Layer

1.5.1  Mapping

   The M2UA layer MUST maintain a map of an Interface ID to a physical
   interface on the Signalling Gateway.  A physical interface would be a
   V.35 line, T1 line/time slot, E1 line/time slot, etc.  The M2UA layer
   MUST also maintain a map of the Interface Identifier to SCTP
   association and to the related stream within the association.

   The SGP maps an Interface Identifier to an SCTP association/stream
   only when an ASP sends an ASP Active message for a particular
   Interface Identifier.  It must be noted, however, that this mapping
   is dynamic and could change at any time due to a change of ASP state.
   This mapping could even temporarily be invalid, for example during
   fail-over of one ASP to another.  Therefore, the SGP MUST maintain
   the states of AS/ASP and reference them during the routing of any
   messages to an AS/ASP.

   Note that only one SGP SHOULD provide Signalling Link Terminal
   services to an SS7 link.  Therefore, within an SG, an Application
   Server SHOULD be active for only one SGP at any given point in time.

Top      ToC       Page 10 
   An example of the logical view of the relationship between an SS7
   link, Interface Identifier, AS and ASP in an SGP is shown below:

               /-------------------------------------------------+
              /   /----------------------------------------------|--+
             /   /                                               v  |
            /   /    +----+             act+-----+   +-------+ -+--+|-+-
   SS7 link1-------->|IID |-+          +-->| ASP |-->| Assoc |      v
              /      +----+ |  +----+  |   +-----+   +-------+ -+--+--+-
             /              +->| AS |--+                        Streams
            /        +----+ |  +----+   stb+-----+
   SS7 link2-------->|IID |-+              | ASP |
                     +----+                +-----+

   where IID = Interface Identifier

   A SGP MAY support more than one AS.  An AS MAY support more than one
   Interface Identifier.

1.5.2  Support for the management of SCTP associations between the SGPs
       and ASPs

   The M2UA layer at the SG maintains the availability state of all
   configured ASPs, in order to manage the SCTP associations and the
   traffic between the SG and ASPs.  As well, the active/inactive state
   of remote ASP(s) are also maintained.  The Active ASP(s) are the
   one(s) currently receiving traffic from the SG.

   The M2UA layer MAY be instructed by local management to establish an
   SCTP association to a peer M2UA node.  This can be achieved using the
   M-SCTP_ESTABLISH primitive to request, indicate and confirm the
   establishment of an SCTP association with a peer M2UA node.

   The M2UA layer MAY also need to inform local management of the status
   of the underlying SCTP associations using the M-SCTP_STATUS request
   and the indication primitive.  For example, the M2UA MAY inform local
   management of the reason for the release of an SCTP association,
   determined either locally within the M2UA layer or by a primitive
   from the SCTP.

   Also the M2UA layer may need to inform the local management of the
   change in status of an ASP or AS.  This may be achieved using the M-
   ASP STATUS request or M-AS_STATUS request primitives.

Top      ToC       Page 11 
1.5.3 Status of ASPs

   The M2UA layer on the SG MUST maintain the state of the ASPs it is
   supporting.  The state of an ASP changes because of the reception of
   peer-to-peer messages (ASPM messages as described in Section 3.3.2)
   or the reception of indications from the local SCTP association.  The
   ASP state transition procedures are described in Section 4.3.1.

   At a SGP, an Application Server list MAY contain active and inactive
   ASPs to support ASP fail-over procedures.  When, for example, both a
   primary and a backup ASP are available, the M2UA peer protocol is
   required to control which ASP is currently active.  The ordered list
   of ASPs within a logical Application Server is kept updated in the
   SGP to reflect the active Application Server Process.

   Also the M2UA layer MAY need to inform the local management of the
   change in status of an ASP or AS.  This can be achieved using the M-
   ASP_STATUS or M-AS_STATUS primitives.

1.5.4  SCTP Specifics

1.5.4.1  SCTP Stream Management

   SCTP allows a user specified number of streams to be opened during
   initialization of the association.  It is the responsibility of the
   M2UA layer to ensure proper management of these streams.  Because of
   the unidirectional nature of streams, a M2UA layer is not aware of
   the stream information from its peer M2UA layer.  For this reason,
   the Interface Identifier is in the M2UA message header.

   The use of SCTP streams within M2UA is recommended in order to
   minimize transmission and buffering delay, thereby, improving the
   overall performance and reliability of the signalling elements.  A
   separate SCTP stream can be used for each SS7 link.  Or, an
   implementation may choose to split the SS7 link across several
   streams based on SLS.  This method may be of particular interest for
   high speed SS7 links (MTP3b) since high speed links have a 24-bit
   sequence number and the stream sequence number is 16-bits.

   SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
   messages (see Section 3) since stream '0' SHOULD only be used for ASP
   Management (ASPM) messages (see Section 4.3.3).

Top      ToC       Page 12 
1.5.5  Seamless SS7 Network Management Interworking

   The M2UA layer on the SGP SHOULD pass an indication of unavailability
   of the M2UA-User (MTP3) to the local Layer Management, if the
   currently active ASP moves from the ACTIVE state.  The actions taken
   by M2UA on the SGP with regards to MTP Level 2 should be in
   accordance with the appropriate MTP specifications.

1.5.6  Flow Control / Congestion

   It is possible for the M2UA layer to be informed of the IP network
   congestion onset and abatement by means of an implementation
   dependent function (i.e. an indication from the SCTP).  The handling
   of this congestion indication by M2UA is implementation dependent.
   However, the actions taken by the SG should be in accordance with the
   appropriate MTP specification and should enable SS7 functionality
   (e.g. flow control) to be correctly maintained.

1.5.7  Audit of SS7 Link State

   After a fail-over of one ASP to another ASP, it may be necessary for
   the M2UA on the ASP to audit the current SS7 link state to ensure
   consistency.  The M2UA on the SGP would respond to the audit request
   with information regarding the current state of the SS7 link (i.e.
   in-service, out-of-service, congestion state, LPO/RPO state).

1.6  Definition of the M2UA Boundaries

1.6.1  Definition of the M2UA / MTP Level 3 boundary

   DATA
   ESTABLISH
   RELEASE
   STATE
   DATA RETRIEVAL
   DATA RETRIEVAL COMPLETE

1.6.2  Definition of the M2UA / MTP Level 2 boundary

   DATA
   ESTABLISH
   RELEASE
   STATE
   DATA RETRIEVAL
   DATA RETRIEVAL COMPLETE

Top      ToC       Page 13 
1.6.3  Definition of the Lower Layer Boundary between M2UA and SCTP

   The upper layer and layer management primitives provided by SCTP are
   provided in Reference [8] Section 10.

1.6.4  Definition of Layer Management / M2UA Boundary

   M-SCTP_ESTABLISH request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to establish an SCTP association with an
            SGP.

   M-SCTP_ESTABLISH confirm
   Direction: M2UA -> LM
   Purpose: ASP confirms to LM that it has established an
            SCTP association with an SGP.

   M-SCTP_ESTABLISH indication
   Direction: M2UA -> LM
   Purpose: SGP informs LM that an ASP has established an SCTP
            association.

   M-SCTP_RELEASE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to release an SCTP association with SGP.

   M-SCTP_RELEASE confirm
   Direction: M2UA -> LM
   Purpose: ASP confirms to LM that it has released SCTP association
            with SGP.

   M-SCTP_RELEASE indication
   Direction: M2UA -> LM
   Purpose: SGP informs LM that ASP has released an SCTP association.

   M-SCTP_RESTART indication
   Direction: M2UA -> LM
   Purpose: M2UA informs LM that a SCTP Restart indication has
            been received.

   M-SCTP_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests M2UA to report status of SCTP association.

   M-SCTP_STATUS indication
   Direction: M2UA -> LM
   Purpose: M2UA reports status of SCTP association.

Top      ToC       Page 14 
   M-ASP_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests SGP to report status of remote ASP.

   M-ASP_STATUS indication
   Direction: M2UA -> LM
   Purpose: SGP reports status of remote ASP.

   M-AS_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests SG to report status of AS.

   M-AS_STATUS indication
   Direction: M2UA -> LM
   Purpose: SG reports status of AS.

   M-NOTIFY indication
   Direction: M2UA -> LM
   Purpose: ASP reports that it has received a NOTIFY message
            from its peer.

   M-ERROR indication
   Direction: M2UA -> LM
   Purpose: ASP or SGP reports that it has received an ERROR
            message from its peer.

   M-ASP_UP request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to start its operation and send an ASP UP
            message to the SGP.

   M-ASP_UP confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that it has received an ASP UP Acknowledgment
            message from the SGP.

   M-ASP_DOWN request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to stop its operation and send an ASP DOWN
            message to the SGP.

   M-ASP_DOWN confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP DOWN Acknowledgment
            message from the SGP.

Top      ToC       Page 15 
   M-ASP_ACTIVE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP.

   M-ASP_ACTIVE confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP ACTIVE
            Acknowledgment message from the SGP.

   M-ASP_INACTIVE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.

   M-ASP_INACTIVE confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP INACTIVE
            Acknowledgment message from the SGP.

   M-LINK_KEY_REG Request
   Direction:  LM -> M2UA
   Purpose: LM requests ASP to register Link Key with SG by sending REG
            REQ message.

   M-LINK_KEY_REG Confirm
   Direction:   M2UA -> LM
   Purpose: ASP reports to LM that it has successfully received a REG
            RSP message from SG.

   M-LINK_KEY_REG Indication
   Direction:  M2UA -> LM
   Purpose:  SG reports to LM that it has successfully processed an
             incoming REG REQ message from ASP.

   M-LINK_KEY_DEREG Request
   Direction:  LM -> M2UA
   Purpose:  LM requests ASP to de-register Link Key with SG by sending
             DEREG REQ message.

   M-LINK_KEY_DEREG Confirm
   Direction:  M2UA -> LM
   Purpose:  ASP reports to LM that it has successfully received a
             DEREG RSP message from SG.

   M-LINK_KEY_DEREG  Indication
   Direction:  M2UA -> LM
   Purpose:  SG reports to LM that it has successfully processed an
             incoming DEREG REQ message from ASP.

Top      ToC       Page 16 
2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].



(page 16 continued on part 2)

Next RFC Part