draft-ietf-sigtran-m2pa-00.txt   draft-ietf-sigtran-m2pa-01.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
IPmobile IPmobile
Malleswar Kalla Malleswar Kalla
Telcordia Telcordia
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Expires May 2001 November 8, 2000 Expires May 2001 November 22, 2000
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-00.txt> <draft-ietf-sigtran-m2pa-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 12 skipping to change at page 3, line 12
using the SS7 Message Transfer Part (MTP) Layer 2 to provide transport using the SS7 Message Transfer Part (MTP) Layer 2 to provide transport
of MTP Layer 3 signaling messages. of MTP Layer 3 signaling messages.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction............................................. 4 1. Introduction............................................. 4
1.1 Scope................................................. 4 1.1 Scope................................................. 4
1.2 Terminology........................................... 4 1.2 Terminology........................................... 4
1.3 Abbreviations......................................... 5 1.3 Abbreviations......................................... 5
1.4 Conventions........................................... 5 1.4 Conventions........................................... 5
1.5 Signaling Transport Architecture...................... 5 1.5 Signaling Transport Architecture...................... 6
1.6 Services Provided by M2PA............................. 7 1.6 Services Provided by M2PA............................. 7
1.7 Functions Provided by M2PA............................ 8 1.7 Functions Provided by M2PA............................ 8
1.8 Definition of the M2PA Boundaries..................... 9 1.8 Definition of the M2PA Boundaries..................... 9
2. Protocol Elements........................................ 9 1.9 Differences Between M2PA and M2UA.....................10
2.1 Common Message Header................................. 9 2. Protocol Elements........................................12
2.2 M2PA Messages.........................................10 2.1 Common Message Header.................................12
3. Procedures...............................................11 2.2 M2PA Messages.........................................13
3.1 Procedures to Support MTP2 Features...................11 3. M2PA Link States.........................................15
3.2 Procedures to Support the MTP3/MTP2 Interface.........15 4. Procedures...............................................17
4. Examples of M2PA Procedures..............................19 4.1 Procedures to Support MTP2 Features...................17
4.1 Link Initialization (Alignment).......................19 4.2 Procedures to Support the MTP3/MTP2 Interface.........21
4.2 Message Transmission and Reception....................20 5. Examples of M2PA Procedures..............................24
4.3 Link Status Indication................................21 5.1 Link Initialization (Alignment).......................24
4.4 Link Status Message (Processor Outage)................22 5.2 Message Transmission and Reception....................26
4.5 Congestion Notification to Upper layer................23 5.3 Link Status Indication................................26
4.6 Link Deactivation.....................................23 5.4 Link Status Message (Processor Outage)................27
4.7 Link Changeover.......................................24 5.5 Congestion Notification to Upper layer................28
5. Security.................................................26 5.6 Link Deactivation.....................................29
6. IANA Considerations......................................26 5.7 Link Changeover.......................................30
7. Acknowledgements.........................................26 6. Security.................................................32
8. References...............................................27 7. IANA Considerations......................................32
9. Author's Addresses.......................................28 8. Acknowledgements.........................................32
9. References...............................................33
10. Author's Addresses.......................................34
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signaling protocol There is a need for Switched Circuit Network (SCN) signaling protocol
delivery over an IP network. This includes delivery from a Signalling delivery over an IP network. This includes delivery from a Signalling
Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling
Point, as described in the Framework Architecture for Signalling Point, as described in the Framework Architecture for Signalling
Transport [1]. This could allow for convergence of some signaling Transport [1]. This could allow for convergence of some signaling
skipping to change at page 5, line 26 skipping to change at page 5, line 26
association provides the transport for MTP3 protocol data units and association provides the transport for MTP3 protocol data units and
M2PA adaptation layer peer messages. M2PA adaptation layer peer messages.
Network Byte Order - Most significant byte first, also known as "Big Network Byte Order - Most significant byte first, also known as "Big
Endian". Endian".
Stream - A stream refers to a SCTP stream [5]. Stream - A stream refers to a SCTP stream [5].
1.3 Abbreviations 1.3 Abbreviations
BSNT - Backward Sequence Number to be Transmitted
FSNC - Forward Sequence Number of last message accepted by
remote level 2
MSU - Message Signal Unit
SCN - Switched Circuit Network SCN - Switched Circuit Network
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
SIF - Signaling Information Field
SIO - Service Information Octet
SLC - Signaling Link Code SLC - Signaling Link Code
SS7 - Signaling System 7 SS7 - Signaling System 7
SSN - Stream Sequence Number SSN - Stream Sequence Number
1.4 Conventions 1.4 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
skipping to change at page 8, line 40 skipping to change at page 8, line 34
purpose. purpose.
FISUs are sent when no other signal units are waiting to be sent. This FISUs are sent when no other signal units are waiting to be sent. This
purpose is served by the heartbeat messages in SCTP. FISUs also carry purpose is served by the heartbeat messages in SCTP. FISUs also carry
acknowledgment of messages. This function is performed by acknowledgment of messages. This function is performed by
SCTP. Therefore, it is unnecessary for M2PA to provide a protocol unit SCTP. Therefore, it is unnecessary for M2PA to provide a protocol unit
like the FISU. like the FISU.
1.7 Functions Provided by M2PA 1.7 Functions Provided by M2PA
1.7.1 Mapping 1.7.1 Support of MTP3/MTP2 Primitives
M2PA receives the primitives sent from MTP3 to its lower layer. M2PA
processes these primitives or maps them to appropriate primitives at
the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like
those used in the MTP3/MTP2 interface.
1.7.2 MTP2 Functionality
M2PA provides MTP2 functionality that is not provided by SCTP. This
includes
- Data retrieval to support the MTP3 changeover procedure
- Reporting of link status changes to MTP3
- Processor outage procedure
- Link alignment procedure
1.7.3 Mapping of SS7 and IP Entities
For each IP link, the M2PA layer must maintain a map of the SS7 link For each IP link, the M2PA layer must maintain a map of the SS7 link
to its SCTP association and its corresponding IP destination. to its SCTP association and its corresponding IP destination.
1.7.2 SCTP Stream Management 1.7.3 SCTP Stream Management
SCTP allows a user-specified number of streams to be opened during the SCTP allows a user-specified number of streams to be opened during the
initialization. It is the responsibility of the M2PA layer to ensure initialization. It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association. proper management of the streams allowed within each association.
1.7.3 Retention of MTP3 in the SS7 Network 1.7.4 Retention of MTP3 in the SS7 Network
M2PA allows MTP3 to perform all of its Message Handling and Network M2PA allows MTP3 to perform all of its Message Handling and Network
Management functions with IPSPs as with other SS7 nodes. Management functions with IPSPs as with other SS7 nodes.
1.8 Definition of the M2PA Boundaries 1.8 Definition of the M2PA Boundaries
1.8.1 Definition of the M2PA / MTP Level 3 boundary 1.8.1 Definition of the M2PA / MTP Level 3 boundary
The upper layer primitives provided by M2PA are the same as those The upper layer primitives provided by M2PA are the same as those
provided by MTP2 to MTP3 [2]. provided by MTP2 to MTP3. Following is a list of these primitives.
Primitives sent from MTP3 to M2PA:
Data Request - Used to send a Data Message for transmission.
Start Request - Used to establish a link.
Stop Request - Used to release a link.
Retrieve BSNT Request - Request the BSNT for the changeover procedure.
Retrieval Request and FSNC - Request retrieval of unacknowledged and
unsent messages. This request includes the FSNC received from the
remote end.
Flush Buffers Request - Requests that all transmit and receive
buffers be emptied.
Continue Request - Requests that processing resume after a processor
outage.
Emergency Request - This is ignored by M2PA.
Emergency Ceases Request - This is ignored by M2PA.
Primitives sent from M2PA to MTP3:
Data Indication - Used to deliver received Data Message to MTP3.
Congestion Indication - Indicates change in congestion level. The
indication includes the congestion level, if the protocol is using the
optional congestion levels.
In Service Indication - Indicates that the link is in service.
Out of Service Indication - Indicates that the link is out of service.
Retrieved Messages Indication - Indicates delivery of unacknowledged
and unsent messages.
Retrieval Complete Indication - Indicates that delivery of
unacknowledged and unsent messages is complete.
BSNT Confirm - Replies to the BSNT Request. The confirmation includes
the BSNT.
BSNT Not Retrievable Confirm - Replies to the BSNT Request when the
BSNT cannot be determined.
Remote Processor Outage Indication - Indicates processor outage at
remote end.
Remote Processor Recovered Indication - Indicates recovery from
processor outage at remote end.
1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP 1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP
The upper layer primitives provided by SCTP are described in Reference The upper layer primitives provided by SCTP are described in Reference
[5] Section 10 "Interface with Upper Layer". [5] Section 10 "Interface with Upper Layer".
1.9 Differences Between M2PA and M2UA
The MTP2 User Adaptation Layer (M2UA) [6] also adapts the MTP3 layer
to the SCTP/IP stack. It does so through a backhauling architecture
[4]. This section intends to clarify some of the differences between
the M2PA and M2UA approaches.
A possible M2PA architecture is shown in Figure 3. Here the IPSP's
MTP3 uses its underlying M2PA as a replacement for
MTP2. Commmunication between the two layers MTP3/M2PA is defined by
the same primitives as in SS7 MTP3/MTP2. M2PA performs functions
similar to MTP2.
A comparable architecture for M2UA is shown in Figure 4. In M2UA, the
MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer. In SS7,
commmunication between the MTP3 and MTP2 layers is defined by
primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA
messages and sent over the IP connection.
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
+------+ +-------------+ +------+
| SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+
| | | | IP | | IP |
+------+ +------+------+ +------+
Figure 3: M2PA in IP Signaling Gateway
******** SS7 *************** IP ********
* SEP *--------* SG *--------* MGC *
******** *************** ********
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| MTP3 | (NIF) | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2UA | | M2UA |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+
| | | | IP | | IP |
+------+ +------+------+ +------+
NIF - Nodal Interworking Function
Figure 4: M2UA in IP Signaling Gateway
M2PA and M2UA are similar in that:
a. Both transport MTP3 data messages.
b. Both present an MTP2 upper interface to MTP3.
Differences between M2PA and M2UA include:
a. M2PA: IPSP processes MTP3-to-MTP2 primitives.
M2UA: MGC transports MTP3-to-MTP2 primitives to SG's MTP2
(via the NIF) for processing.
b. M2PA: SG-IPSP connection is an SS7 link.
M2UA: SG-MGC connection is not an SS7 link.
c. M2PA: SG is an SS7 node with a point code.
M2UA: SG is not an SS7 node and has no point code.
d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
M2UA: SG does not have upper SS7 layers since it has no MTP3.
Potential users of M2PA and M2UA should be aware of these differences
when deciding how to use them for SS7 signaling transport over IP
networks.
2. Protocol Elements 2. Protocol Elements
This section describes the format of various messages used in this This section describes the format of various messages used in this
protocol. protocol.
All fields in an M2PA message must be transmitted in the network byte All fields in an M2PA message must be transmitted in the network byte
order, i.e., most significant byte first, unless otherwise stated. order, i.e., most significant byte first, unless otherwise stated.
2.1 Common Message Header 2.1 Common Message Header
The protocol messages for M2PA require a message header structure The protocol messages for M2PA require a message header structure
which contains a version, message type and message length. This which contains a version, message type and message length. This
message header is common among all SCN adaptation layers. The message header is common among all SCN adaptation layers. The
header structure is shown in Figure 3. header structure is shown in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Spare | Message Type | | Version | Spare | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
Figure 3: Common Message Header Figure 5: Common Message Header
2.1.1 Version 2.1.1 Version
The version field (vers) contains the version of the M2PA adapation The version field (vers) contains the version of the M2PA adapation
layer. The supported versions are: layer. The supported versions are:
01 Release 1.0 of M2PA protocol 01 Release 1.0 of M2PA protocol
2.1.2 Message Type 2.1.2 Message Type
skipping to change at page 10, line 43 skipping to change at page 14, line 18
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
| Message Data | | Message Data |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.1 User Data 2.2.1 User Data
The User Data is the data sent from the MTP3 in the form of the The User Data is the data sent from the MTP3 in the form of the
contiguous LI, SIO, and SIF fields of the MSU ([2] Q.703, section 2.2 contiguous LI, SIO, and SIF octets of the MSU ([2] Q.703, section 2.2
Signal Unit Format). The format for the User Data message is as Signal Unit Format). The LI octet includes the two undefined bits
follows: between the SIO and LI fields.
The format for the User Data message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
| User Data | | Data |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No padding is added to the MTP3 message. No padding is added to the MTP3 message.
Note that the User Data field contains only the LI, SIF, and SIO Note that the Data field contains only the LI, SIF, and SIO
octets. The other components of the message transmitted by MTP2 (the octets. The other components of the message transmitted by MTP2 (the
Flag, BSN, BIB, FSN, FIB, CK) are not included in M2PA. Flag, BSN, BIB, FSN, FIB, CK) are not included in M2PA.
Note: The two spare bits in the LI octet are used in a national
version of SS7 by MTP3 as a Priority field. See [9], section 14
"Common Characteristics of message signal unit formats", section 14.2
(A) Priority Indicator (PRI).
2.2.2 Link Status 2.2.2 Link Status
The MTP2 Link Status message can be sent between M2PA peers to The MTP2 Link Status message can be sent between M2PA peers to
indicate link status. This message performs a function similar to the indicate link status. This message performs a function similar to the
the Link Status Signal Unit in MTP2. the Link Status Signal Unit in MTP2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Status | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Value Description Value Description
1 In Service 1 In Service
2 Processor Outage 2 Processor Outage
3 Processor Outage Ended 3 Processor Outage Ended
4 Busy 4 Busy
5 Busy Ended 5 Busy Ended
3. Procedures 3. M2PA Link States
3.1 Procedures to Support MTP2 Features The M2PA link moves from one state to another in response to various
events. The events that may result in a change of state include:
3.1.1 Signal Unit Format, Delimitation, Acceptance - MTP3 primitive requests
- SCTP notifications
- Receipt of Status messages from the peer M2PA
- Expiration of certain timers
Figure 6 illustrates state changes together with the causing events.
Note that some of the error conditions are not shown in the state
diagram.
Following is a list of the M2PA Link States and a description of each.
IDLE - State of link during power-up initialization.
OOS - Out Of Service. Power-up initialization is complete.
AIP - Alignment In Progress. M2PA is attempting to establish SCTP
association.
INS-LOCAL - In Service Local. Association is established. M2PA is
waiting for peer to verify that it is In Service.
INS - In Service. Link is ready for traffic.
RETRIEVAL - Link no longer carries traffic. M2PA is waiting for
request for message retrieval from MTP3.
+-----------+
| IDLE |
+-----------+
|
| Power On
|
V
+-----------+
+------->| OOS |---------+
| +-----------+ |
| | |
| | Client AND | Server AND
| | MTP3 Start | MTP3 Start
| | |
| V |
| +-----------+ |
| | AIP |<--------+
| +-----------+
| |
| | SCTP
| | Communication Up
| |
| V
| +-----------+
| | INS-LOCAL |
| +-----------+
| |
| | Link Status
| | In Service received
| |
| V
| +-----------+
| | INS |
| +-----------+
| |
Retrieval | | MTP3 Stop
Complete | | OR SCTP Communication Error
| | OR SCTP Communication Lost
| | OR T6 Expiration
| |
| V
| +-----------+
+--------| RETRIEVAL |
+-----------+
Figure 6: M2PA Link State Transition Diagram.
4. Procedures
4.1 Procedures to Support MTP2 Features
4.1.1 Signal Unit Format, Delimitation, Acceptance
Messages for transmission across the network must follow the format Messages for transmission across the network must follow the format
described in section 2. described in section 2.
SCTP provides reliable, in-sequence delivery. Therefore the related SCTP provides reliable, in-sequence delivery. Therefore the related
functionality of MTP2 is not needed. SCTP does not provide functions functionality of MTP2 is not needed. SCTP does not provide functions
related to Link State Control in MTP2. These functions must be related to Link State Control in MTP2. These functions must be
provided by M2PA. provided by M2PA.
3.1.2 Link Alignment 4.1.2 Link Alignment
Link alignment begins when MTP3 sends the Start command to M2PA.
To begin alignment in M2PA, M2PA sends the ASSOCIATE primitive to SCTP Link alignment includes the establishment of an SCTP association and a
if the SCTP association is not already established. handshaking procedure between the M2PA peers to verify that the
association is ready to be used as a link.
To prevent duplicate associations from being established, it must be To prevent duplicate associations from being established, it must be
decided in advance which endpoint initiates the establishment of the decided in advance which endpoint initiates the establishment of the
association. In a pair of endpoints, the endpoint that initiates the association. In a pair of endpoints, the endpoint that initiates the
establishment of the association is called the client. The other establishment of the association is called the client. The other
endpoint is the server. An endpoint may be a client in its endpoint is the server. An endpoint may be a client in its
relationship with one endpoint, and a server in its relationship with relationship with one endpoint, and a server in its relationship with
another endpoint. The designations of client and server are needed another endpoint. The designations of client and server are needed
only to decide which endpoint initiates the establishment of the only to decide which endpoint initiates the establishment of the
association. After that, the endpoints function as peers. association. After that, the endpoints function as peers.
skipping to change at page 12, line 37 skipping to change at page 17, line 48
a different local port number for each link. It must be decided in a different local port number for each link. It must be decided in
advance which local ports are used by the client. Each of these client advance which local ports are used by the client. Each of these client
ports must be known to the server. Each combination of client IP ports must be known to the server. Each combination of client IP
address/port and server IP address/port must be mapped to the same address/port and server IP address/port must be mapped to the same
Signaling Link Code (SLC) in the client and server, so that each Signaling Link Code (SLC) in the client and server, so that each
endpoint knows which link is being created at the time the SCTP endpoint knows which link is being created at the time the SCTP
association is established. However, M2PA does not do any processing association is established. However, M2PA does not do any processing
based on the SLC. based on the SLC.
An example of the relationships between the associations and the SLCs An example of the relationships between the associations and the SLCs
is shown in Figure 4 and Table 1. Note that a link is an SCTP is shown in Figure 7 and Table 1. Note that a link is an SCTP
association identified by two endpoints, in this case a client and association identified by two endpoints, in this case a client and
server. Each endpoint is identified by an IP address and port server. Each endpoint is identified by an IP address and port
number. Each association is mapped to an SLC. Table 1 is only number. Each association is mapped to an SLC. Table 1 is only
conceptual. The actual method for mapping the SCTP associations to the conceptual. The actual method for mapping the SCTP associations to the
SLCs is implementation dependent. SLCs is implementation dependent.
Client Server Client Server
IPA IPB IPA IPB
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 13, line 27 skipping to change at page 18, line 27
| port = P2 +---------------+ port = PW | | port = P2 +---------------+ port = PW |
| | | | | | | |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
IPA = IP address of Client IPA = IP address of Client
IPB = IP address of Server IPB = IP address of Server
P1, P2 = Pre-selected port numbers for Client P1, P2 = Pre-selected port numbers for Client
PW = Well-known port number for M2PA PW = Well-known port number for M2PA
Figure 4: Associations and SLCs Figure 7: Associations and SLCs
+-------------+---------------------------------------+-----+ +-------------+---------------------------------------+-----+
| Association | Client | Server | SLC | | Association | Client | Server | SLC |
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | | | | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+ +=============+============+======+============+======+=====+
| 1 | IPA | P1 | IPB | PW | a | | 1 | IPA | P1 | IPB | PW | a |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
| 2 | IPA | P2 | IPB | PW | b | | 2 | IPA | P2 | IPB | PW | b |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
Table 1: Associations and SLCs Table 1: Associations and SLCs
The association shall contain two streams in each direction. Stream 0 The association shall contain two streams in each direction. Stream 0
is designated for Link Status messages. Stream 1 is designated for is designated for Link Status messages. Stream 1 is designated for
User Data messages. User Data messages.
If the SCTP association is not established, the client M2PA sends the
ASSOCIATE primitive to SCTP. The client should attempt to establish
the association periodically until it is successful.
If SCTP fails to establish the association, and M2PA had received a If SCTP fails to establish the association, and M2PA had received a
Start command from its MTP3, then M2PA shall report to MTP3 that the Start Request from its MTP3, then M2PA shall report to MTP3 that the
link is out of service. If M2PA has an SCTP association ID for that link is out of service. If M2PA has an SCTP association ID for that
association, it should ABORT the association. The association ID is a association, it should ABORT the association. The association ID is a
number provided by the SCTP used to identify an association. number provided by the SCTP used to identify an association.
Once the association is established, M2PA invokes the GETSRTTREPORT Once the association is established, M2PA invokes the GETSRTTREPORT
primitive to determine the Smooth Round Trip Time (SRTT) from SCTP. If primitive to determine the Smooth Round Trip Time (SRTT) from SCTP. If
the SRTT exceeds its maximum allowed value (which is implementation the SRTT exceeds its maximum allowed value (which is implementation
dependent), M2PA should use the ABORT primitive to end the dependent), M2PA should use the ABORT primitive to end the
association. If M2PA had received a Start Request from its MTP3, then
association. If M2PA had received a Start command from its MTP3, then
M2PA shall report to MTP3 that the link is out of service. M2PA shall report to MTP3 that the link is out of service.
Once M2PA has received a Start from MTP3, the association is Once M2PA has received a Start Request from MTP3, the association is
established, the SRTT is determined to be satisfactory, and if MTP3 established, the SRTT is determined to be satisfactory, and if MTP3
has not deactivated the link, then: has not deactivated the link, then:
(a) If there is no local processor outage condition, M2PA sends a (a) If there is no local processor outage condition, M2PA sends a
Link Status of In Service to its peer. Link Status of In Service to its peer.
(b) If there is a local processor outage condition, M2PA sends Link (b) If there is a local processor outage condition, M2PA sends Link
Status Processor Outage to its peer. When MTP3 sends Local Status Processor Outage to its peer. When MTP3 sends Local
Processor Recovered, then M2PA sends Link Status Processor Processor Recovered, then M2PA sends Link Status Processor
Outage Ended to its peer, followed by Link Status In Service. Outage Ended to its peer, followed by Link Status In Service.
If M2PA has not received a Link Status In Service from its peer at the If M2PA has not received a Link Status In Service from its peer at the
time it sends the Link Status In Service, M2PA starts timer T1. Timer time it sends the Link Status In Service, M2PA starts timer T1. Timer
T1 is stopped when M2PA receives Link Status In Service from its T1 is stopped when M2PA receives Link Status In Service from its
peer. If M2PA does not receive Link Status In Service from its peer peer. If M2PA does not receive Link Status In Service from its peer
before T1 expires, then M2PA reports to MTP3 that the link is out of before T1 expires, then M2PA reports to MTP3 that the link is out of
service. Then M2PA uses the ABORT primitive to end the association. service. Then M2PA uses the ABORT primitive to end the association.
Recommended value of T1 is 5-150 seconds. Recommended value of T1 is 5-150 seconds.
Note that if the server M2PA has not received a Start Request from its
MTP3, it will not send the Link Status In Service message to the
client. Eventually the client will ABORT the association. The client
will then attempt to establish the association.
When the association is established, M2PA has sent Link Status In When the association is established, M2PA has sent Link Status In
Service to its peer, and has received Link Status In Service from its Service to its peer, and has received Link Status In Service from its
peer, and there is no local processor outage condition, then M2PA peer, and there is no local processor outage condition, then M2PA
sends Link In Service to its MTP3. sends Link In Service to its MTP3.
If M2PA receives a Link Status of Processor Outage during alignment, If M2PA receives a Link Status of Processor Outage during alignment,
and M2PA had received a Start command from its MTP3, M2PA shall report and M2PA had received a Start Request from its MTP3, M2PA shall report
Remote Processor Outage to MTP3. Remote Processor Outage to MTP3.
M2PA shall ignore the Emergency and Emergency Ceases commands from M2PA shall ignore the Emergency and Emergency Ceases commands from
MTP3. MTP3.
3.1.3 Processor Outage 4.1.3 Processor Outage
A processor outage occurs when M2PA cannot transfer messages because A processor outage occurs when M2PA cannot transfer messages because
of a condition at a higher layer than M2PA. of a condition at a higher layer than M2PA.
When M2PA detects a local processor outage, it sends a Link Status When M2PA detects a local processor outage, it sends a Link Status
message to its peer with status Processor Outage. M2PA shall discard message to its peer with status Processor Outage. M2PA shall discard
any User Data messages received. M2PA shall also cease sending User any User Data messages received. M2PA shall also cease sending User
Data messages to SCTP for transmission. Data messages to SCTP for transmission.
The peer M2PA, upon receiving the Link Status Processor Outage The peer M2PA, upon receiving the Link Status Processor Outage
message, shall report Remote Processor Outage to its MTP3. M2PA ceases message, shall report Remote Processor Outage to its MTP3. M2PA ceases
sending User Data messages. sending User Data messages.
When the processor outage ceases, MTP3 sends a Local Processor When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2PA. The local M2PA notifies its peer by Recovered indication to M2PA. The local M2PA notifies its peer by
sending a Link Status message with status Processor Outage Ended. The sending a Link Status message with status Processor Outage Ended. The
peer notifies its MTP3 that the remote processor outage has ceased. peer notifies its MTP3 that the remote processor outage has ceased.
3.1.4 Level 2 Flow Control 4.1.4 Level 2 Flow Control
Notification of receive congestion from SCTP to M2PA is implementation Notification of receive congestion from SCTP to M2PA is implementation
dependent. This section assumes that there is some form of receive dependent. This section assumes that there is some form of receive
congestion notification from SCTP to M2PA. congestion notification from SCTP to M2PA.
If M2PA receives notification from its lower layer SCTP that SCTP is If M2PA receives notification from its lower layer SCTP that SCTP is
in receive congestion for an association, M2PA shall send a Link in receive congestion for an association, M2PA shall send a Link
Status Busy message to its peer on that association. Status Busy message to its peer on that association.
When the peer M2PA receives the Link Status Busy message, it shall When the peer M2PA receives the Link Status Busy message, it shall
skipping to change at page 15, line 35 skipping to change at page 20, line 44
If M2PA receives notification from its lower layer SCTP that SCTP is If M2PA receives notification from its lower layer SCTP that SCTP is
no longer in receive congestion for the association, M2PA shall send a no longer in receive congestion for the association, M2PA shall send a
Link Status Busy Ended message to its peer on that association. Link Status Busy Ended message to its peer on that association.
When the peer M2PA receives the Link Status Busy Ended message, it When the peer M2PA receives the Link Status Busy Ended message, it
shall stop timer T6 and resume transmitting User Data messages from shall stop timer T6 and resume transmitting User Data messages from
its upper layer MTP3. its upper layer MTP3.
Recommended value of T6 is 1-6 seconds. Recommended value of T6 is 1-6 seconds.
3.1.5 Error Monitoring 4.1.5 Error Monitoring
If M2PA loses the SCTP association for a link, M2PA shall report to If M2PA loses the SCTP association for a link, M2PA shall report to
MTP3 that the link is out of service. MTP3 that the link is out of service.
3.1.6 Transmission Priorities 4.1.6 Transmission Priorities
In MTP, Link Status messages have priority over User Data messages In MTP, Link Status messages have priority over User Data messages
([2] Q.703, section 11.2). To achieve this in M2PA, Link Status and ([2] Q.703, section 11.2). To achieve this in M2PA, Link Status and
User Data messages shall be sent via SCTP on separate streams. All User Data messages shall be sent via SCTP on separate streams. All
messages are sent using the ordered delivery option. messages are sent using the ordered delivery option.
M2PA should give higher priority to reading the Link Status stream M2PA should give higher priority to reading the Link Status stream
over the User Data stream. over the User Data stream.
M2PA should give higher priority to receiving notifications from SCTP M2PA should give higher priority to receiving notifications from SCTP
over reading either the Link Status stream or the User Data stream. over reading either the Link Status stream or the User Data stream.
3.2 Procedures to Support the MTP3/MTP2 Interface Implementation Note: If the SCTP implementation allows streams to have
different priorities for sending messages, then M2PA should set the
Link Status stream to a higher priority than the User Data stream.
3.2.1 Sending/receiving messages 4.2 Procedures to Support the MTP3/MTP2 Interface
4.2.1 Sending/receiving messages
When MTP3 sends a message for transmission to M2PA, M2PA passes the When MTP3 sends a message for transmission to M2PA, M2PA passes the
corresponding M2PA message to SCTP using the SEND primitive. corresponding M2PA message to SCTP using the SEND primitive.
M2PA Link Status messages are passed to SCTP using the SEND primitive. M2PA Link Status messages are passed to SCTP using the SEND primitive.
Link Status and User Data messages shall be sent via SCTP on separate Link Status and User Data messages shall be sent via SCTP on separate
streams. streams.
When M2PA receives a Data message from SCTP, M2PA passes the message When M2PA receives a Data message from SCTP, M2PA passes the message
to MTP3. to MTP3.
3.2.2 Link activation and restoration 4.2.2 Link activation and restoration
When MTP3 requests that M2PA activate or restore a link by a Start When MTP3 requests that M2PA activate or restore a link by a Start
command, M2PA shall follow the alignment procedure in section 3.1.2. Request, M2PA shall follow the alignment procedure in section 4.1.2.
3.2.3 Link deactivation 4.2.3 Link deactivation
When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA
shall send an ABORT primitive to SCTP. shall send an ABORT primitive to SCTP.
3.2.4 Flush buffers 4.2.4 Flush buffers
If M2PA receives a Flush Buffers command from MTP3, M2PA: If M2PA receives a Flush Buffers command from MTP3, M2PA:
(a) shall not transmit any messages to SCTP that are currently (a) shall not transmit any messages to SCTP that are currently
waiting to be transmitted to SCTP. waiting to be transmitted to SCTP.
(b) shall discard all messages currently waiting to be passed (b) shall discard all messages currently waiting to be passed
to MTP3. to MTP3.
3.2.5 MTP3 Signaling Link Congestion 4.2.5 MTP3 Signaling Link Congestion
Notification of transmit congestion from SCTP to its upper layer Notification of transmit congestion from SCTP to its upper layer
(M2PA) is implementation dependent. Nevertheless, M2PA should receive (M2PA) is implementation dependent. Nevertheless, M2PA should receive
notification from SCTP adequate to allow MTP3 to meet its requirements notification from SCTP adequate to allow MTP3 to meet its requirements
for signaling link transmit congestion in [2] Q.704, section 3.8. for signaling link transmit congestion in [2] Q.704, section 3.8.
M2PA shall notify its upper layer MTP3 when transmit buffer occupancy M2PA shall notify its upper layer MTP3 when transmit buffer occupancy
crosses the congestion onset, discard, and abatement thresholds. For crosses the congestion onset, discard, and abatement thresholds. For
national networks with multiple congestion threshold levels, M2PA national networks with multiple congestion threshold levels, M2PA
shall notify MTP3 when transmit buffer occupancy crosses each level of shall notify MTP3 when transmit buffer occupancy crosses each level of
the congestion onset, discard, and abatement thresholds. the congestion onset, discard, and abatement thresholds.
3.2.6 Changeover 4.2.6 Changeover
The objective of the changeover is to ensure that signaling traffic The objective of the changeover is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the carried by the unavailable signaling link is diverted to the
alternative signaling link(s) as quickly as possible while avoiding alternative signaling link(s) as quickly as possible while avoiding
message loss, duplication, or mis-sequencing. For this purpose, the message loss, duplication, or mis-sequencing. For this purpose, the
changeover procedure includes data retrieval, which is performed changeover procedure includes data retrieval, which is performed
before opening the alternative signaling links to the diverted before opening the alternative signaling links to the diverted
traffic. Data retrieval consists of these steps: traffic. Data retrieval consists of these steps:
(1) buffer updating, i.e., identifying all those User Data (1) buffer updating, i.e., identifying all those User Data
messages in the retransmission buffer of the unavailable messages in the retransmission buffer of the unavailable
signaling link which have not been received by the far end signaling link which have not been received by the far end
SCTP, as well as untransmitted messages, and SCTP, as well as untransmitted messages, and
(2) transferring those messages to the transmission buffers of the (2) transferring those messages to the transmission buffers of the
alternate links. alternate links.
skipping to change at page 19, line 5 skipping to change at page 24, line 14
Each of these messages is sent to MTP3, first (a), then (b). Then M2PA Each of these messages is sent to MTP3, first (a), then (b). Then M2PA
sends the Retrieval Complete indication to MTP3. sends the Retrieval Complete indication to MTP3.
Note: The changeover procedure makes it impossible for M2PA to have Note: The changeover procedure makes it impossible for M2PA to have
multiple User Data streams in a direction for one link. Buffer multiple User Data streams in a direction for one link. Buffer
updating would have to be done for each User Data stream separately to updating would have to be done for each User Data stream separately to
avoid duplication of messages. But MTP3 provides for only one XCO avoid duplication of messages. But MTP3 provides for only one XCO
message for sending the last-received SSN. message for sending the last-received SSN.
4. Examples of M2PA Procedures 5. Examples of M2PA Procedures
In general, messages passed between MTP3 and M2PA are the same as In general, messages passed between MTP3 and M2PA are the same as
those passed between MTP3 and MTP2. M2PA interprets messages from those passed between MTP3 and MTP2. M2PA interprets messages from
MTP3 and sends the appropriate message to SCTP. Likewise, messages MTP3 and sends the appropriate message to SCTP. Likewise, messages
from SCTP are used to generate a meaningful message to MTP3. from SCTP are used to generate a meaningful message to MTP3.
Note that throughout this section, the primitives between MTP3 and Note that throughout this section, the primitives between MTP3 and
M2PA are named using the MTP terminology [1][2]. Communications M2PA are named using the MTP terminology [1][2]. Communications
between M2PA and SCTP are named using SCTP terminology. between M2PA and SCTP are named using SCTP terminology.
4.1 Link Initialization (Alignment) 5.1 Link Initialization (Alignment)
An example of the message flow to bring an SS7 link in service is An example of the message flow to bring an SS7 link in service is
shown below. Alignment is done by both ends of the link. To simplify the shown below. Alignment is done by both ends of the link. To simplify the
diagram, alignment is shown on one end only. It is assumed in this diagram, alignment is shown on one end only. It is assumed in this
example that SCTP has been initialized. example that SCTP has been initialized.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Out of Service Out of Service
skipping to change at page 20, line 27 skipping to change at page 26, line 5
------------------------------------> ------------------------------------>
Link Status In Service Link Status In Service
<------------------------------------ <------------------------------------
In Service In Service In Service In Service
<------------ ------------> <------------ ------------>
At this point, MTP3 may begin sending data messages. At this point, MTP3 may begin sending data messages.
4.2 Message Transmission and Reception 5.2 Message Transmission and Reception
Messages are transmitted using the Data Request primitive from MTP3 to Messages are transmitted using the Data Request primitive from MTP3 to
M2PA. The diagram shows the case where the Link is In Service. The M2PA. The diagram shows the case where the Link is In Service. The
message is passed from MTP3 of the source to MTP3 of the destination. message is passed from MTP3 of the source to MTP3 of the destination.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Message for Message for
transmission transmission
skipping to change at page 21, line 5 skipping to change at page 26, line 30
------------> ------------>
(SCTP sends message) (SCTP sends message)
Receive Receive
------------> ------------>
Received message Received message
------------> ------------>
4.3 Link Status Indication 5.3 Link Status Indication
If SCTP sends a Communication Lost primitive to M2PA, M2PA notifies If SCTP sends a Communication Lost primitive to M2PA, M2PA notifies
MTP3 that the link is out of service. MTP3 responds in its usual way. MTP3 that the link is out of service. MTP3 responds in its usual way.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Communication Lost Communication Lost
<------------ <------------
Out of Service Out of Service
<------------ <------------
4.4 Link Status Message (Processor Outage) 5.4 Link Status Message (Processor Outage)
This example shows how M2PA responds to a local processor outage. M2PA This example shows how M2PA responds to a local processor outage. M2PA
sends a Link Status message to its peer. The peer M2PA notifies MTP3 sends a Link Status message to its peer. The peer M2PA notifies MTP3
of the outage. MTP3 can then follow the processor outage procedures in of the outage. MTP3 can then follow the processor outage procedures in
[2]. [2].
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
M2PA detects M2PA detects
skipping to change at page 23, line 5 skipping to change at page 28, line 5
(SCTP sends message) (SCTP sends message)
Receive Receive
------------> ------------>
Remote Processor Remote Processor
Outage Ceases Outage Ceases
------------> ------------>
4.5 Congestion Notification to Upper layer 5.5 Congestion Notification to Upper layer
MTP3 expects notification of link congestion. In this example, it is MTP3 expects notification of link congestion. In this example, it is
assumed that SCTP notifies M2PA of congestion onset and abatement. assumed that SCTP notifies M2PA of congestion onset and abatement. The
notification includes the congestion level, if there are levels of
congestion defined.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Implementation dependent Implementation dependent
indication of congestion indication of congestion
onset onset (level)
<------------ <------------
Congestion Onset Congestion Indication
(level)
<------------ <------------
Implementation dependent Implementation dependent
indication of congestion indication of congestion
abatement abatement (level)
<------------ <------------
Congestion Abatement Congestion Indication
(level)
<------------ <------------
4.6 Link Deactivation 5.6 Link Deactivation
The MTP3 can request that a SS7-IP link be taken out-of-service. M2PA The MTP3 can request that a SS7-IP link be taken out-of-service. M2PA
uses the Abort message as shown below. uses the Abort message as shown below.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Stop Stop
------------> ------------>
skipping to change at page 24, line 5 skipping to change at page 30, line 5
(SCTP performs its (SCTP performs its
termination procedure) termination procedure)
Communication Lost Communication Lost
<------------ <------------
Out of Service Out of Service
<------------ <------------
4.7 Link Changeover 5.7 Link Changeover
In this example, MTP3 performs a changeover because the link went out In this example, MTP3 performs a changeover because the link went out
of service. MTP3 selects a different link for retransmitting the of service. MTP3 selects a different link for retransmitting the
unacknowledged messages. unacknowledged messages.
Note that in this example, the sequence numbers and messages requested Note that in this example, the sequence numbers and messages requested
by MTP3 are sent from SCTP to M2PA in the Communication Lost by MTP3 are sent from SCTP to M2PA in the Communication Lost
primitive. In general, the retrieval of sequence numbers and messages primitive. In general, the retrieval of sequence numbers and messages
is implementation dependent. is implementation dependent.
skipping to change at page 26, line 5 skipping to change at page 32, line 5
<------------ <------------
Retrieved Message Retrieved Message
<------------ <------------
Retrieval Complete Retrieval Complete
<------------ <------------
Send messages on another link. Send messages on another link.
5. Security 6. Security
SCN adaptation layers rely on SCTP to provide security. SCN adaptation layers rely on SCTP to provide security.
6. IANA Considerations 7. IANA Considerations
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA
is TBD. is TBD.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is SCTP Payload Data chunk is
M2PA TBD M2PA TBD
The SCTP Payload Protocol Identifier is included in each SCTP Data The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but may be used by Protocol Identifier is not directly used by SCTP but may be used by
certain network entities to identify the type of information being certain network entities to identify the type of information being
carried in a Data chunk. carried in a Data chunk.
The User Adaptation peer may use the Payload Protocol Identifier as a The User Adaptation peer may use the Payload Protocol Identifier as a
way of determining additional information about the data being way of determining additional information about the data being
presented to it by SCTP. presented to it by SCTP.
7. Acknowledgements 8. Acknowledgements
The authors would like to thank Ian Rytina for his valuable comments The authors would like to thank Brian Tatum and Ian Rytina for their
and suggestions. valuable comments and suggestions.
8. References 9. References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)' System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7
(SS7) - Message Transfer Part (MTP)' (SS7) - Message Transfer Part (MTP)'
[3] Bellcore GR-246-CORE 'Bell Communications Research Specification [3] Bellcore GR-246-CORE 'Bell Communications Research Specification
of Signaling System Number 7', Volume 1, December 1995 of Signaling System Number 7', Volume 1, December 1995
[4] RFC 2719, Framework Architecture for Signaling Transport, [4] RFC 2719, Framework Architecture for Signaling Transport,
October 1999 October 1999
[5] RFC 2960, Stream Control Transmission Protocol, [5] RFC 2960, Stream Control Transmission Protocol,
October 2000 October 2000
[6] SS7 MTP2-User Adaptation Layer, draft-ietf-sigtran-m2ua-00.txt, [6] SS7 MTP2-User Adaptation Layer, draft-ietf-sigtran-m2ua-05.txt,
March 2000 November 2000
[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 [7] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T functions and messages using the services of ITU-T
Recommendation Q.2140' Recommendation Q.2140'
[8] Bradner, S. "Key words for use in RFCs to Indicate Requirement [8] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
9. Author's Addresses [9] Telecommunication Technology Committee (TTC) Standard JT-Q704,
'Message Transfer Part Signaling Network Functions',
April 28, 1992.
10. Author's Addresses
Tom George Tel: +1-972-519-3168 Tom George Tel: +1-972-519-3168
Alcatel USA EMail: tom.george@usa.alcatel.com Alcatel USA EMail: tom.george@usa.alcatel.com
1000 Coit Road 1000 Coit Road
Plano, TX 75075 Plano, TX 75075
USA USA
Ram Dantu, Ph.D. Tel: +1-972-234-6070 extension 211 Ram Dantu, Ph.D. Tel: +1-972-234-6070 extension 211
IPmobile EMail: rdantu@ipmobile.com IPmobile EMail: rdantu@ipmobile.com
1651 North Glenville, Suite 216 1651 North Glenville, Suite 216
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/