SS7 MTP-L3 and M3UA IETF IETF RFC 4666
Statement of Compliance



Contents

1General



1.1Introduction



1.2Concept



1.3Concepts




2
Compliance Lists



2.1RFC 4666



2.2Notes and Comments




Glossary




Reference List













1   General


1.1   Introduction



This document details how the Ericsson SS7 MTPL3& M3UA IETF (M3-IETF)
signaling component conforms with the IETF RFC 4666 Reference [1] .
Conformance is considered on a per-section basis. The M3-IETF signaling component
is compliant with a section provided it conforms with everything in the section,
irrespective of requirement level (that is irrespective of the keywords "MAY",
"MUST", "SHOULD" so on.)



Note that the Ericsson SS7 M3-IETF signaling component comprises the functionality
of both the MTP-L3 and the M3UA protocols, however, this document considers
only the M3UA protocol.



1.2   Concept



This section will explain the different concepts that will be used in the
compliance lists. The terms that are used are:



C The Ericsson signaling component complies with the specified
section in the standard. 
N The Ericsson signaling component does not comply with
the specified section in the standard. 
P The Ericsson signaling component complies partly with
the specified section in the standard.
- There is nothing to implement in the referred section
(always placed in column C). 


1.3   Concepts



 Figure 1 illustrates how routing is performed according
to the IETF M3UA standard. A RK describes a set of SS7 parameter values (for
example a RK could consist of the tuple DPC/SI/SSN) that uniquely defines
the range of signaling traffic to be handled by a particular Application Server
(AS).



Sometimes as it is shown in  Figure 1 two or more SS7 networks
are connected to the same Signaling Gateway (SG), a Network Appearance (NA)
is appended to the RK to make the RK unique. There is a relationship between
NA in M3UA part and local NodeId in MTPL3 part. This relationship is defined
by means of configuration file.




Figure 1   Routing According to the IETF M3UA Standard

To obtain redundancy in IETF_M3UA an AS may comprise several process instances
- so called Application Server Processes (ASP). Commonly, these ASPs are configured
to work in a primary/backup relationship, that is only one of the ASPs is
active at anyone time, the rest are in standby, ready to take over in case
the active ASP fails, see  Figure 1.



2   Compliance Lists



2.1   RFC 4666




Table 1    





References




C




N




P




Comments






Section




Title





-




Abstract




X



 


 


 






1.0




Introduction




-







1.1




Scope




X



 


 


 






1.2




Terminology




X



 


 


 






1.3




M3UA Overview




-







1.3.1




Protocol Architecture




X



 


 


 






1.3.2




Services Provided by the M3UA Layer




X



 


 


 






1.3.2.1




Support for the Transport of MTP3-User Messages




X



 


 


 






1.3.2.2




Native Management Functions




X



 


 


 






1.3.2.3




Inter-working with MTP3 Network Management Functions




X



 


 


 






1.3.2.4




Support for the Management of SCTP associations between the SG
and ASPs




X



 


 


 






1.3.2.5




Support for the Management of Connections to Multiple SGs




X



 


 


 






1.4




Functional Areas




-







1.4.1




Signaling Point Code Representation




X



 


 


 






1.4.2




Routing Contexts and Routing Keys




-







1.4.2.1




Overview




X



 


 



Note 17 on Note17







1.4.2.2




Routing Key Limitations




X



 


 


 






1.4.2.3




Managing Routing Contexts and Routing Keys



 


 



X




Dynamic registration of Routing Keys is not supported







1.4.2.4




Message Distribution at the SGP




X



 


 


 






1.4.2.5




Message Distribution at the ASP




X



 


 


 






1.4.3




SS7 and M3UA Interworking




X



 


 


 






1.4.3.1




Signaling Gateway SS7 Layers




X



 


 


 






1.4.3.2




SS7 and M3UA Interworking at the SG




X



 


 


 






1.4.3.3




Application Server




X



 


 


 






1.4.3.4




IPSP Considerations




X



 


 


 






1.4.4




Redundancy Models




-







1.4.4.1




Application Server Redundancy




X



 


 


 






1.4.5




Flow Control




X



 


 


 






1.4.6




Congestion Management




X



 


 



Note 1 on Note1







1.4.7




SCTP Stream Mapping




X



 


 



Note 2 on Note2







1.4.8




Client/Server Model



 


 



X




Note 3 on Note3







1.5




Sample Configurations




-







1.5.1




Example 1: ISUP message transport




X



 


 


 






1.5.2




Example 2: SCCP Transport between IPSPs




X



 


 


 






1.5.3




Example 3: SG resident SCCP layer, with remote ASP




X



 


 


 






1.6




Definition of M3UA Boundaries




X



 


 


 






1.6.1




Definition of the Boundary between M3UA and an MTP3-User




X



 


 


 






1.6.2




Definition of the Boundary between M3UA and SCTP




-



 


 


 






1.6.3




Definition of the Boundary between M3UA and Layer Management



 


 



X




Note 5 on Note5, Note 6 on Note6







2.0




Conventions




-







3.0




M3UA Protocol Elements




X



 


 


 






3.1




Common Message Header




X



 


 



Note 16 on Note16







3.1.1




M3UA Protocol Version: 8 bits (unsigned integer)




X



 


 


 






3.1.2




Message Classes and Types



 


 



X




RKM messages are not supported.







3.1.3




Reserved: 8 Bits




X



 


 


 






3.1.4




Message Length: 32-Bits (Unsigned Integer) 




X



 


 


 






3.2




Variable-Length Parameter Format




X



 


 


 






3.3




Transfer Messages




-







3.3.1




Payload Data Message (DATA)




X



 


 



Note 7 on Note7



Note 18 on Node18







3.4




SS7 Signaling Network management (SSNM) Messages




-







3.4.1




Destination Unavailable (DUNA)




X



 


 



Note 18 on Node18







3.4.2




Destination Available (DAVA)




X



 


 



Note 18 on Node18







3.4.3




Destination State Audit (DAUD)




X



 


 



Note 18 on Node18







3.4.4




SS7 Network Congestion (SCON)




X



 


 



Note 18 on Node18







3.4.5




Destination User Part Unavailable (DUPU)




X



 


 



Note 8 on Note8, Note 13 on Note13



Note 18 on Node18







3.4.6




Destination Restricted (DRST)




X



 


 



Note 18 on Node18







3.5




Application Server Process Maintenance Messages 




-







3.5.1




ASP Up 




X



 


 



Note 12 on Note12







3.5.2




ASP Up Acknowledgement (ASP Up Ack)




X



 


 


 






3.5.3




ASP Down 




X



 


 



Note 12 on Note12







3.5.4




ASP Down Acknowledgement (ASP Down Ack)




X



 


 


 






3.5.5




Heartbeat (BEAT)




X



 


 


 






3.5.6




Heartbeat Ack (Beat-Ack)




X



 


 


 






3.6




Routing Key Management (RKM) Messages [Optional]




-







3.6.1




Registration Request (REG REQ)



 



X



 



Message is not implemented







3.6.2




Registration Response (REG RSP)



 



X



 



Message is not implemented







3.6.3




Deregistration Request (DEREG REQ)



 



X



 



Message is not implemented







3.6.4




Deregistration Response (DEREG RSP)



 



X



 



Message is not implemented







3.7




ASP Traffic Maintenance (ASPTM) Messages




-







3.7.1




ASP Active 



 


 



X




Note 9 on Note9, Note 12 on Note12







3.7.2




ASP Active Acknowledgement (ASP Active Ack)




X



 


 


 






3.7.3




ASP Inactive




X



 


 



Note 12 on Note12







3.7.4




ASP Inactive Acknowledgement (ASP Inactive Ack)




X



 


 


 






3.8




Management Messages




-







3.8.1




Error 




X



 


 


 






3.8.2




Notify




X



 


 


 






4.0




Procedures




-







4.1




Procedures to Support the Services of the M3UA Layer




-







4.1.1




Receipt of Primitives from the M3UA-User




X



 


 


 






4.2




Receipt of Primitives from the Layer Management 




X



 


 


 






4.2.1




Receipt of M3UA Peer Management Messages




X



 


 


 






4.3




AS and ASP/IPSP State Maintenance




X



 


 


 






4.3.1




ASP/IPSP States




X



 


 



Note 10 on Note10







4.3.2




AS States




X



 


 


 






4.3.3




M3UA Management Procedures for Primitives 




X



 


 


 






4.3.4




M3UA Management Procedures for Peer-to-Peer Messages




-







4.3.4.1




ASP-Up Procedures




X



 


 


 






4.3.4.2




ASP-Down Procedures




X



 


 


 






4.3.4.3




ASP-Active Procedures




X



 


 


 






4.3.4.4




ASP Inactive Procedures




X



 


 


 






4.3.4.5




Notify Procedures 




X



 


 


 






4.3.4.6




Heartbeat Procedures




X



 


 


 






4.4




Routing Key Management Procedures [Optional]




-







4.4.1




Registration



 



X



 



No dynamic registration procedure is implemented







4.4.2




Deregistration



 



X



 



No dynamic deregistration procedure is implemented







4.4.3




IPSP Considerations (REG/DEREG)



 



X



 



This implementation does not support dynamic registration/deregistration
of RK







4.5




Procedures to Support the Availability or Congestion Status of
SS7 Destination




-







4.5.1




At an SGP




X



 


 


 






4.5.2




At an ASP




-







4.5.2.1




Single SG Configurations




X



 


 


 






4.5.2.2




Multiple SG Configurations




X



 


 


 






4.5.3




ASP Auditing




X



 


 


 






4.6




MTP3 Restart




X



 


 


 






4.7




NIF Not Available 




-



 


 



Note 4 on Note4







4.8




M3UA Version Control




X



 


 


 






4.9




M3UA Termination




X



 


 


 






5.0




Examples of M3UA Procedures




-







5.1




Establishment of Association and Traffic between SGs and ASPs




-







5.1.1




Single ASP in an Application Server ("1+0" sparing), No Registration




-







5.1.1.1




Single ASP in an Application Server ("1+0" Sparing), No Registration




X



 


 


 






5.1.1.2




Single ASP in Application Server ("1+0" Sparing), Dynamic Registration



 



X



 



Dynamic registration of RK is not supported







5.1.1.3




Single ASP in Multiple Application Servers (Each with "1+0" Sparing),
Dynamic Registration (Case 1 - Multiple Registration Requests)



 



X



 



Dynamic registration of RK is not supported







5.1.1.4




Single ASP in Multiple Application Servers (each with "1+0" sparing),
Dynamic Registration (Case 2 - Single Registration Request)



 



X



 



Dynamic registration of RK is not supported







5.1.2




Two ASPs in Application Server ("1+1" Sparing)




X



 


 


 






5.1.3




Two ASPs in an Application Server ("1+1" Sparing, Loadsharing Case) 




X



 


 


 






5.1.4




Three ASPs in an Application Server ("n+k" Sparing, Loadsharing
Case) 




X



 


 


 






5.2




ASP traffic Failover Examples




-







5.2.1




1+1 Sparing, Withdrawal of ASP, Backup Override 




X



 


 


 






5.2.2




1+1 Sparing, Backup Override 




X



 


 


 






5.2.3




n+k Sparing, Loadsharing Case, Withdrawal of ASP 




X



 


 


 






5.3




Normal Withdrawal of an ASP from an Application Server 




X



 


 


 






5.4




Auditing Examples 




-







5.4.1




SG State: Uncongested/Available 




X



 


 



SCON is always sent in answer to DAUD







5.4.2




SG State: Congested (Congestion Level=2) /Available 




X



 


 


 






5.4.3




SG State: Unknown/Available 




X



 


 


 






5.4.4




SG State: Unavailable 




X



 


 


 






5.5




M3UA/MTP3-User Boundary Examples




X



 


 


 






5.5.1




5.5.1 At an ASP




-







5.5.1.1




Support for MTP-TRANSFER Primitives at the ASP 




X



 


 


 






5.5.2




At an SGP 




-







5.5.2.1




Support for MTP-TRANSFER Request Primitive at the SGP 




X



 


 



Note 14 on Note14, Note 11 on Note11







5.5.2.2




Support for MTP-TRANSFER Indication Primitive at the SGP 




X



 


 



Note 14 on Note14







5.5.2.3




Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication Primitives 




X



 


 


 






5.6




Examples for IPSP Communication 




-







5.6.1




Single Exchange 




X



 


 


 






5.6.2




Double Exchange 




X



 


 


 






6.0




Security Considerations



 



X



 


 






7.0




IANA Considerations




-







7.1




SCTP Payload Protocol Identifier




X



 


 


 






7.2




M3UA Port Number 




X



 


 


 






7.3




M3UA Protocol Extensions



 



X



 



Note 15 on Note15







7.3.1




IETF-Defined Message Classes 




-



 


 


 






7.3.2




IETF Defined Message Types 



 



X



 



Note 15 on Note15







7.3.3




IETF-Defined Parameter Extension 



 



X



 



Note 15 on Note15







8.0




Acknowledgements




-







9.0




Document Contributors 




-







10.0




References




-







10.1




Normative References 




-







10.2




Informative References 




-







-




Appendix A 




-







A.1




Signaling Network Architecture 




X



 


 


 






A.2




Redundancy Models 




-







A.2.1




Application Server Redundancy 




X



 


 


 






A.2.2




Signaling Gateway Redundancy




X



 


 


 



2.2   Notes and Comments



Note 1 M3-IETF supports three types of congestion management:
Signaling of congestion in International Networks, in National Networks which
uses multiple congestion levels and which employ congestion priorities, and
finally, signaling of congestion in National Networks which uses multiple
congestion levels, but which do not employ congestion priorities. If M3-IETF
resides in a SG and an SCON message is received which is destined to an SS7SEP,
the SCON message triggers the generation of a TFC message. Conversely, if
M3-IETF resides in a SG and a TFC message is received which is destined to
a IPSEP, the TFC message triggers an SCON message to be sent. Except for the
translation between TFC and SCON messages, the congestion management of M3UA
part of M3-IETF works essentially in the same way as the MTP-L3 congestion
management in National networks with multiple congestion levels. However,
it should be noted that even though M3UA part of M3-IETF supports multiple
congestion levels, SCTP is only able to signal congestion onset and congestion
abatement. Thus, when an SCON message is triggered by congestion on a link
in the IP network, M3-IETF will only signal congestion onset and congestion
abatement. In National Networks with multiple congestion levels, M3-IETF will
set the congestion level of the triggered SCON message to the highest defined
congestion level. Typically, this means a congestion level of 3.
Note 2 Within an SCTP association, a stream is selected
using the SLS. See Reference [3], Chapter 4.8 for the details.
Note 3 All process types (ASP, SGP and IPSP) are able
to act as client or server. As an option the endpoint can also be configured
to work at the same time as client and server, i.e. to take role of client
or server for initiating SCTP associations. In current implementation the
role on SCTP layer is combined with the role on M3UA layer so that SCTP client
will as well start ASPSM and ASPTM procedures whether it be ASP, SGP or IPSP.
One of the consequences is that IPSP Double Exchange scenario can only be
activated correctly in client/peer relationsheep.
Note 4 The NIF component are part of the Ericsson SS7
MTPL3& M3UA IETF signaling component.
Note 5 The following messages are not supported by M3-IETF:
see  Table 2.
Note 6 M3-IETF interface supports to a large extent the
same functionality as the IETF M3UA interface. The  Table 3 summarizes
the compliance of the M3-IETF interface with respect to the IETF M3UA interface.
Following TLV parameters are supported by M3-IETF: see  Table 4.
Note 7  The optional parameter "Correlation Id" is never
sent by M3-IETF. If received, this parameter is discarded without prior notification
to the UP.
Note 8 The optional parameter "Concerned Destination"
can optionaly be included in DUPU message in those cases the DUPU message
is triggered by an UPU message. The OPC specified in the UPU becomes the "Concerned
Destination" in the DUPU message.
Note 9 Broadcast traffic mode is not supported.
Note 10 The two primitives SCTP CDI and SCTP RI are not
supported by M3-IETF, instead these primitives essentially corresponds to
the primitives SCTP_COMM_LOST_ind and SCTP_ASSOC_RESTART_ind, respectively.
Note 11  The concept NA is used by M3-IETF to discriminate
the traffic between different local nodes on SGP. There is mapping table in
SGP which defines NA for every local NodeId. When routing DATA messages on
SGP RC is used first while determing NodeId. If RC is absent or useless NA
is used.
Note 12 ASPUP, ASPAC, ASIA and ASPDN message can be sent
not only by ASP and IPSP but also by SGP. Roles in ASPSM/ASPTM messaging are
governed by “ASP messaging” configuration parameter.
Note 13 As a configuration option DUPU message can also
be used by ASP to answer a DATA message destined to unavailable user.
Note 14 It is possible to have a local User at an SGW.
This User can communicate with both SS7 and IP networks as a common user at
an SS7SEP or IPSEP correspondingly.
Note 15 As an extension to RFC4666 in this implementation
DUPU message can be sent in ASP to SGP dorection. Also an optional “Concerned
Destination” parameter can be put into DUPU message. These extensions
have not been registered through IANA.
Note 16 When M3-IETF sends any message over SCTP it provides
to SCTP parameter “Protocol Id”. This parameter isn't coded in
network byte order. It is not violation of RFC4666“ becasue Protocol
Id” is not part of the M3UA message it is part of the SCTP message.
Note 17 It is possible to configure not RFC compliant
behavior of RC supporting. The parameter ”RC Handling” for remote
SP determines which of the behaviors will be used: RCF compliant or E-Sigtran
compliant. This allows M3-IETF to communicate with E-Sigtran compliant implementation
of M3UA even when more than one AS is served by remote SP. In this case M3-IETF
handles MGMT, ASPTM and DATA messages without RC even if RC is a mandatory
parameter according to RFC4666. M3-IETF also sends such messages without RC.
In addition to E-Sigtran compliant behavior the parameter ”RC Handling”
determines the ability to ignore Routing Context parameter from an incoming
message. In this case M3-IETF will process the message as if it did not contain
RC.
Note 18 It is possible to configure not RFC compliant
behavior of including NA into DATA and SSNM messages. The Bit 1 of the parameter ”Remote
SP Extended Options” for remote SP determines which of the behaviors
will be used: whether NA should be mandatory parameter for these messages
or not. If Bit 1 is set to 1, NA parameter should always included into messages
whether it configured for this remote SP or not.




Table 2    





Message Class




Message Type




Comment





RKM




REG REQ




(1)







REG RSP




(1)







DEREG REQ




(1)







DEREG RSP




(1)



(1) Message never sent by M3-IETF, and when received, M3-IETF responds
by sending an ERROR message with error code 0x03 (Unsupported Message Class).





Table 3    





IETF M3UA Primitive




M3-IETF





M-SCTP_ESTABLISH request




Supported.







M-SCTP_ESTABLISH confirm




Supported.







M-SCTP_ESTABLISH indication




Supported.







M-SCTP_RELEASE request




Supported.







M-SCTP_RELEASE confirm




Supported.







M-SCTP_RESTART indication




Supported.







M-SCTP_STATUS request




Supported.







M-SCTP_STATUS confirm




Supported.







M-SCTP_STATUS indication




Supported.







M-ASP_STATUS request




Supported.







M-ASP_STATUS confirm




Supported.







M-AS_STATUS request




Supported.







M-AS_STATUS confirm




Supported.







M-NOTIFY indication




Supported.







M-ERROR indication




Supported.







M-ASP_UP request




Supported.







M-ASP_UP confirm




Supported.







M-ASP_UP indication




Supported.







M-ASP_DOWN request




Supported.







M-ASP_DOWN indication




Supported.







M-ASP_ACTIVE request




Supported.







M-ASP_ACTIVE confirm




Supported.







M-ASP_ACTIVE indication




Supported.







M-ASP_INACTIVE request




Supported.







M-ASP_INACTIVE confirm




Supported.







M-ASP_INACTIVE indication




Supported.







M-AS_ACTIVE indication




Supported.







M-AS_INACTIVE indication




Supported.







M-AS_DOWN indication




Supported.







M-RK_REG request




Not supported.







M-RK_REG confirm




Not supported.







M-RK_DEREG request




Not supported.







M-RK_DEREG confirm




Not supported.







M-RK_DEREG indication




Not supported.






Table 4    





TLV Parameter




Parameter ID





Info String




0x0004







Routing Context




0x0006







Diagnostic Information




0x0007







Heartbeat Data




0x0009







Traffic Mode Type




0x000b







Error Code




0x000c







Status




0x000d







ASP Identifier




0x0011







Affected Point Code




0x0012







Network Appearance




0x0200







User/Cause




0x0204







Congestion Indications




0x0205







Concerned Destination




0x0206







Local Routing Key Identifier




0x020a







Protocol Data




0x0210





Glossary


AS
Application Server
 
ASP
Application Server Process
 
ASPSM
Application Server Process State Maintenance
 
ASPTM
Application Server Process Traffic Maintenance
 
DAUD
Destination State Audit
 
DAVA
Destination Available
 
DPC
Destination Point Code
 
DRST
Destination Restricted
 
DUNA
Destination Unavailable
 
DUPU
Destination User Part Unavailable
 
E-M3UA
Ericsson SS7 MTPL3&M3UA Signaling Component
 
IANA
Internet Assigned Number Authority
 
IETF
Internet Engineering Task Force
 
IP
Internet Protocol
 
IPSP
IP Server Process
 
ITU
International Telecommunications Union
 
LFU
Link Forced Uninhibit
 
M3
SS7 MTP-L3 & M3UA
 
M3-IETF
SS7 MTP-L3 & M3UA-IETF
 
M3UA
MTPL3 User Adaptation Layer
 
MTP3
Message Transfer Part Level 3
 
MTP-L3
Message Transfer Part Level 3
 
NA
Network Appearance
 
NI
Network Indicator
 
OPC
Originating Point Code
 
RC
Routing Context
 
RK
Routing Key
 
RKM
Routing Key Management
 
SCON
Signaling Congestion
 
SCTP
Stream Control Transmission Protocol
 
SEP
Signaling Endpoint
 
SG
Signaling Gateway (M3UA)
 
SGP
Signaling Gateway Process
 
SI
Service Indicator
 
SP
Signaling Point
 
SPMC
Signaling Point Management Cluster
 
SS7
Signaling System No. 7
 
SS7SEP
Signaling Endpoint in an SS7 network
 
SSN
Subsystem Number
 
SSNM
SS7 Signaling Network Management Messages
 
STP
Signaling Transfer Point
 
TFC
TransFer Control signal
 
UP
User Part


Reference List


IETF Standard
[1] K. Morneault, J. Pastor-Balbas eds., Signaling
System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA),
RFC 4666, September 2006.
ITU Standard
[2] Signaling network functions and messages,
ITU-T, Q.704.
M3-IETF FS
[3] Function Specification for MTPL3 & M3UA
IETF, 155 17-CAA 901 1817 Uen.
















Copyright


© Ericsson AB 2008, 2011-2012. All rights reserved. No
part of this document may be reproduced in any form without the written permission
of the copyright owner.




Disclaimer


The contents of this document are subject to revision without notice due
to continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.











     SS7 MTP-L3 and M3UA IETF IETF RFC 4666         Statement of Compliance