Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3331

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

Pages: 94
Proposed Standard
Errata
Part 1 of 5 – Pages 1 to 16
None   None   Next

Top   ToC   RFC3331 - 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   ToC   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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   RFC3331 - 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 Section