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]