Internet DRAFT - draft-asveren-sigtran-m3uaipsp
draft-asveren-sigtran-m3uaipsp
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]
