Actions
Feature #2006
openImplement M2PA support
Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
04/10/2017
Due date:
% Done:
0%
Spec Reference:
Description
M2PA is what is used e.g. by Cisco ITP, and I believe also by yate. So we could test SS7 routing/interop with those implementations if we had M2PA support.
Related issues
Updated by laforge 11 months ago
Reading through RFC4165 and taking some random notes:
- two SCTP streams per direction (one for Link Status, another for User Data)
- M2PA retains classic notion of ss7 links + linksets
- 1:1 mapping beteween SCTP association and SS7 link
- same SLC for same link (==association) on both ends
- 1:1 mapping beteween SCTP association and SS7 link
- empty user data messages used to acknowledge receipt in some situations
Message format / protocol elements¶
- 24-bit FSN / BSN sequence numbers in each header
- only one message class with two message types
- User Data
- contains MTP3 message with PRI/SIO/SIF fields
- Link Status
- Alignment / Proving Normal / Proving Emergency / Ready / Processor Outage / Processor Recovered / Busy / Busy Ended / OOS
- not all are sent on Stream0, but some on Stream1
- User Data
- local processor outage
- MTP3 from peer must be buffered
- remote processor outage
- MTP3 messages might also need buffering
- flow control / congestion timers
- criteria how to determine congestion onset is "implementation dependent"
- signaling of SCTP association failures up to MTP3 / take link out of service
- change-over procedure in case of link failure
- message retrieval: obtain all not-yet-transmitted and all sent-but-not-yet-acknowledged messages from the old link
- MTP3 XCO / XCA messages instead of COO/COA due to longer FSM/BSN range
FSMs¶
- MTP2 IAC (Initial Alignment Control) as per Q.703 Figure 4 / Figure 9
- MTP2 LSC (Link State Control) as per Q.703 Figure 3 / Figure 8
- MTP3 SLTC (Signalling Link Test Control) as per Q.707
- MTP3 HMDT (Message Distribution) as per Q.704
Actions