Internet DRAFT - draft-zhang-sigtran-m3ua-req
draft-zhang-sigtran-m3ua-req
SIGTRAN Zhang Hao
Chen Xu
Duan Xiaodong
Peng jin
Internet Draft Zhao Yuyi
Intended status: Informational China Mobile
Expires: August 2008 February 18, 2008
The requirement of extending RFC4666 for the M3UA deployment
draft-zhang-sigtran-m3ua-req-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 1]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
Abstract
RFC 4666 defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.
M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP
applications, so the network level management function isn't required.
SSNM(SS7 Signalling Network Management) messages defined in M3UA are
only used for interworking with SS7. RFC 4666 doesn't define IPSEP-
IPSTP-IPSEP application of M3UA. The signalling network management
function for this application needs to be extended.
Some parts of the specification are unclear,which may lead to
misinterpretations and may weaken interoperability.
This document provides extensions and clarifications to RFC 4666.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction................................................3
2. The requirement for IP based signalling network..............3
3. The requirement for the extension of signalling network management
function of M3UA for IPSEP-IPSTP-IPSEP application..............4
4. About the terminology........................................7
5. About the sample configuration...............................8
6. About SCTP Client/Server Model...............................8
7. About the functional area....................................8
8. About Destination User Part Unavailable (DUPU)...............8
9. About procedures............................................9
10. About sample configuration for BICC.........................9
11. About Message Length for M3UA message format................9
12. About Destination State Audit(DAUD).........................9
13. Formal Syntax.............................................10
14. Security Considerations....................................10
15. IANA Considerations........................................10
16. Conclusions...............................................10
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 2]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
17. Acknowledgments...........................................10
18. References................................................11
18.1. Normative References..................................11
Author's Addresses............................................11
Intellectual Property Statement................................12
Disclaimer of Validity........................................12
1. Introduction
RFC 4666 defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.
M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP
applications, so the network level management function isn't required.
SSNM(SS7 Signalling Network Management) messages defined in M3UA are
only used for interworking with SS7. RFC 4666 doesn't define IPSEP-
IPSTP-IPSEP application of M3UA. The signalling network management
function for this application needs to be extended.
Some parts of the specification are unclear,which may lead to
misinterpretations and weaken interoperability.
This document provides extensions and clarifications to RFC 4666.
2. The requirement for IP based signalling network
The application of SIGTRAN standard for SG has ever solved the
problems of interworking between No.7 Signalling System and IP system.
It also helps to settle the problems about transmission of access
network signalling in R4 CS core network.
The world trend of IP bearer for signalling will make SIGTRAN
standard widely used in signalling network, and also make IP based
signalling network possible.
An IP based SS7 signalling network using M3UA/SCTP/IP as transport
layer has been defined by 3GPP, SEPs such as HLR, MSC can communicate
with each other directly by accessing to this IP based signalling
network. When deploying a large scale signalling network based on IP,
it is better to separate the network into several sections, keep the
number of SEPs in each section in an appropriate degree. IPSTPs are
needed between different sections to simplify the GT data and
converge the SCTP association data. And it is recommended that M3UA
should be used on the IPSTP-IPSEP interface, while M2PA may be used
on the IPSTP- IPSTP interface.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 3]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
The architecture of IP based signalling network is as follows:
+---------------+ +--------------+
| | | |
--IP-----------| [IPSTP] |--IP(M2PA)--| [IPSTP] |
| | | | | | |
| +-------|-------+ +----- |------+
| Signalling transfer point Signalling transfer point
| IP(M3UA) IP(M3UA)
| +-------|-------+ +------|--------+
(M3UA) | | | | | |
| | [IPSEP] + + [IPSEP] |
| | | | |
| | | | |
| +---------------+ +---------------+
| Signalling end point Signalling end point
|
| +---------------+
| | |
------+ [IPSEP] +
| |
+---------------+
Signalling end point
Figure 1 The architecture of IP based signalling network.
3. The requirement for the extension of signalling network management
function of M3UA for IPSEP-IPSTP-IPSEP application
As same as the traditional TDM based SS7 signalling network, an IP
based SS7 signalling network also provides signalling network
management functions, such as signalling traffic management,
signalling link management , and signalling route management, to
insure the availability and traffic transport capacity of a
signalling network in case of failures and congestion.
For a large scale signalling network based on IP with IPSTPs, the
usage of M2PA on IPSTP-IPSTP interface can help to realize the
signalling network management between different sections of the
signalling network. But M3UA can not fulfil the signalling network
management within a section completely at present, the extension of
it for this application is needed. The reason for the extension will
be discussed in this section.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 4]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
Within a section of a large scale signalling network based on IP with
IPSTPs, the normal signalling transport route between two IPSEPs will
transit an IPSTP. When the destination IPSEP is not available
Scenario 1 , the IPSTP must notify the source IPSEP to choose
another route. And when the user part of the destination IPSEP is
not available Scenario 2 , the IPSTP must also notify the source
IPSEP to stop the signalling traffic.
M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP
applications, so the network level management function isn't required.
SSNM(SS7 Signalling Network Management) messages defined in M3UA are
only used for interworking with SS7. M3UA specification doesn't
define signalling network management function for the IPSEP-(IP)-
IPSEP-(IP)-IPSEP application.
Scenario 1: the destination SP is not available
In Scenario 1, when IPSTP1 finds the destination IPSEP (AS,IPSEP2) in
IP domain is not available,and there is no connection between IPSTP1
and IPSTP2,or the connection between IPSTP1 and IPSTP2 is not
available. It is a matter of M3UA spec interpretation whether IPSTP1
sends a DUNA message or not to IPSEP1 upon failure of signaling
connection towards IPSEP2.M3UA spec does not prohibit this, but it
seems there is a bit of unclarity on whether SSNM Message can be sent
by the IPSTP in the context of a AS->SG-AS interworking, while it is
very clear that IPSTP can send such message in the context of SEP ->
SG -> AS. In result, the source IPSEP (AS,IPSEP1) doesn't know the
route is unavailable and still sends traffic to IPSTP1, which makes
the signalling transport failure.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 5]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
+---------------+ +--------------+
| | \ / | |
+-- --| [IPSTP1] |--IP(M2PA)-\- | [IPSTP2] | +
| | | | / \ | | | |
| +-------+-------+ +-------+------+ |
| Signalling transfer point Signalling transfer point |
| | \ / | |
| +---- IP(M3UA)-----\------+ | |
| / \ | | |
IP(M3UA) | | IP(M3UA)
| | | |
| | | | | |
| |1 | | 3 | |
| |DUNA | | DATA | |
| | 2 DATA | | | |
| | ---------------> | | | |
|\|/ +---- IP(M3UA)--------------|----+ \|/ |
| | | |
| +---------------+ +---------------+ |
| | | | | |
------+ [IPSEP1] + + [IPSEP2] +---+
| | | |
+---------------+ +---------------+
Signalling end point Signalling end point
Figure 2 Scenario 1 - the destination IPSEP is not available.
Scenario 2: the user part of the destination SP is not available
In Scenario 2, when the user part of the destination
IPSEP(AS,IPEP2 ) is not available, M3UA doesn't define the
destination SP(AS,IPSEP2)'s M3UA layer can send proper SSNM message
(DUPU) to notify the source IPSEP (AS, IPSEP1),and doesn't define
IPSTP's M3UA layer can transfer the DUPU to the proper
IPSEP(AS,IPSEP1) either. In addition ,DUPU contains no DPC field
to indicate the address of the source IPSEP(AS,IPSEP1) which is
the originator of the message( DATA) that triggered the DUPU. In
result, the source IPSEP (AS,IPSEP1) doesn't know the user part of
IPSEP2 is unavailable and still sends traffic to IPSEP2 , which
makes the signalling transport failure.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 6]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
+---------------+
| |
+-- --| [IPSTP1] |----------------------+
| | | | |
| +-------+-------+ |
| Signalling transfer point |
| |
| |
| |
IP(M3UA) IP(M3UA)
| |
|/|\ | /|\ | |
| |1 |4 3 | 2 | |
| |DATA |DUPU DUPU| DATA | |
| | | | | |
| | | | | |
| | \|/ | \|/|
| |
| +---------------+ +----------------+
| | | | \ / |
------+ [IPSEP1] + + \[IPSEP2] +
| | | / \User Part|
+---------------+ +----------------+
Signalling end point Signalling end point
Figure 3 Scenario 2 - The expected signalling network management
function in M3UA.
So, the extension of M3UA for this application is needed.
4. About the terminology
In section 1.2 it provides the terminology of the SEP and STP, but
there all are nodes in SS7 network. After introducing M3UA, if all
those IP SEP are connected each other, each IP SEP should configure
all the other IP SEP's SCTP and M3UA information. The maintenance and
management work is too heavy.
So IP STP should be introduced into the network and each IP STP
covers a number of IP SEP and each IP SEP need only configure the IP
STP's SCTP/M3UA information.
IP SEP sends correlative messages to IP STP, and it is the
responsibility of IP STP to relay those message to another IP SEP.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 7]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
For the scenario of IP STP, there is the need to introduce IPSTP and
IPSEP.
5. About the sample configuration
In section 1.5 there are three examples where M3UA is used. But the
examples focus on the scenarios of SG implement and IPSP to IPSTP. If
the IPSTP is deployed in the IP based signalling network, the network
model should be extended. At least, the network model about IPSEP-
IPSTP-IPSEP, IPSEP-IPSTP-IPSTP/STP/SEP should be added in order to
extend the application of M3UA in the IP based singling network.
6. About SCTP Client/Server Model
In section 1.4.8 there is a statement about the SCTP Client/Server
Model for SG and IPSP to IPSP scenarios. In order to avoid the
interoperability after IPSTP is deployed in the IP based signalling
network, the SCTP Client/Server Model for IPSTP and IPSEP should be
specified.
7. About the functional area
In section 1.4 the function areas which should be supported by SG
and IPSP are listed. And the network management messages are defined
in section 3.4 and it is the mandatory function to be supported by
the nodes which deploy M3UA protocol. But the function about the
network management function is not specified in section 1.4.
Especially after the IPSTP is deployed in IP based signalling network,
the network management function is more important. It is necessary to
add M3UA signalling network management function in section 1.4
especial for the IPSTP and IPSEP.
8. About Destination User Part Unavailable (DUPU)
In section 3.4.5, the DUPU message is defined. But when the message
is defined, it only considers the scenarios of SG and IPSP and not
the scenario where IPSTP is deployed in the IP based signalling
network. If IPSEP A sends a message to IPSEP B by through IPSTP,
after the IPSEP B receives the M3UA layer DATA message, and finds
that it could not be sent to appointed upper layer user, IPSEP B will
feedback DUPU to the source point with the correlation reason. But if
DUPU is not extended, the DUPU perhaps could not be returned back to
IPSEP A by through IPSTP because DUPU only can be sent to IPSTP with
the DPC is IPSTP. Only the source point code is included in the DUPU
message, the DUPU can be feedback to the source point after the
IPSTP's M3UA Parses the source PC field to transmits it to
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 8]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
corresponding signalling point if the source PC not point to the
IPSTP.
9. About procedures
This section describes the M3UA procedures in response to the M3UA
special events. If the IPSTP is deployed in the IP based signalling
network, the procedures to support DUPU in IPSEP-IPSTP interface and
the procedures to support DUNA/DAVA/SCON/DAUD in IPSEP-IPSTP
interface should the specified.
10. About sample configuration for BICC
In section 1.5 there are three examples where M3UA is used. But the
examples focus on the scenarios of SG implement and IPSP to IPSTP. To
IPSP-IPSP scenario, only the SCCP over M3UA is presented. As the
popular call control protocol, BICC is widely used in the
telecommunication network. And BICC is also based on M3UA. So the
sample configuration for BICC Transport between IPSPs should also be
presented.
11. About Message Length for M3UA message format
In section 3.1.4 the statement whether the message length should
include the padding octets is inconsistent. The text states that the
message length should include the padding octets but the note says
that the message length can not include the padding octets. The
inconsistent statements can bring on the interoperability problem. It
is suggested that the note in the section 3.1.4 should be deleted.
12. About Destination State Audit(DAUD)
In section 3.4.3, the DAUD message is defined. But it does not
specify whether IPSP can send DAUD with its own Point Code or not
which brings on the divarication for understanding.
The statement should be declared definitely whether it is allowed or
not. And if the IPSTP receives a DAUD message from IPSEP A with the
Affected Point Code parameter which is just the IPSEP A, the IPSTP
should refuse it or return the status. It should also be declared
definitely to avoid interoperability problem.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 9]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
13. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [2].
14. Security Considerations
Implementations MUST follow the normative guidance of RFC3788 on the
integration and usage of security mechanisms in SIGTRAN protocol.
15. IANA Considerations
This document contains no new actions for IANA.
16. Conclusions
According to this document, it is needed to supplement and extend
RFC4666 for its widely usage in the IP based Signalling Network.
17. Acknowledgments
The authors wish to thank Zhao Yuyi, Peng Jin, Zhang Juan, and many
others for their invaluable comments.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 10]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
18. References
18.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] K. Morneault, et al. " Signalling System 7 (SS7) Message
Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)" RFC4666,
September 2006.
Author's Addresses
Zhang Hao
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3281
Email: zhanghao@chinamobile.com
Chen Xu
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3163
Email: chenxu@chinamobile.com
Duan Xiaodong
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3062
Email: duanxiaodong@chinamobile.com
Peng Jin
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3252
Email: pengjin@chinamobile.com
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 11]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
Zhao Yuyi
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3072
Email: zhaoyuyi@chinamobile.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 12]
Internet-Draft The requirement of extending RFC4666 February 2008
for the M3UA deployment
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang,Chen,Duan,Peng,Zhao Expires August 18, 2008 [Page 13]
