Network Working Group T. Asveren Internet-Draft Ulticom Inc. Expires: June 23, 2006 J. Pastor-Balbas Ericsson Espana S.A. December 20, 2005 M3UA IPSP Procedures draft-asveren-sigtran-m3uaipsp-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 June 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines M3UA IPSP procedures. It is based on IPSP concepts and procedures defined by M3UA specification. Its purpose is to describe M3UA IPSP procedures in an easy-to-follow single document and to provide clarifications for M3UA IPSP procedures. Asveren & Pastor-Balbas Expires June 23, 2006 [Page 1] Internet-Draft M3UA IPSP Procedures December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPSP Functionality . . . . . . . . . . . . . . . . . . . . . . 3 3. IPSP Operation Modes . . . . . . . . . . . . . . . . . . . . . 3 4. IPSP State Machine . . . . . . . . . . . . . . . . . . . . . . 4 5. AS State Machine . . . . . . . . . . . . . . . . . . . . . . . 6 6. IPSP Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Notify Procedures . . . . . . . . . . . . . . . . . . . . 9 6.2. SSNM Procedures . . . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. IPSP M3UA Layer Getting Ready . . . . . . . . . . . . . . 9 7.2. AS Activation . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 11. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Asveren & Pastor-Balbas Expires June 23, 2006 [Page 2] Internet-Draft M3UA IPSP Procedures December 2005 1. Introduction This document defines M3UA IPSP procedures. It is based on IPSP concepts and procedures defined by M3UA. IPSP related procedures are defined together with ASP/SGP procedures in M3UA. This makes it hard to follow IPSP procedures and causes confusion. This document is intended to provide a single source for all IPSP related procedures. Furthermore it also addresses questions/concerns raised about IPSP in the SIGTRAN WG mailing list. 2. IPSP Functionality IPSP funtionality allows two SS7 applications to communicate directly, in a peer-to-peer fashion via an IP network. It should be noted that IPSP refers to a logical functionality, i.e. it can be implemented in different physical entities and may coexist with other M3UA related logical functions, e.g. SGP. Regardless of the physical entity the IPSP functionality is implemented in, IPSP functionality communicates strictly only with peer IPSPs, e.g. in an entity where MTP3 and IPSP functionalities coexist, IPSP does not interact with MTP3 in any way. 3. IPSP Operation Modes There are two IPSP operation modes: Single Exchange(SE) Mode: This mode allows peer-to-peer communication between two IPSPs with a single exchange of ASPAC/ASPAC-ACK. Each RK defines the traffic at both ends of the communication path, thus a RK MUST consist of OPC and DPC at a minimum. This mode of IPSP operation is mandatory and MUST be supported by all IPSPs. Double Exchange(DE) Mode: This mode simulates peer-to-peer communication between two IPSPs with a pair of ASPAC/ASPAC-ACK exchanges, one for each direction. Each path is used unidirectionally. Conceptually an DE-IPSP can be considered as a coupled ASP and SGP functionality pair. RKs define traffic only at one end, for that reason two RKs are necessary for communication between two IPSPs. This mode is optional. The procedures and state machine to be followed for DE-IPSP is exactly the same like the ones described for ASP and SGP described in M3UA, for that reason following sections of this document will focus only on SE-IPSPs and the term IPSP will be used to refer to SE-IPSP. Asveren & Pastor-Balbas Expires June 23, 2006 [Page 3] Internet-Draft M3UA IPSP Procedures December 2005 +-------------+ +--------------+ | | | | | IPSP1 | | IPSP2 | | | | | | +------+ | | +------+ | | | ASPF |----------->------------------| SGPF | | | +------+ | | +------+ | | +------+ | | +------+ | | | SGPF |----------<-------------------| ASPF | | | +------+ | | +------+ | | | | | +-------------+ +--------------+ Figure 1: DE-IPSP Functional Model It should be noted that Figure1 is for clarification purposes only and does not impose any specific IPSP implementation. 4. IPSP State Machine Each IPSP maintains a state machine to keep track of the peer IPSP states . The state machine logic is shown in two figures for being able to follow transitions easier. The state machine diagram is only a functional representation and does not impose any specific implementation. As long as implementations provide the same behavior in terms of messages sent/received, they can choose to implement IPSP state machine functionaly in any way they want. Certin events are omitted from state machine diagrams for simplicity reasons: o SCTP CTI/SCTP RI events always cause a transition to DOWN state. o All events except SCTP CTI/SCTP RI, which are not shown for a state cause the state machine to stay in the same state and generate ERR(Unexpected Message) o ERR stand for ERROR(Management Blocking) message. o "no answer" stands for the case where no answer has been received for a sent message possibly after some retries. To resend messages, when no corresponding answer message received and the period of such resends is implementation dependent. If a state transition includes also sending a message to the peer, this message is shown in "[]". Asveren & Pastor-Balbas Expires June 23, 2006 [Page 4] Internet-Draft M3UA IPSP Procedures December 2005 +---------------+ | |----ASPUP-ACK-------+ | ASPUP | received | | Sent | | | |----ASPUP------+ | +---------------+ received | | ^ | | [ASPUP-ACK] V V | | | +---------------+ ASPUP | no | |-----+ sent | answer | UP | ASPUP-ACK recv. | | | | | ASPUP[ASPUP-ACK] | ERR | | |<----+ recv. | received | +---------------+ | | | ^ | | | | | | | |ASPDN sent | V V ASPUP | V +---------------+ recv. | +---------------+ | | [ASPUP-ACK] | | | | DOWN |---------+ | | ASPDN | | |<--------------+ | Sent | | |<------no reply----| | +---------------+ +---------------+ | ^ ^ | | | | | | | +-------------------------+ +-------+ ASPDN-ACK received ASPUP recv. [ERR] Figure 2: IPSP State Machine -1- Asveren & Pastor-Balbas Expires June 23, 2006 [Page 5] Internet-Draft M3UA IPSP Procedures December 2005 +-------------+ +--------no answer---------------->| | | | DOWN | +---------------+ | |<-+ | |----ASPAC-ACK-------+ | | | | ASPAC | received | +-------------+ | | Sent | | | | |----ASPAC------+ | | +---------------+ received | | | ^ | [ASPAC-ACK] V V | | | +---------------+ | ASPAC | | |-----+ | sent | | ACTIVE | ASPAC-ACK recv. | | | | | ASPAC[ASPAC-ACK]| | ERR | |<----+ recv. | | received +---------------+ | | | ^ | | | | | | | |ASPIA sent | | V ASPAC | V no +---------------+ recv. | +---------------+ answer | | [ASPAC-ACK] | | | | | UP |---------+ | | ASPIA |-----+ | |<--------------+ | Sent | | | | | +---------------+ +---------------+ | ^ ^ | | | | | | | +-------------------------+ +-------+ ASPIA-ACK received ASPAC recv. [ERR] Figure 3: IPSP State Machine -2- 5. AS State Machine The state of peer AS is kept in the M3UA layer on the IPSPs. For IPSP, AS state changes based on the state of both IPSP sides regarding the peer AS. Each side notifies the other one about its own AS state view with NTFY messages. An AS is considered ACTIVE, when the number of required ACTIVE IPSPs is satisfied both by local and remote sides. For the generic case of n+k traffic mode, this corresponds to: - n IPSPs are in ACTIVE state - NTFY(Active) has been received from peer IPSPs. This ensures that Asveren & Pastor-Balbas Expires June 23, 2006 [Page 6] Internet-Draft M3UA IPSP Procedures December 2005 number of required ACTIVE IPSPS criteria has been satisfied on the remote side by enough number of IPSPs. In the AS state machine, the number of ACTIVE peer IPSPs is shown with #I_A, and the number of NTFY(Active) messages received from peer IPSPs is shown with #N_A. When AS switches from DOWN to INACTIVE state, both #I_A and #N_A are 0. Whenever an IPSP switched to ACTIVE state, #I_A is increased by one. Whenever an IPSP switches from ACTIVE to another state, #I_A is decreased by one. Whenever a NTFY(Active) is received from an IPSP, #N_A is increased by one. Whenever a NTFY indicating a new AS state except ACTIVE is received, #N_A is decreased by one. The state machine diagram is only a functional representation and does not impose any specific implementation. As long as implementations provide the same behavior in terms of messages sent/ received, they can choose to implement AS state machine functionaly in any way they want. If a state transition includes also sending a message to the peer, this message is shown in "[]". The following states are defined for AS state machine(it is assumed that the local end uses n+k and the remote end uses m+l configuration): DOWN: The Application Server is unavailable. This state implies that all IPSPs for this AS are in DOWN state. Initially an AS is in this state. INACTIVE: At least one IPSP part of the AS is in INACTIVE state and number of ACTIVE IPSP is less than n. In this state, AS is not ready yet to process traffic. HALF ACTIVE LOCAL: The number of ACTIVE IPSP is equal or more than n, i.e the remote AS is ready to process traffic, but less than n peer IPSPs declared that they have enough peer IPSPs in ACTIVE state. HALF ACTIVE REMOTE: n peer IPSPs declared that they have enough peer IPSPs in ACTIVE state but the number of ACTIVE IPSPs from local point of view is less than n. ACTIVE: Both ends have enough IPSP ACTIVE to send/receive traffic. AS PENDING: An ACTIVE IPSP transitions to INACTIVE or DOWN and it was the last IPSP in ACTIVE state. In this state, a recovery timer T(r) SHOULD be started and all outgoing messages should be buffered. If Asveren & Pastor-Balbas Expires June 23, 2006 [Page 7] Internet-Draft M3UA IPSP Procedures December 2005 an IPSP becomes ACTIVE before T(r) expiry, all buffered messages are sent to this IPSP and AS moves to ACTIVE state. If no IPSP becomes ACTIVE before T(r) expiry, AS changes to INACTIVE state. +----------+ one IPSP | |--------------------------- becomes ACTIVE | PENDING | Last IPSP becomes [NTFY(Active)] | | INACTIVE | | |<---------[NTFY(Pending)]-----+ | +----------+ | | | +----------+ | | Tr | HALF | | | expires | ACTIVE | | | | +---#N_A < n---| REMOTE | | | | | | | | | | | +----------+ | | | | ^ | | | V V | #I_A = n | | +----------+ | [NTFY(Active)] | V | |----#N_A = n-+ | +----------+ | INACTIVE | +------>| | | | | ACTIVE | | |---#I_A = n--+ | | +----------+ [NTFY(Active)] +------>| | | ^ ^ | | +----------+ Last IPSP | | | #N_A = n becomes | | | | DOWN | | V | | First | +----------+ | IPSP +---------+ | HALF | | becomes | | ACTIVE | | INACTIVE | | LOCAL | | [NTFY(Inactive)] | | | V | | +----------+ +----------+ | | | | +-#I_A < n | DOWN | [NTFY(Inactive)] | | | | +----------+ Figure 4: AS State Machine Asveren & Pastor-Balbas Expires June 23, 2006 [Page 8] Internet-Draft M3UA IPSP Procedures December 2005 6. IPSP Procedures 6.1. Notify Procedures In IPSP communication, NTFY messages are used not only for advisory purposes but to guide AS state transitions as well. This need arises due to the n+k configurations where n has a different value on each end. Although it is theoretically not necessary for a 1+k solution, for consistency purposes and to prevent interoperability problems, the same method is used for 1+k case as well. A NTFY message is sent to all IPSP, which are not in DOWN state and which are configured to handle traffic for the corresponding AS. A NTFY messages indicating current AS states are sent to an IPSP, which switches from DOWN to INACTIVE state as well, for all of the AS, for which this IPSP is configured for. 6.2. SSNM Procedures IPSPs do not interact with conventional SS7 entities on layer3, i.e. they do not interact with any MTP3 instance neither directly nor indirectly. Any interaction with conventional SS7 nodes requires interworking on SS7 User Part/Application layer. SSNM is used in M3UA to interwork with MTP3 network management, and thus not used by IPSPs with SCON being the only exception. SCON is used by an IPSP to inform peer IPSPs about its congestion status. It is expected to have a new ASPTM message defined for that purpose shortly and when this new ASPTM message is defined, it MUST be used to convey congestion information instead of SCON. 7. Examples In all of the examples, the following configuration is assumed: IPSP1 and IPSP2 are serving AS1 and IPSP3 and IPSP4 are serving AS2. RC1 is used as routing context for RK1, which identifies the traffic range for the traffic between AS1 and AS2. For IPSP1/IPSP2 n=2 and for IPSP3/IPSP3 n=1 is assumed as n+k traffic mode parameter. . 7.1. IPSP M3UA Layer Getting Ready In this scenario, it is assumed that SCTP associations between IPSPs are already established. Asveren & Pastor-Balbas Expires June 23, 2006 [Page 9] Internet-Draft M3UA IPSP Procedures December 2005 IPSP1 IPSP2 IPSP3 IPSP4 | | | | |-----ASPUP--------->| | | | | | |<---ASPUP-ACK-------| | | | | | |--NTFY(Inactive)--->| | | | | | |<--NTFY(Inactive)---| | | | | | |----ASPUP- ----ASPUP------| | | \_/_ | | | | / \ | | |<---------- ------------>| | | | | |------ASPUP-ACK------------>| | | | | |<--------------ASPUP-ACK----| | | | | |-------NTFY(Inactive)------>| | | | | |<------NTFY(Inactive)-------| | | | | |<-----ASPUP---------| | | | | | |----ASPUP-ACK------>| | | | | | |----NTFY(Inactive)->| | | | | | |<---NTFY(Inactive)--| | | | | | |---------ASPUP------------->| | | | | |<--------ASPUP-ACK----------| | | | | |<------NTFY(Inactive)-------| | | | | |-------NTFY(Inactive)------>| | | | | Figure 5: IPSPs Declaring Readiness 7.2. AS Activation In this scenario, it is assumed that IPSPs already declared readiness of their M3UA layers by exchanging ASPUP/ASPUP-ACK. Asveren & Pastor-Balbas Expires June 23, 2006 [Page 10] Internet-Draft M3UA IPSP Procedures December 2005 IPSP1 IPSP2 IPSP3 IPSP4 | | | | |-----ASPAC--------->| | | | | | |<----ASPAC-ACK----- | | #I_A=1 | #I_A=1 | | | | | | |<--NTFY-----| | | | (Active) | | | #N_A=1 | | | | | | |<--NTFY(Active)-----| | #N_A=1 | | | | | | | | |--ASPAC---->| | | | | | | |<-ASPAC-ACK-| | | #I_A=1 #I_A=2 | | | | | |--------ASPAC-------------->| | | | | |<------ASPAC-ACK------------| #I_A=2 | | #I-A=1 | | | | | |<----NTFY(Active)-- | | #N_A=2 | | | | | | |<------NTFY(Active)-+------ | #N_A=2 | | | AS | | | Active | | | |----NTFY(Active)--->| | | | #N_A=1 | | | AS | | | Active | | | | | |-------NTFY(Active)-------->| | | | #N_A=1 | | | AS | | | Active | | | | | |-----ASPAC--------->| | | | | | |<-----ASPAC-ACK-----| | #I_A=2 | #I_A=2 | AS | | | Active | | | |--NTFY----->| | Asveren & Pastor-Balbas Expires June 23, 2006 [Page 11] Internet-Draft M3UA IPSP Procedures December 2005 | | (Active) | | | | #N_A=2 | | | | | | |---NTFY(Active)---->| | | | #N_A=2 | | | | Figure 6: IPSPs Getting Active 8. IANA Considerations This document does not require any actions from IANA. 9. Security Considerations 10. Acknowledgments 11. 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. Asveren & Pastor-Balbas Expires June 23, 2006 [Page 12] Internet-Draft M3UA IPSP Procedures December 2005 Authors' Addresses Tolga Asveren Ulticom Inc. 1020 Briggs Road Mount Laurel, NJ, 08054 USA Email: asveren@ulticom.com Javier Pastor-Balbas Ericsson Espana S.A. C/ Retamal 28045 Madrid Spain Email: j.javier.pastor@ericsson.com Asveren & Pastor-Balbas Expires June 23, 2006 [Page 13] Internet-Draft M3UA IPSP Procedures December 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 & Pastor-Balbas Expires June 23, 2006 [Page 14]