One document matched: draft-chen-sigtran-m3ua-ext-00.txt
SIGTRAN Chen Xu
Internet Draft China Mobile
Intended status: Informational Li Xinyan
Expires: May 2008 Alcatel Shanghai Bell
Zhang hao
Duan Xiao Dong
China Mobile
The proposal of extenting RFC4666 for the M3UA deployment
draft-chen-sigtran-m3ua-ext-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 May 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 1]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
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. Some parts of
the specification are unclear that may lead to misinterpretations
that may impair interoperability between different implementations.
RFC 4666 doesn't define the application of IPSTP-IPSEP interface. For
the signalling network management function, messages and procedures,
it needs more contributes.
This document provides clarifications and amendments 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
1.1. Scope.......................................... 3
1.2. Terminology..................................... 3
2. Conventions ......................................... 3
3. Clarifications and Amendments........................... 4
3.1. IPSTP-IPSEP Interface............................. 4
3.1.1. Update Section 1.5. Sample Configuration......... 4
3.1.2. Update Section 1.4.8. SCTP Client/Server Model .... 6
3.2. Define the signalling network management function messages
and procedures....................................... 6
3.2.1. Update Section 1.4 Functional Areas ............. 6
3.2.2. Update 3.4.5. Destination User Part Unavailable (DUPU)7
3.2.3. Update Section 4 Procedures.................... 9
3.3. Other Clarifications and Corrections................ 10
3.3.1. Update Section 1.5. Sample Configuration ........ 10
3.3.2. Update Section 3.1.4. Message Length: 32-Bits (Unsigned
Integer) ........................................ 11
3.3.3. Update Section 3.4.3. Destination State Audit (DAUD)11
4. Security Considerations............................... 11
5. Acknowledgments..................................... 12
6. References......................................... 12
6.1. Normative References............................. 12
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 2]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
Author's Addresses..................................... 12
Intellectual Property Statement .......................... 13
Disclaimer of Validity.................................. 14
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. During
implementation and interoperability testing of RFC 4666, some
ambiguities and common misinterpretations have been identified.
This document summarizes identified issues and provides
clarifications needed for implementations of RFC 4666 to interoperate,
i.e., it constitutes an update to RFC 4666. This document also makes
amendments to RFC 4666. References to RFC 4666 should, therefore,
also include this document.
1.1. Scope
1) Define the Application for IPSTP-IPSEP interface.
2) Define the signalling network management function messages,and
procedures
3) Other Clarifications and Corrections
1.2. Terminology
IP Signaling Transfer Point (IPSTP) - STP in the IP Signaling Network
with IP Signaling Interface. It has its own Point Code, can perform
SS7/M3UA messages routing, screening and transfer.
Internal Signalling Gateway (Internal SG) - A SG which exists in MGW
physically or locates with MGW.
IP Signaling End Point (IPSEP) - A node in the M3UA network
associated with an originating or terminating local exchange (switch)
or a gateway exchange.
2. Conventions
In this document, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL
NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and
OPTIONAL are to be interpreted as described in [RFC2119].
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 3]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
3. Clarifications and Amendments
3.1. IPSTP-IPSEP Interface
3.1.1. Update Section 1.5. Sample Configuration
Add different kinds of application scenarios for IPSEP-IPSTP
interface.
1.5.y Network Model: IPSEP-IPSTP-IPSEP
******** IP ***************** IP ********
*IPSEP *---------* IPSTP *--------*IPSEP *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP | | SCCP | | SCCP |
+------+ +---------------+ +------+
| M3UA | | M3UA | | M3UA |
+------| +---------------+ +------+
| SCTP | | SCTP | | SCTP |
+------+ +---------------+ +------+
| IP | | IP | | IP |
+------+ +---------------+ +------+
|_______________| |______________|
Figure 1 Network Model for IPSEP-IPSTP-IPSEP.
In this network model, IPSTP provides MTP user signaling messages'
transfer, M3UA management messages' transfer and SCCP signaling
through IPSTP M3UA IPSP.
1.5.z Network Model: IPSEP-IPSTP-IPSTP/STP/SEP (i.e. IPSEP
communicates with IPSTP/STP/SEP through IPSTP)
In the following network models, IPSTP provides MTP user signaling
messages' transfer, M3UA management messages' transfer and SCCP
signaling through IPSTP M3UA SGP.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 4]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
******** IP ***************** IP ********
*IPSEP *---------* IPSTP *--------*IPSTP *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +------+ +------+ +------+
| | | | | MTP3 | | MTP3 |
| M3UA | | M3UA | +------+ +------+
| | | | | M2PA | | M2PA |
+------| +------+-+------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
Figure 2 Network Model for IPSEP-IPSTP-IPSTP.
In the above network model, IPSEP communicates with IPSTP through
IPSTP.
******** IP ***************** SS7 ********
*IPSEP *---------* IPSTP *--------* SEP *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP | | (NIF) | | SCCP |
+------+ +------+ +------+ +------+
| M3UA | | M3UA | | MTP3 | | MTP3 |
+------| +------+-+------+ +------+
| SCTP | | SCTP | | MTP2 | | MTP2 |
+------+ +------+ +------+ +------+
| IP | | IP | | L1 | | L1 |
+------+ +------+ +------+ +------+
|_______________| |______________|
Figure 3 Network Model fro IPSEP-IPSTP-SEP.
In the above network model, IPSEP communicates with SEP through IPSTP.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 5]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
******** IP ***************** SS7 ********
*IPSEP *---------* IPSTP *--------* STP *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP | | (NIF) | | SCCP |
+------+ +------+ +------+ +------+
| M3UA | | M3UA | | MTP3 | | MTP3 |
+------| +------+-+------+ +------+
| SCTP | | SCTP | | MTP2 | | MTP2 |
+------+ +------+ +------+ +------+
| IP | | IP | | L1 | | L1 |
+------+ +------+ +------+ +------+
|_______________| |______________|
Figure 4 Network Model fro IPSEP-IPSTP-STP.
In the above network model, IPSEP communicates with STP through IPSTP.
3.1.2. Update Section 1.4.8. SCTP Client/Server Model
Add the Client/Server Model for IPSTP-IPSEP interface.
Add the following sentences as the third paragraph: In the case of
IPSTP to IPSEP communication, the default orientation would be for
the IPSTP to take on the role of server while the IPSEP is the
client. In this case, IPSEP SHOULD initiate the SCTP association to
the IPSTP.
3.2. Define the signalling network management function messages and
procedures
3.2.1. Update Section 1.4 Functional Areas
Add M3UA signalling network management function as 1.4.9 1.4.9. M3UA
signalling network management function
For IPSEP,
- When IPSEP receives a M3UA layer DATA message, and finds that it
could not be sent to appointed upper layer user, IPSEP shall send
DUPU to the source point to indicate with the reason: Unknown,
Unequipped Remote User or Inaccessible Remote user.
- Shall support SCON/DUNA/DAVA message receiving, refer to
corresponding Procedure description.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 6]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
- Shall support DAUD message sending, refer to corresponding
Procedure description.
For IPSTP,
- Shall support the DUPU message receiving and handling
- When receiving TFC/TFA/TFP message, shall convert to corresponding
M3UA SSNM message to IPSEP.
- When adjacent IPSEP availability, congestion status change, shall
report it to IPSEP through SCON/DUNA/DAVA, to IPSTP/SEP/STP through
TFC/TFA/TFP.
- When adjacent SEP/STP/IPSTP availability, congestion status change,
shall report it to IPSEP through SCON/DUNA/DAVA.
- Shall support DAUD message receiving procedure.
3.2.2. Update 3.4.5. Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a
remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is
unavailable.
This message is also used by IPSEP to inform IPSEP/SEP/IPSTP that its
corresponding user lary is unavailable.
Extend the DUPU message format. A new field is introduced to DUPU.
Concerned DPC: Destination DPC which has caused DUPU to be generated.
The field Concerned DPC has been defined in RFC3332 for SCON message,
tag is 0x0206.
The DUPU message contains the following parameters:
Network Appearance Optional
Routing Context Conditional
Affected Point Code Mandatory
Concerned Destination Mandatory
User/Cause Mandatory
INFO String Optional
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 7]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
The format for DUPU message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 DUPU Message Format.
Concerned Destination: 32 bits
The Concerned Destination parameter contains one Concerned
Destination Point Code field, a three-octet parameter to allow
for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. A
Concerned Point Code that is less than 24 bits is padded on the
left to the 24-bit boundary.
When IPSEP receives a M3UA layer DATA message, and finds that it
could not be sent to appointed upper layer user, IPSEP will feedback
DUPU to the source point with the reason: Unknown, Unequipped Remote
User or Inaccessible Remote user.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 8]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
In DUPU message, own side's PC shall be fulfilled in Affected PC
field; The source point PC(i.e. DATA Message's OPC, IPSEP or IPSTP's
Point Code) shall be fulfilled in Concerned DPC Field.
Concerned DPC is like DPC in SS7 UPU. Because DUPU in M3UA is a SSNM
message, no DPC in this type of messages. So IPSTP/SG cann't know the
destination to transfer this DUPU. Currently because of this
shortcoming, DUPU handling is suspended in IPSTP/SG products, no real
usage. So shall extend DUPU like SCON, thus IPSTP/SG can know the
destinations of this message from Concerned DPC.
For internal SG, When it receives DUPU from IPSEP, it shall convert
it to UPU to SEP. When converting between DUPU and UPU, Concerned DPC
to DPC, affected PC to affected PC, user/cause to user/cause.
3.2.3. Update Section 4 Procedures
Add one section for signalling network management procedures as
Section 4.x (x is between 5 and 6)
4.x. M3UA signalling network management procedures
4.x.1. Procedures to support DUPU in IPSEP-IPSTP interface
For the interface IPSEP-IPSTP, DUPU message transmission and
receiption procedures are as following:
When IPSEP receives a M3UA layer DATA message, and finds that it
could not be sent to appointed upper layer user, IPSEP will feedback
DUPU to the source point with the reason: Unknown, Unequipped Remote
User or Inaccessible Remote user.
The Procedure of DUPU message handling when IPSTP receives it:
- M3UA analyzes Concerned DPC field, if it is IPSTP's PC and user
is SCCP, reports to SCCP layer that Affected PC's SCCP is
unavailable. SCCP will not send SCCP message to this Affected PC
anymore.
- M3UA Parses Concerned DPC field, if it is not its own PC,
transmits it to corresponding signaling point(i.e. IPSEP or next
jump IPSTP) according to routing table.
The Procedure of DUPU message handling when IPSEP receives it:
- M3UA analyzes Concerned DPC field, if it is own PC, reports to
corresponding user layer that Affected PC's user layer is
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 9]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
unavailable. User layer will not send this kind of messages to
the Affected PC again.
4.x.2 Procedures to support DUNA/DAVA/SCON/DAUD in IPSEP-IPSTP
interface
For IPSEP,
- Shall support SCON/DUNA/DAVA message receiving procedure, to RFC
4666 Section 4.5 for detail.
- Shall support DAUD message sending procedure, to RFC 4666 Section
4.5 for detail.
For IPSTP,
- When receiving TFC/TFA/TFP message, shall convert to corresponding
M3UA SSNM message to IPSEP.
- When adjacent IPSEP availability, congestion status change, shall
report it to IPSEP through SCON/DUNA/DAVA, to IPSTP/SEP/STP through
TFC/TFA/TFP.
- When adjacent SEP/STP/IPSTP availability, congestion status change,
shall report it to IPSEP through SCON/DUNA/DAVA.
- Shall support DAUD message receiving procedure, to RFC 4666 Section
4.5 for detail.
3.3. Other Clarifications and Corrections
3.3.1. Update Section 1.5. Sample Configuration
Add Section 1.5.x Sample Example X: BICC Transport between IPSPs
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 10]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
******** IP ********
* IPSP * * IPSP *
******** ********
+------+ +------+
| BICC | | BICC |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
|________________|
Figure 6 BICC Transport between IPSPs.
This example shows Nc interface between two MSC Servers. In this
example, BICC messages are exchanged directly between two IP-resident
IPSPs through M3UA. In like manner, When M3UA layer delivers MTP-
PAUSE, MTP-RESUME, and MTP-STATUS indication to BICC, it shall
consider SCTP association, IP network status, congestion information
etc.
3.3.2. Update Section 3.1.4. Message Length: 32-Bits (Unsigned Integer)
Delete "Note: A receiver SHOULD accept the message whether or not the
final parameter padding is included in the message length."
3.3.3. Update Section 3.4.3. Destination State Audit (DAUD)
Add the sentence in the end of the Section 3.4.3. "For IPSEP, it
shall not send DAUD with its own Point Code. For IPSTP, if it
receives DAUD with the Affected Point Code parameter which is just
the source IPSEP's, it shall return this IPSEP's status."
4. Security Considerations
This document provides a number of corrections and clarifications to
[1], but it does not make any changes with regard to the security
aspects of the protocol. As a consequence, the security
considerations of [1] apply without additions.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 11]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
5. Acknowledgments
The authors wish to thank Zhao Yuyi, Peng Jin, Zhang Juan, and many
others for their invaluable comments.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] RFC4666 K. Morneault, et al. " Signaling System 7 (SS7)
Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)"
[3] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7
(SS7) - ISDN User Part (ISUP)"
[4] ETSI ETS 300 356-1 "Integrated Services Digital Network
(ISDN);Signalling System No.7; ISDN User Part (ISUP) version 2
for theinternational interface; Part 1: Basic services"
[5] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7
(SS7) - Signalling Connection Control Part (SCCP)"
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Signalling Connection Control Part
(SCCP) (connectionless and connection-oriented class 2) to
support international interconnection; Part 1: Protocol
specification"
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[8] ITU-T Recommendations Q.1902.1 to Q.1902.6, "Specifications of
signalling related to Bearer Independent Call Control (BICC)"
Author's Addresses
Chen Xu
53A
XiBianMennei Ave, XuanWu District, Beijing, China
Phone: +86 10 66006688 3163
Email: chenxu@chinamobile.com
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 12]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
Li Xinyan
Box 525
North XiZang Road, Shanghai, China
Phone: Phone: +86 21 36054510 6839
Email: xinyan.li@alcatel-sbell.com.cn
Zhang Hao
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3281
Email: zhanghao@chinamobile.com
Duan Xiaodong
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3062
Email: duanxiaodong@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.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 13]
Internet-Draft Clarifications and Amendments to RFC 4666 November 2007
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 (2007).
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.
Chen,Li,Zhang,Duan Expires May 13, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 10:15:30 |