Internet DRAFT - draft-asveren-sigtran-m3uacons
draft-asveren-sigtran-m3uacons
Network Working Group T. Asveren
Internet-Draft Ulticom Inc.
Expires: May 26, 2006 H. Lincoln
Comverse Inc.
M. Tuexen
Muenster Univ. of Applied Sciences
November 22, 2005
M3UA Deployment Considerations
draft-asveren-sigtran-m3uacons-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.
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 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides some considerations regarding the deployment
of M3UA protocol, which were originally brought up at the SIGTRAN
mailing list. Certain parts of the discussions in this document are
applicable to other SIGTRAN protocols as well.
Asveren, et al. Expires May 26, 2006 [Page 1]
Internet-Draft M3UA Deployment Considerations November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. M3UA Redundancy Model . . . . . . . . . . . . . . . . . . . . 3
2.1. M3UA Redundancy Architecture Overview . . . . . . . . . . 3
2.2. Services expected from SCTP . . . . . . . . . . . . . . . 3
2.3. Comparison with MTP3 redundancy mechanisms . . . . . . . . 3
2.3.1. Host Redundancy . . . . . . . . . . . . . . . . . . . 3
2.3.2. Link Redundancy . . . . . . . . . . . . . . . . . . . 4
2.3.3. Procedures For Failover Between Hosts . . . . . . . . 5
3. Operational Issues and Recommendations . . . . . . . . . . . . 5
3.1. Issues related with endpoint behavior . . . . . . . . . . 5
3.2. Issues with IP network QoS . . . . . . . . . . . . . . . . 6
3.3. Lack of SCTP Multihoming Support . . . . . . . . . . . . . 7
4. Recommendations for propriatery/optional procedures . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Asveren, et al. Expires May 26, 2006 [Page 2]
Internet-Draft M3UA Deployment Considerations November 2005
1. Introduction
This document provides some considerations regarding the deployment
of M3UA [1], which were originally brought up at the SIGTRAN mailing
list.
2. M3UA Redundancy Model
Because most deployment considerations are closely tied with
redundancy, this section provides an overview of redundancy provided
by M3UA protocol.
2.1. M3UA Redundancy Architecture Overview
M3UA utilizes multiple mechanisms to provide redundancy for different
failure scenarios.
M3UA uses the concept of ASP and SGP to enable distributed message
processing by multiple entities. An AS can be served by multiple
ASPs and similarly one SG can consist of multiple SGPs. This
mechanism allows redirecting traffic from a failed peer to another
one to provide host redundancy.
2.2. Services expected from SCTP
M3UA relies on certain SCTP [2] mechanisms to increase reliability of
the communication between two peers. SCTP provides reliable and
ordered delivery of messages between two peers. Furthermore, SCTP
provides network interface/link/network redundancy as well with its
multihoming feature. Multihoming allows SCTP to use multiple network
interface cards (NICs) and multiple networks to prevent single point
of failures during message transport.
2.3. Comparison with MTP3 redundancy mechanisms
Considering that M3UA is going to be deployed in SS7 networks
replacing MTP3[4] for certain scenarios, it has to provide the same
level of reliability. This section discusses redundancy mechanisms
defined by those two protocols.
2.3.1. Host Redundancy
MTP3 does not provide any mechanism directly providing host
redundancy for a signaling point. On the other hand, distributing
links of a signaling point on different hosts is a mechanism often
used in the industry to provide host redundancy for signaling points.
Asveren, et al. Expires May 26, 2006 [Page 3]
Internet-Draft M3UA Deployment Considerations November 2005
+--------------+
| Signaling |
| Point B |
+----------+ | ......... |
|Signaling +--------+--. Host 1. |
|Point A | | ......... |
| | | ......... |
| +--------+--. Host 2. |
+----------+ | ......... |
| |
+--------------+
Figure 1: Providing host redundancy for a signaling point
M3UA allows the distribution of elements -ASPs and SGPs- of a
signaling point to multiple hosts -ASPs and SGPs- to provide host
redundancy.
2.3.2. Link Redundancy
MTP3 allows using multiple links between two signaling points. If a
link fails, transfer of messages can continue over the other links
between two signaling points. MTP3 also defines changeover procedure
to perform failover among links without message loss. This mechanism
relies on the receiver side sending the sequence number of the last
received message to the sender, thus is effective only if the
receiver MTP3 and MTP2 is alive and can fetch and send the required
sequence number to the sender, i.e. is not effective in case of host
failures. A distributed MTP2 solution could minimize/eliminate
message loss during host failure, but is not a commonly utilized
technique due to the complexity and heavy processing associated with
it.
M3UA does not have the concept of multiple links between two hosts
and uses a single SCTP association between them. On the other hand,
SCTP uses multiple paths for a single association thanks to the
multihoming feature. This eliminates single point of failures for
NIC and network. Conceptually each path of an association
corresponds to a MTP2 link. When one path fails, SCTP continues
message transfer on another path of the same association, where this
failover happens without any message loss or missequencing. This
mechanism relies on the control of multiple network interfaces by a
single SCTP instance and therefore ineffective to handle host failure
cases, unless a distributed SCTP implementation is used. Distributed
SCTP implementations are not common due to the complexity and heavy
processing associated with them.
Asveren, et al. Expires May 26, 2006 [Page 4]
Internet-Draft M3UA Deployment Considerations November 2005
+--------------+ ( ) +--------------+
| SGP1 | ( ) | ASP1 |
|+--------+ | +--(Ntwk 1 )--+ | +--------+|
|| SCTP | | | ( ) | | | SCTP ||
|| assoc1 | | | ( ) | | | assoc2 ||
||Path1....NIC1+----+ +---+NIC1...Path1 ||
|| | | | | ||
||Path2....NIC2+----+ ( ) +---+NIC2...Path2 ||
|| | | | ( ) | | | ||
|+--------+ | +--(Ntwk 2 )--+ | +--------+|
+--------------+ ( ) +--------------+
( )
Figure 2: A dualhomed SCTP association
2.3.3. Procedures For Failover Between Hosts
MTP3 defines the time-controlled diversion (TCD), time-controlled
changeover (TCO) procedure to be used when the message routing
decisions on a signaling point change because the reachability status
of a neighbor changes. The purpose of that procedure is to reduce
the possibility of message missequencing.
M3UA does not define any procedures to be followed when traffic is
diverted from a failed host to an alternate one, but there is nothing
preventing implementations to imitate MTP3 procedures for such cases
because no interaction/coordination is necessary with the peer to
implement them. M3UA entities SHOULD implement mechanism similar to
MTP3 TCD/TCO procedures to minimize possibility of message
missequencing when traffic divertion from one peer to another one
happens.
3. Operational Issues and Recommendations
3.1. Issues related with endpoint behavior
It has been observed that misbehaving SCTP implementations may cause
their peers to stop sending traffic for reasons like receiver window
decreasing to a level, which prevents sending new messages. This may
happen if the misbehaving SCTP instance does not send SACK messages
properly.
The following approaches are RECOMMENDED to deal with such problems:
a) To fix the misbehaving SCTP implementation
b) To drop SCTP association when there is evidence of a misbehaving
Asveren, et al. Expires May 26, 2006 [Page 5]
Internet-Draft M3UA Deployment Considerations November 2005
peer. To determine when a peer is behaving is implementation
dependent and could be done by observing certain SCTP state
variables, e.g. receiver window size, by processing SCTP
notifications e.g. time out to send, by exchanging M3UA BEAT/BEAT-ACK
messages with the peer.
3.2. Issues with IP network QoS
To meet the expectations for SS7 traffic, the underlying IP network
should have certain QoS level if M3UA is utilized. On the other
hand, it has been observed that some deployments are facing problems
if QoS level is not always as required. Actually, M3UA itself is
QoS-agnostic, i.e. there are no procedures in M3UA measuring the
network performance and taking action according to the results. On
the other hand, SCTP declares paths/associations failed according to
the acknowledgements received for sent packets.
Most concerns related with IP network QoS are about SCTP declaring an
association failed, even if the peer host is not down. M3UA
delegates network redundancy to SCTP and thus considers an SCTP
association failure equivalent to peer host failure, i.e. M3UA
assumes that by making use of multiple networks and multiple NICs,
SCTP eliminates all single point of failures on network level. That
assumption is the reason for M3UA not to have a procedure similar to
MTP3 changeover procedure. It has been observed that for some
deployments this assumptions do not hold. The following solutions
are RECOMMENDED to deal with such cases:
a) Increasing QoS of the IP network
If the problems in IP network causing SCTP associations to fail, e.g.
high latency, high packet drop rate, are observed frequently the most
effective way of dealing with them is upgrading IP infrastructure to
ensure the desired QoS. It should be noted that frequent problems
with latency are problems for SS7 applications as well.
b) Adjusting SCTP parameters
If the QoS of the IP network is satisfactory for most of the times
but does cause SCTP associations to fail rarely, SCTP protocol
parameters can be adjusted to prevent such dropped associations.
This can be done in several different ways like increasing
Association.Max.Retrans, Path.Max.Retrans values, increasing RTO.max.
It should be noted that adjusting SCTP parameters can increase the
time necessary to drop the association when the peer is down.
c) Using new procedures If there is no other acceptable solution, new
procedures may be utilized. Such mechanisms could be proprietary or
could be defined as optional extension to M3UA protocol.
Asveren, et al. Expires May 26, 2006 [Page 6]
Internet-Draft M3UA Deployment Considerations November 2005
3.3. Lack of SCTP Multihoming Support
Multihoming feature of SCTP is a key element to provide NIC and
network redundancy for M3UA entities. M3UA entities SHOULD use SCTP
as transport protocol and SHOULD utilize multihoming feature of SCTP.
For cases where SCTP multihoming support is not available the
following are recommended:
a) Implementing multihoming feature for SCTP.
b) Utilizing redundancy mechanisms in IP network/LAN level.
1. All IP routing protocols allow redundant network design to
certain degree. A properly engineered IP network could provide a
reasonable degree of redundancy for the core network by making
use of such mechanisms.
2. MPLS could be used in the core network to have fast failover
times, e.g. MPLS Fast Reroute mechanism allows failover times in
the order of tens of milliseconds.
3. Link aggregation techniques, e.g. IEEE 802.3ad, can be used to
provide link/interface redundancy both for LAN and for the core
network.
4. Fiber Distributed Data Interface(FDDI) could be used to provide
link redundancy for LAN. Similarly SONET Automatic Protection
Switch could provide link redundancy for core network elements.
Wave-division multiplexing (WDM) with optical layer protection
feature could be used as well, to achieve the same result on
physical layer.
5. Virtual Router Redundancy Protocol(VRPP) could be used to provide
host redundancy for routers in the LAN.
6. Host running the SIGTRAN protocol stacks could be configured as a
router. This would allow utilizing multiple routers to access
the core network and SIGTRAN host can send IP packets to the
appropriate router based on configuration and failover
conditions.
c) To use proprietary or optional M3UA procedures to prevent/minimize
message loss due to network failures. Buffer updating mechanism of
MTP3 changeover procedure could be used as a model while designing
such M3UA procedures.
Asveren, et al. Expires May 26, 2006 [Page 7]
Internet-Draft M3UA Deployment Considerations November 2005
4. Recommendations for propriatery/optional procedures
It is important for the proprietary/optional extensions for M3UA to
be consistent with the general architecture of the protocol. This
will allow easier adaptation of solutions and will prevent
inconsistencies with other enhancements.
Extensions to M3UA SHOULD honor the functional separation between
M3UA and SCTP, i.e. all transport services and reliable and ordered
delivery of messages has to be performed by SCTP.
5. IANA Considerations
This document does not require any actions from IANA.
6. Security Considerations
This document provides only some considerations regarding M3UA
deployment and therefore the considerations given in RFC3332 [1] and
RFC3788 [3] do apply.
7. Acknowledgments
The authors wish to thank Brian Bidulock for his invaluable comments.
8. Normative References
[1] Sidebottom, G., Morneault, K., and J. Pastor-Balbas, "Signaling
System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
Layer (M3UA)", RFC 3332, September 2002.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN) Protocols",
RFC 3788, June 2004.
[4] ITU, "Q.704 (07/96) Specification of Signaling System No. 7 -
Message Transfer part".
Asveren, et al. Expires May 26, 2006 [Page 8]
Internet-Draft M3UA Deployment Considerations November 2005
Authors' Addresses
Tolga Asveren
Ulticom Inc.
1020 Briggs Road
Mount Laurel ,NJ, 08054
USA.
Email: asveren@ulticom.com
Haresign Lincoln
Comverse Inc.
1015 Briggs Road
Mount Laurel, NJ, 08054
USA.
Email: Lincoln.Haresign@comverse.com
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Asveren, et al. Expires May 26, 2006 [Page 9]
Internet-Draft M3UA Deployment Considerations November 2005
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 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 Internet Society (2005). 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.
Asveren, et al. Expires May 26, 2006 [Page 10]
