One document matched: draft-cui-tsvwg-snm-ps-00.txt
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: </ T3|<-----< |<--------------< | |
| broken<------| /| | |
| T4|<-----< | | |
| | | | |
| | | | |
| LOST | | | LOST |
|<-------------| | 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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:29:34 |