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]