Network Working Group X. Cui Internet Draft Huawei Intended status: Informational X. Chen Expires: August 2010 China Mobile February 11, 2010 Problem Statement for Sigtran Network Management draft-cui-tsvwg-snm-ps-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 10, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Cui, et al. Expires August 10, 2010 [Page 1] Internet-Draft PS for Sigtran Network Management February 2010 Abstract Sigtran is widely applied in the telecommunication network but there are still some issues. This document briefly describes some concerned scenarios and presents the association changeover and Sigtran routing management problems. The goal of this document is to analyse the existing shortage of Sigtran and discuss the desirable improvements. 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 [RFC2119]. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. SCTP Association Changeover Problem...........................5 3.1. SCTP Data Retrieval Problem..............................5 3.2. SS7 Adapter over SCTP Problem............................6 3.3. Application Signalling over SCTP Problem.................7 4. Routing Management Problem....................................7 5. Conclusion and Recommendations...............................10 6. Security Considerations......................................10 7. IANA Considerations..........................................10 8. Acknowledgments..............................................10 9. References...................................................11 9.1. Normative References....................................11 9.2. Informative References..................................11 Authors' Addresses..............................................11 Cui, et al. Expires August 10, 2010 [Page 2] Internet-Draft PS for Sigtran Network Management February 2010 1. Introduction Sigtran is designed to provide IP based signaling bearer for the existing switched circuit network signaling protocols. Sigtran typically consists of three components: adaptation sub-layer, common signaling transport protocol (i.e., SCTP) and standard IP transport. Sometimes application signaling protocol can be directly combined with SCTP transport protocol. Sigtran enabled application signaling to be transported in the IP network and in some scenarios Sigtran can also compress the original protocol stack. Sigtran provides an important way to migrate the TDM based circuit-switched network to the IP based packet-switched network. But in some aspects the functionality and performance provided by Sigtran can not meet the same criterion as SS7 or TDM based circuit- switched network. However, these aspects are crucial in the telecommunication. For example, [ITU-T-Q.704] specifies "in the case of a link failure, the traffic conveyed over the faulty link should be diverted to one or more alternative links" (section 3.1) and [ITU-T-Q.704] also introduces changeover mechanism to "ensure that signaling traffic carried by the unavailable signaling link is diverted to the alternative signaling link(s) as quickly as possible while avoiding message loss, duplication or mis-sequencing" (section 5.1.1). This requirement is very important to telecommunication network but this functionality is not inherited in Sigtran solutions. On the other hand, Sigtran provides a new manner for signaling transport. But in the Sigtran network some SS7 network management functions are affected and the existing Sigtran network management can not meet the requirements of telecommunication network. Some analyses are provided and some problems are also stated in this document. Section 3 is about SCTP association changeover and section 4 is about routing management in Sigtran network. Conclusion and recommendation are provided at last. 2. Terminology All the Sigtran related terms used in this document are to be interpreted as defined in Stream Control Transmission Protocol [RFC4960] and Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) [RFC4666]. Cui, et al. Expires August 10, 2010 [Page 3] Internet-Draft PS for Sigtran Network Management February 2010 This document also provides the following context-specific explanation to the following terms used in this document. These terms are defined in 3GPP specifications. eNodeB (eNB) The eNodeB is the radio station of 3GPP's future LTE wireless communication standard. Evolved Packet Core (EPC) EPC is the core network architecture of 3GPP's future LTE wireless communication standard. E-UTRAN E-UTRAN is the Evolved Universal Terrestrial Radio Access Network in 3GPP standard. LTE LTE is the project name of a new high performance air interface for cellular mobile communication systems in 3GPP standard. It is the last step toward the 4th generation (4G) of radio technologies designed to increase the capacity and speed of mobile telephone networks. Mobility Management Entity (MME) MME is the key control plane entity within Evolved Packet Core. MME functions include Non-Access-Stratum signaling, mobility management, Bearer management, etc. S1 Interface between an eNB and an EPC, providing an interconnection point between the E-UTRAN and the EPC. S1-MME interface The S1-MME is a reference point for the control plane protocol between E-UTRAN and MME in 3GPP standard. Cui, et al. Expires August 10, 2010 [Page 4] Internet-Draft PS for Sigtran Network Management February 2010 3. SCTP Association Changeover Problem 3.1. SCTP Message Retrieval Problem In SCTP specification [RFC4960], some primitives are defined to provide SCTP transport service to the ULP. The ULP can use "Receive Unsent Message" and "Receive Unacknowledged Message" primitives to retrieve the data that need retransmission or other disposal. The ULP can get the related information from SCTP layer by "Status" or "COMMUNICATION LOST notification" primitives. But in fact, in most scenarios the ULP can not get the accurate information related to the acknowledged/unacknowledged data. For example, in the flowing scenario: Endpoint A IP network Endpoint B ULP SCTP | SCTP ULP | SEND | | | | |------------->|> | | | | | \ | data #1 | | | | >-----|---------------->\ | | | SEND | | \ | | |------------->|> | >| | | | \ | data #2 /| | | | >-----|---------------->\/ | | | SEND | | sack #1 /\ | | |------------->|> |<---------------< >| | | | \ /| data #3 /| | | | >---/-|---------------->\/ | | | T1|<----< | /\ | | | (T2)| | / >|T2 | | | | / /| | | /--| | sack #2 / / | | | / | |<------------< / | | | / | /| sack #3 / | | | T: | | | | | | |RETRIEVAL | | | | |<------------>| | | | | | | | | Figure 1 SCTP Message Retrieval Issue Cui, et al. Expires August 10, 2010 [Page 5] Internet-Draft PS for Sigtran Network Management February 2010 In such an assumption, endpoint A sends data to endpoint B. At time T1 endpoint A receives the first sack for data #1, at time T2 endpoint B receives all data #1, #2 and #3, and responds sack #1, #2 and #3. Endpoint A receives sack #2 and #3 respectively at time T3 and T4. In this flow the time sequence is T1 < T2 < T3 < T4. If the IP network that connecting endpoint A and endpoint B is interrupted at time T which is between T2 and T3, endpoint B should receive data #1, #2 and #3, but endpoint A should only receive sack for data #1. When the SCTP layer in endpoint A sends COMMUNICATION LOST notification to the ULP layer, SCTP indicates ULP that data #2 and #3 are not acknowledged, so if the ULP layer retrieves unacknowledged data and retransmits the data in some other manner, the endpoint B would receives the duplicated data #2 and #3, which is explicitly a wrong result. If the IP network that connecting endpoint A and endpoint B is interrupted at the time between T3 and T4, endpoint B should receive data #1, #2 and #3, but endpoint A should only receive sack for data #1 and data #2. When the SCTP layer in endpoint A sends COMMUNICATION LOST notification to the ULP layer, SCTP indicates ULP that data #3 are not acknowledged, so if the ULP layer retrieves unacknowledged data and retransmits the data in some other manner, the endpoint B would receives the duplicated data #3, which is also a wrong result. Analyzing these cases, we can find that the key issue is the floating sack packets. The amount of floating sack packets depends on the throughput, the trip time from the receiver to the sender and other reasons. The amount, which is related to the network condition, may be small, middle or large. Because of these floating sack packets, ULP can't get the accurate unacknowledged information via the existing primitives. 3.2. SS7 Adapter over SCTP Problem M3UA specified in [RFC4666] is the most popular SS7 adapter in current network. M3UA can provide service not only to IPSP-IPSP communication but also to Signalling Gateway. The failover mechanism in M3UA layer is "n+k" redundancy model, where "n" ASPs are active and "k" ASPs are inactive. When the active ASP(s) lost communication (association interrupted), the inactive ASPs may takeover the active ASP role. But during the failover procedure the traffic is affected. Some signaling messages that have been sent to the interrupted association are not successfully transported to the receiver, so the failover mechanism M3UA provided is a "lossful" solution. Cui, et al. Expires August 10, 2010 [Page 6] Internet-Draft PS for Sigtran Network Management February 2010 3.3. Application Signalling over SCTP Problem Signalling layer may use the SCTP layer directly without adapter layer, such as S1-MME interface in 3GPP network. In the control plane of 3GPP LTE/EPC network the E-UTRAN accesses EPC network by S1-MME interface, and the protocol stack specified in section 5.1.1.2 of [3GPP-TS-23401] is as below: +-----------+ | +-----------+ | S1-AP | --------------------- | S1-AP | |-----------| | |-----------| | SCTP | --------------------- | SCTP | |-----------| | |-----------| | IP | --------------------- | IP | |-----------| | |-----------| | L2 | --------------------- | L2 | |-----------| | |-----------| | L1 | --------------------- | L1 | +-----------+ | +-----------+ eNodeB S1-MME MME Figure 2 eNodeB/MME Architecture SCTP is adopted as the signaling transport protocol in LTE/EPC network. Section 4.1 of [3GPP-TS-36412] additionally specifies that "Provision of redundancy in the signaling network" is provided by the S1 signaling bearer. But, because SCTP can't support inter- association changeover function now, which means SCTP can only provide inner-association level redundancy mechanism but can not provide end-to-end level redundancy mechanism, 3GPP has to specify in section 7 of [3GPP-TS-36412] that "There shall be only one SCTP association established between one MME and eNB pair". In fact, there is no distributed SCTP TCB implement, so in the actual device, any association MUST be implemented in single host or single board. Also because of the high speed data transmission, TCB synchronization and buffered data reproduction are almost can't be achieved in practice. So the "single board/single association" mechanism can't meet the redundancy requirement of telecommunication network. On the other hand, one association can only provide limited throughput for ULP, because of the hardware capability, so the multi-association solution SHOULD be provided for the telecommunication network and the association changeover mechanism SHOULD also be provided. 4. Routing Management Problem Routing management is a very important functionality in the signaling network. When the source node wants to send a signaling message to Cui, et al. Expires August 10, 2010 [Page 7] Internet-Draft PS for Sigtran Network Management February 2010 the destination node, the source node MUST know some address information of the destination node. The destination may be identified by Signalling Point Code, IP address, User identity or other identifiers. The source node encapsulates the signaling message and transmits the message to the network. In SS7 network the destination of the signaling message may be a node (Layer3 node, Layer3 identifier) or a specific part in a specific node (User part of a node, Layer3 identifier + User Identity). The routing of user part falls into the scope of signaling routing management, too. But current Sigtran specifications don't provide complete solution for some scenarios. [I-D.sigtran-m3ua-ext] and [Liaison-sigtran-to-3gpp] have presented some discussion on this topic. In the basic scenario where IPSEP communicates with No.7 SP, some problems on routing management would appear. For example, IPSP 2 +----------------------------+ +-----+ | | | SG1 |-----\ | | /+-----+ \ | +-------+ | +-------+/ \| +------------+--| User1 | | | 7#SP1 | --| ASP1, ASP2 |\/| | | +-------+\ --| ASP3, ASP4 |/\| | | \+-----+ /| +------------+--| User2 | | | SG2 |------/ | +-------+ | +-----+ | | +----------------------------+ Figure 3 Sigtran Routing Management Issue In this case, SP1 is No.7 Signalling Point, SG1 and SG2 are Signalling Gateways. 7#SP1 may use TDM based or IP based signaling connection to access the SGs. IPSP2 is an IP based No.7 Signalling Point and two User Parts are running in this node. Additionally there are four ASPs connecting to SG1 and SG2 respectively (ASP1 and ASP2 to SG1, ASP3 and ASP4 to SG2). ASP1 and ASP3 both provide service to User1 in IPSP2. ASP2 and ASP4 both provide service to User4 in IPSP2. Cui, et al. Expires August 10, 2010 [Page 8] Internet-Draft PS for Sigtran Network Management February 2010 The routing table in IPSP2 is as below: Source Destination User1 ASP1 Association1 SG1 7#SP1 User1 ASP3 Association3 SG2 7#SP1 User2 ASP2 Association2 SG1 7#SP1 User2 ASP4 Association4 SG2 7#SP1 In this scenario, if Association #1 loses communication to SG1 (too heavy traffic from User1, board crashes down or other reasons) while association #2 is active, SG1 SHOULD detects that IPSP2 is an available node and User1 in IPSP2 is unavailable, SG1 SHOULD send a Destination User Part Unavailable (DUPU) message to 7#SP1 at this moment. However, SG2 and all connections of SG2 work well. 7#SP1 would meet the confusing situation in this scenario. Because MTP and Sigtran don't maintain status information of remote User Part and MTP/Sigtran would send unavailable indication by MTP-STATUS primitive to User Part. But the other path (7#SP1-SG2-IPSP2 User1) for the User Part is active, so the User part of 7#SP1 can't proceed correctly. In other scenarios where multiple IPSPs or No.7 SPs share same Sigtran connections (e.g. M3UA ASPs and SCTP associations), more routing management issues would happen. The existing management solutions on status of destination (i.e., SP status and User Part status) and Routing Context cannot meet the requirements of some telcom environments. The origin of these troubles is that Sigtran splits MTP into multiple units, which are indexed by Routing Context. Traditional SS7 protocol stack consists of User Part and Message Transfer Part, so SP status and User Part status is simple. While Sigtran divides Message Transfer Part, which leads to the SP status and User Part status depend on the status of the sub-units and the combination. Existing mechanism can't deal the "partly-available" status. Cui, et al. Expires August 10, 2010 [Page 9] Internet-Draft PS for Sigtran Network Management February 2010 5. Conclusion and Recommendations The problems about changeover (traffic management) and routing management are introduced in this document. The existing model of application signaling plus Sigtran can not meet the requirements of telecommunication network. So for the IP migration of telecommunication, Sigtran needs some extensions and enhancements. 6. Security Considerations Security considerations regarding traffic management and routing management are needed. The security solution SHOULD fulfill the requirements of all involved nodes and the signaling traffic. 7. IANA Considerations This document doesn't request any assignment from IANA. 8. Acknowledgments TBD. Cui, et al. Expires August 10, 2010 [Page 10] Internet-Draft PS for Sigtran Network Management February 2010 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4666] Morneault, K. and J. Pastor-Balbas, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 4666, September 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 9.2. Informative References [ITU-T-Q.704] ITU-T, Recommendations Q.704, "Signalling network functions and messages", July 1996. [3GPP-TS-23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9)", December 2009. [3GPP-TS-36412] 3GPP, "Evolved Universal Terrestrial Access Network (E-UTRAN); S1 signaling transport (Release 9)", December 2009. [I-D.sigtran-m3ua-ext] Xu, C., Xinyan, L., Hao, Z. And X. Duan, "The proposal of extenting RFC4666 for the M3UA deployment", draft-chen-sigtran-m3ua-ext-00.txt, (expired), November 2007. [Liaison-sigtran-to-3gpp] IETF Sigtran Working Group, Liaison from Sigtran WG to 3GPP, https://datatracker.ietf.org/documents/LIAISON/file552.txt, April 2008. Cui, et al. Expires August 10, 2010 [Page 11] Internet-Draft PS for Sigtran Network Management February 2010 Authors' Addresses Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Xu Chen China Mobile 53A XiBianMennei Ave, XuanWu District, Beijing, China Phone: 86 10 15801696688 3163 Email: chenxu@chinamobile.com Cui, et al. Expires August 10, 2010 [Page 12]