draft-ietf-sigtran-m2pa-10.txt   draft-ietf-sigtran-m2pa-11.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 14
INTERNET-DRAFT Alcatel INTERNET-DRAFT Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Ram Dantu Ram Dantu
University of North Texas University of North Texas
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Expires April 2004 October 16, 2003 Expires July 2004 January 29, 2004
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-10.txt> <draft-ietf-sigtran-m2pa-11.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 13 skipping to change at page 3, line 13
endpoints. endpoints.
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........................................... 6 1.4 Conventions........................................... 6
1.5 Signaling Transport Architecture...................... 6 1.5 Signaling Transport Architecture...................... 6
1.6 Services Provided by M2PA............................. 8 1.6 Services Provided by M2PA............................. 9
1.7 Functions Provided by M2PA............................ 9 1.7 Functions Provided by M2PA............................10
1.8 Definition of the M2PA Boundaries.....................10 1.8 Definition of the M2PA Boundaries.....................11
1.9 Differences Between M2PA and M2UA.....................10 1.9 Differences Between M2PA and M2UA.....................11
2. Protocol Elements........................................12 2. Protocol Elements........................................13
2.1 Common Message Header.................................12 2.1 Common Message Header.................................13
2.2 M2PA Header...........................................14 2.2 M2PA Header...........................................14
2.3 M2PA Messages.........................................14 2.3 M2PA Messages.........................................15
3. State Control............................................18 3. State Control............................................19
3.1 SCTP Association State Control........................18 3.1 SCTP Association State Control........................19
3.2 M2PA Link State Control...............................19 3.2 M2PA Link State Control...............................20
4. Procedures...............................................19 4. Procedures...............................................21
4.1 Procedures to Support MTP2 Features...................19 4.1 Procedures to Support MTP2 Features...................21
4.2 Procedures to Support the MTP3/MTP2 Interface.........29 4.2 Procedures to Support the MTP3/MTP2 Interface.........32
4.3 SCTP Considerations...................................32 4.3 SCTP Considerations...................................36
5. Examples of M2PA Procedures..............................33 5. Examples of M2PA Procedures..............................37
5.1 Link Initialization (Alignment).......................34 5.1 Link Initialization (Alignment).......................38
5.2 Message Transmission and Reception....................36 5.2 Message Transmission and Reception....................40
5.3 Link Status Indication................................36 5.3 Link Status Indication................................40
5.4 Link Status Message (Processor Outage)................37 5.4 Link Status Message (Processor Outage)................41
5.5 Level 2 Flow Control..................................41 5.5 Level 2 Flow Control..................................45
5.6 MTP3 Signaling Link Congestion........................43 5.6 MTP3 Signaling Link Congestion........................47
5.7 Link Deactivation.....................................43 5.7 Link Deactivation.....................................47
5.8 Link Changeover.......................................44 5.8 Link Changeover.......................................48
6. Security.................................................45 6. Security.................................................49
6.1 Security Requirements.................................45 6.1 Security Requirements.................................49
6.2 Protecting Confidentiality............................45 6.2 Protecting Confidentiality............................49
7. IANA Considerations......................................46 7. IANA Considerations......................................50
7.1 SCTP Payload Protocol Identifier......................46 7.1 SCTP Payload Protocol Identifier......................50
7.2 M2PA Protocol Extensions..............................46 7.2 M2PA Protocol Extensions..............................50
8. Acknowledgements.........................................48 8. Acknowledgements.........................................53
9. References...............................................48 9. References...............................................53
9.1 Normative..............................................48 9.1 Normative..............................................53
9.2 Informative............................................49 9.2 Informative............................................55
10. Author's Addresses.......................................50 10. Author's Addresses.......................................56
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 message transfer between delivery over an IP network. This includes message transfer between
the following: the following:
- a Signaling Gateway (SG) and a Media Gateway Controller (MGC) - a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
skipping to change at page 4, line 35 skipping to change at page 4, line 35
advantages when traditional signaling links are replaced by IP network advantages when traditional signaling links are replaced by IP network
"connections". "connections".
The delivery mechanism described in this document allows for full MTP3 The delivery mechanism described in this document allows for full MTP3
message handling and network management capabilities between any two message handling and network management capabilities between any two
SS7 nodes, communicating over an IP network. An SS7 node equipped with SS7 nodes, communicating over an IP network. An SS7 node equipped with
an IP network connection is called an IP Signaling Point (IPSP). The an IP network connection is called an IP Signaling Point (IPSP). The
IPSPs function as traditional SS7 nodes using the IP network instead IPSPs function as traditional SS7 nodes using the IP network instead
of SS7 links. of SS7 links.
The delivery mechanism SHOULD The delivery mechanism should:
- Support seamless operation of MTP3 protocol peers over an IP - Support seamless operation of MTP3 protocol peers over an IP
network connection. network connection.
- Support the MTP Level 2 / MTP Level 3 interface boundary. - Support the MTP Level 2 / MTP Level 3 interface boundary.
- Support management of SCTP transport associations and traffic - Support management of SCTP transport associations and traffic
instead of MTP2 Links. instead of MTP2 Links.
- Support asynchronous reporting of status changes to management. - Support asynchronous reporting of status changes to management.
skipping to change at page 7, line 31 skipping to change at page 8, line 7
+------+ +------+ +------+ +------+
IP - Internet Protocol IP - Internet Protocol
IPSP - IP Signaling Point IPSP - IP Signaling Point
SCTP - Stream Control Transmission Protocol [RFC2960] SCTP - Stream Control Transmission Protocol [RFC2960]
Figure 1. M2PA Symmetrical Peer-to-Peer Architecture Figure 1. M2PA Symmetrical Peer-to-Peer Architecture
Figure 2 shows an example of M2PA used in a Signaling Gateway Figure 2 shows an example of M2PA used in a Signaling Gateway
(SG). The SG is an IPSP equipped with both traditional SS7 and IP (SG). The SG is an IPSP equipped with both traditional SS7 and IP
network connections. Any of the nodes in the diagram could have SCCP network connections.
or other SS7 layers above MTP3. The Signaling Gateway acts as a Signal
Transfer Point (STP). Other STPs MAY be present in the SS7 path The SEP and the SG communicate through a traditional SS7 link, which
between the SEP and the SG. follows a protocol such as [Q.702]. The SG and the IPSP communicate
through an IP link using the M2PA protocol. Messages sent from the SEP
to the IPSP (and vice versa) are routed by the SG.
Any of the nodes in the diagram could have SCCP or other SS7 layers
above MTP3. The Signaling Gateway acts as a Signal Transfer Point
(STP). Other STPs MAY be present in the SS7 path between the SEP and
the SG.
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP * * SEP *--------* SG *--------* IPSP *
******** *************** ******** ******** *************** ********
+------+ +------+ +------+ +------+
| TCAP | | TCAP | | TCAP | | TCAP |
+------+ +------+ +------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+ +------+ +-------------+ +------+
skipping to change at page 18, line 23 skipping to change at page 19, line 18
Figure 7 illustrates state changes in the M2PA management of the SCTP Figure 7 illustrates state changes in the M2PA management of the SCTP
association together with the causing events. Note that some of the association together with the causing events. Note that some of the
error conditions are not shown in the state diagram. error conditions are not shown in the state diagram.
Following is a list of the M2PA Association States and a description Following is a list of the M2PA Association States and a description
of each. of each.
IDLE - State of the association during power-up initialization. IDLE - State of the association during power-up initialization.
ASSOCIATE - M2PA is attempting to establish an SCTP association. ASSOCIATING - M2PA is attempting to establish an SCTP association.
ESTABLISHED - SCTP association is established. ESTABLISHED - SCTP association is established.
+-----------+ +-----------+
| IDLE | | IDLE |
+-----------+ +-----------+
| |
| Associate | Associate
| (Issue SCTP associate) | (Issue SCTP associate)
| |
| +----------------------+ | +----------------------+
| | (Issue SCTP | | | (Issue SCTP |
V V associate) | V V associate) |
+-----------+ | +-------------+ |
| ASSOCIATE |------------------->+ | ASSOCIATING |----------------->+
+-----------+ SCTP Comm Error | +-------------+ SCTP Comm Error |
| | | |
| | | |
| SCTP Comm Up | | SCTP Comm Up |
| | | |
V | V |
+-------------+ | +-------------+ |
| ESTABLISHED |----------------->+ | ESTABLISHED |----------------->+
+-------------+ SCTP Comm Error +-------------+ SCTP Comm Error
OR SCTP Comm Lost OR SCTP Comm Lost
skipping to change at page 19, line 30 skipping to change at page 21, line 15
4. Procedures 4. Procedures
Since M2PA provides MTP3 with an interface and functionality like Since M2PA provides MTP3 with an interface and functionality like
MTP2, its internal functioning is similar to that of MTP2. MTP2, its internal functioning is similar to that of MTP2.
Except as modified in this document, M2PA SHOULD follow the Except as modified in this document, M2PA SHOULD follow the
requirements of the applicable MTP2 specification. These may include requirements of the applicable MTP2 specification. These may include
[Q.703] or [T1.111]. The same standard MUST be followed on both ends [Q.703] or [T1.111]. The same standard MUST be followed on both ends
of the M2PA link. of the M2PA link.
In particular, the the corresponding applicable timer value defaults
and ranges specified for the applicable MTP2 standard should be used
for the M2PA timers.
When referring to MTP2 terminology in this document, the terminology When referring to MTP2 terminology in this document, the terminology
of [Q.703] is used. This does not imply that the requirements of of [Q.703] is used. This does not imply that the requirements of
[Q.703] are to be followed. [Q.703] are to be followed.
4.1 Procedures to Support MTP2 Features 4.1 Procedures to Support MTP2 Features
4.1.1 Signal Unit Format, Delimitation, Acceptance 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.
skipping to change at page 26, line 30 skipping to change at page 28, line 39
condition, instead of an MSU or FISU as in MTP2. The BSN in the Link condition, instead of an MSU or FISU as in MTP2. The BSN in the Link
Status Processor Recovered message is set to the FSN of the last User Status Processor Recovered message is set to the FSN of the last User
Data message received (and not discarded) from the peer M2PA. Data message received (and not discarded) from the peer M2PA.
Upon receiving the Link Status Processor Recovered message, the M2PA Upon receiving the Link Status Processor Recovered message, the M2PA
in RPO SHALL respond with a Link Status Ready message on the User Data in RPO SHALL respond with a Link Status Ready message on the User Data
stream. The BSN in the Link Status Ready message is set to the FSN of stream. The BSN in the Link Status Ready message is set to the FSN of
the last User Data message received (and not discarded) from the peer the last User Data message received (and not discarded) from the peer
M2PA. M2PA.
Upon receiving the Link Status Ready message, the M2PA formerly in LPO
SHALL respond with a Link Status Ready message on the User Data
stream. The BSN in the Link Status Ready message is set to the FSN of
the last User Data message received (and not discarded) from the peer
M2PA.
M2PA (at both the LPO and RPO ends) uses the BSN value in the received M2PA (at both the LPO and RPO ends) uses the BSN value in the received
Link Status Ready message to resynchronize its sequence numbers, if Link Status Ready message to resynchronize its sequence numbers, if
this is required by MTP2. M2PA SHALL not resume transmitting User Data this is required by MTP2. M2PA SHALL NOT resume transmitting User Data
messages until it has received the Link Status Ready message. messages until it has received the Link Status Ready message.
During resynchronization, M2PA SHALL NOT discard any received User During resynchronization, M2PA SHALL NOT discard any received User
Data messages that were sent after the processor outage ended. Data messages that were sent after the processor outage ended.
When M2PA experiences a local processor outage, it MAY put the link When M2PA experiences a local processor outage, it MAY put the link
out of service by sending a Link Status Out of Service message if out of service by sending a Link Status Out of Service message if
allowed by the applicable MTP2 standard (e.g., [Q.2140]). allowed by the applicable MTP2 standard (e.g., [Q.2140]).
In other respects, M2PA SHOULD follow the same procedures as MTP2 in In other respects, M2PA SHOULD follow the same procedures as MTP2 in
skipping to change at page 45, line 26 skipping to change at page 49, line 26
Additional requirements MAY come from local regulation. Additional requirements MAY come from local regulation.
While these parties may have some overlapping security needs, their While these parties may have some overlapping security needs, their
needs may not be identical. Any security solution SHOULD fulfill all needs may not be identical. Any security solution SHOULD fulfill all
of the different parties' needs. of the different parties' needs.
6.1 Security Requirements 6.1 Security Requirements
Consult [Security] for a discussion of security requirements and for Consult [Security] for a discussion of security requirements and for
guidance on the use of security protocols. guidance on the use of security protocols. Implementers of M2PA MUST
follow the guidelines in [Security].
When M2PA is running in professionally managed corporate or service When M2PA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site Security includes an appropriate security policy framework. The "Site Security
Handbook" [RFC2196] SHOULD be consulted for guidance. Handbook" [RFC2196] SHOULD be consulted for guidance.
6.2 Protecting Confidentiality 6.2 Protecting Confidentiality
Particularly for wireless users, the requirement for confidentiality Particularly for wireless users, the requirement for confidentiality
MAY include the masking of IP addresses and ports. In this case MAY include the masking of IP addresses and ports. In this case
skipping to change at page 46, line 45 skipping to change at page 50, line 45
- through definition of additional message parameters. - through definition of additional message parameters.
The definition and use of new message classes, types, and parameters The definition and use of new message classes, types, and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434]. defined in [RFC2434].
The proposed extension must in no way adversely affect the general The proposed extension must in no way adversely affect the general
working of the protocol. working of the protocol.
The defined values for the message classes, types, and parameters are
listed in the Signaling User Adaptation Layer registry
(sigtran-adapt).
7.2.1 IETF Defined Message Classes 7.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following The documentation for a new message class MUST include the following
information: information:
(a) A long and short name for the message class. (a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class. (b) A detailed description of the purpose of the message class.
7.2.2 IETF Defined Message Types 7.2.2 IETF Defined Message Types
skipping to change at page 48, line 5 skipping to change at page 52, line 5
(b) Detailed description of the structure of the parameter field. (b) Detailed description of the structure of the parameter field.
(c) Detailed definition of each component of the parameter value. (c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type, (d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within multiple instances of this parameter type may be found within
the same message type. the same message type.
7.2.4 Defined Values
This section lists the values defined in this document that should be
included in the Signaling User Adaptation Layer registry
(sigtran-adapt).
The following values for Message Class are defined in this document:
Value
(decimal) Message Class
--------- -------------
11 M2PA Messages
The following values for Message Type are defined in this document:
Value
(decimal) Message Type
--------- -------------
1 User Data
2 Link Status
The following values for Version are defined in this document:
Value
(decimal) Version
--------- -------
1 Release 1.0 of M2PA protocol
The following values for the State parameter are defined in this
document:
Value
(decimal) Description
--------- -----------
1 Alignment
2 Proving Normal
3 Proving Emergency
4 Ready
5 Processor Outage
6 Processor Recovered
7 Busy
8 Busy Ended
9 Out of Service (OOS)
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the following for their valuable The authors would like to thank the following for their valuable
comments and suggestions: Brian Tatum, Wayne Davis, Cliff Thomas, comments and suggestions: Brian Tatum, Wayne Davis, Cliff Thomas,
Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina, Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina,
Greg Sidebottom, Al Varney, Jeff Craig, Andrew Booth. Greg Sidebottom, Al Varney, Jeff Craig, Andrew Booth.
9. References 9. References
9.1 Normative 9.1 Normative
[JT-Q703] [JT-Q703]
TTC, "Message Transfer Part Signalling Link," TTC Standard TTC, "Message Transfer Part Signalling Link," TTC Standard
JT-Q703, Telecommunication Technology Committee (TTC), version JT-Q703, Telecommunication Technology Committee (TTC), version
3 (April 27, 1994). 3 (April 27, 1994).
[JT-Q704] [JT-Q704]
TTC, "Message Transfer Part Signalling Network Functions," TTC TTC, "Message Transfer Part Signalling Network Functions," TTC
Standard JT-Q704, Telecommunication Technology Committee (TTC), Standard JT-Q704, Telecommunication Technology Committee (TTC),
version 3 (April 28, 1992). version 4 (May 30, 2002).
[Q.703] [Q.703]
ITU, "Signalling System No. 7 - Signalling Link," ITU-T ITU, "Signalling System No. 7 - Signalling Link," ITU-T
Recommendation Q.703, ITU-T Telecommunication Standardization Recommendation Q.703, ITU-T Telecommunication Standardization
Sector of ITU (March 1993). Sector of ITU (July 1996).
[Q.Imp703]
ITU, "Implementors' Guide (03/99) for Recommendation Q.703
(07/96)" ITU-T Recommendation Q.Imp703, ITU-T Telecommunication
Standardization Sector of ITU (March 1999).
[Q.704] [Q.704]
ITU, "Message Transfer Part - Signalling Network Functions and ITU, "Message Transfer Part - Signalling Network Functions and
Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication
Standardization Sector of ITU (March 1993). Standardization Sector of ITU (July 1996).
[Q.Imp704]
ITU, "Implementors' Guide (12/2000) for Recommendation Q.704
(07/96)" ITU-T Recommendation Q.Imp704, ITU-T Telecommunication
Standardization Sector of ITU (December 2000).
[Q.2140] [Q.2140]
ITU, "B-ISDN ATM Adaptation Layer - Service Specific ITU, "B-ISDN ATM Adaptation Layer - Service Specific
Coordination Function for Signalling at the Network Node Coordination Function for Signalling at the Network Node
Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T
Telecommunication Standardization Sector of ITU (February Telecommunication Standardization Sector of ITU (February
1996). 1995).
[Q.Imp2140]
ITU, "Implementors' Guide (03/99) for Recommendation Q.2140
(02/95)" ITU-T Recommendation Q.Imp2140, ITU-T
Telecommunication Standardization Sector of ITU (March 1999).
[Q.2210] [Q.2210]
ITU, "Message Transfer Part Level 3 Functions and Messages ITU, "Message Transfer Part Level 3 Functions and Messages
Using the Services of ITU-T Recommendation Q.2140," ITU-T Using the Services of ITU-T Recommendation Q.2140," ITU-T
Recommendation Q.2210, ITU-T Telecommunication Standardization Recommendation Q.2210, ITU-T Telecommunication Standardization
Sector of ITU (July 1996). Sector of ITU (July 1996).
[Q.Imp2210]
ITU, "Implementors' Guide (12/99) for Recommendation Q.2210
(07/96)" ITU-T Recommendation Q.Imp2210, ITU-T
Telecommunication Standardization Sector of ITU (December
1999).
[RFC791] [RFC791]
Information Sciences Institute, "Internet Protocol - DARPA Information Sciences Institute, "Internet Protocol - DARPA
Internet Program - Protocol Specification," RFC 791, The Internet Program - Protocol Specification," RFC 791, The
Internet Society (September 1981). Internet Society (September 1981).
[RFC2119] [RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, Internet Engineering Task Force Levels," BCP 14, RFC 2119, Internet Engineering Task Force
(March 1997). (March 1997).
skipping to change at page 49, line 31 skipping to change at page 54, line 53
(SCTP)," RFC 2960, The Internet Society (February 2000). (SCTP)," RFC 2960, The Internet Society (February 2000).
[RFC3309] [RFC3309]
J. Stone, R. Stewart, and D. Otis, "Stream Control Transmission J. Stone, R. Stewart, and D. Otis, "Stream Control Transmission
Protocol (SCTP) Checksum Change," RFC 3309, The Internet Protocol (SCTP) Checksum Change," RFC 3309, The Internet
Society (September 2002). Society (September 2002).
[Security] [Security]
J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security
Considerations for SIGTRAN Protocols," Considerations for SIGTRAN Protocols,"
draft-ietf-sigtran-security-02.txt (January 2003). draft-ietf-sigtran-security-03.txt (June 2003).
[T1.111] [T1.111]
ANSI, "American National Standard for Telecommunications - ANSI, "American National Standard for Telecommunications -
Signaling System Number 7 (SS7) - Message Transfer Part (MTP)," Signaling System Number 7 (SS7) - Message Transfer Part (MTP),"
ANSI T1.111-2000, American National Standards Institute (2000). ANSI T1.111-2001, American National Standards Institute
(February 2001).
9.2 Informative 9.2 Informative
[M2UA] [M2UA]
K. Morneault, et. al., "Signaling System 7 (SS7) Message K. Morneault, et. al., "Signaling System 7 (SS7) Message
Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331, Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
Internet Engineering Task Force - Signalling Transport Working Internet Engineering Task Force - Signalling Transport Working
Group (September, 2002). Group (September, 2002).
[Q.700] [Q.700]
skipping to change at page 49, line 58 skipping to change at page 55, line 31
Recommendation Q.700, ITU-T Telecommunication Standardization Recommendation Q.700, ITU-T Telecommunication Standardization
Sector of ITU (March 1993). Sector of ITU (March 1993).
[Q.701] [Q.701]
ITU, "Functional Description of the Message Transfer Part (MTP) ITU, "Functional Description of the Message Transfer Part (MTP)
of Signalling System No. 7," ITU-T Recommendation Q.701, ITU-T of Signalling System No. 7," ITU-T Recommendation Q.701, ITU-T
Telecommunication Standardization Sector of ITU (March 1993). Telecommunication Standardization Sector of ITU (March 1993).
[Q.702] [Q.702]
ITU, "Signalling Data Link," ITU-T Recommendation Q.702, ITU-T ITU, "Signalling Data Link," ITU-T Recommendation Q.702, ITU-T
Telecommunication Standardization Sector of ITU (March 1993). Telecommunication Standardization Sector of ITU (November
1988).
[Q.705] [Q.705]
ITU, "Signalling System No. 7 - Signalling Network Structure," ITU, "Signalling System No. 7 - Signalling Network Structure,"
ITU-T Recommendation Q.705, ITU-T Telecommunication ITU-T Recommendation Q.705, ITU-T Telecommunication
Standardization Sector of ITU (March 1993). Standardization Sector of ITU (March 1993).
[Q.Imp705]
ITU, "Implementors' guide (version 09/97) for Q.705 (03/93)"
ITU-T Recommendation Q.Imp705, ITU-T Telecommunication
Standardization Sector of ITU (September 1997).
[RFC2719] [RFC2719]
L. Ong, et. al., "Framework Architecture for Signaling L. Ong, et. al., "Framework Architecture for Signaling
Transport," RFC 2719, The Internet Society (October 1999). Transport," RFC 2719, The Internet Society (October 1999).
10. Author's Addresses 10. Author's Addresses
Tom George Tel: +1-972-519-3168 Tom George Telephone: +1-972-519-3168
Alcatel EMail: Tom.George@Alcatel.com Alcatel EMail: Tom.George@Alcatel.com
3400 West Plano Parkway 3400 West Plano Parkway
Plano, TX 75075 Plano, TX 75075
USA USA
Brian Bidulock Tel +1-780-490-1141 Brian Bidulock Telephone: +1-780-490-1141
OpenSS7 Corporation EMail: bidulock@openss7.org OpenSS7 Corporation EMail: bidulock@openss7.org
1469 Jeffreys Crescent 1469 Jeffreys Crescent
Edmonton, AB T6L 6T1 Edmonton, AB T6L 6T1
Canada Canada
Ram Dantu, Ph.D. Tel: +1-940-565-2822 Ram Dantu, Ph.D. Telephone: +1-940-565-2822
Assistant Professor EMail: rdantu@unt.edu Assistant Professor EMail: rdantu@unt.edu
Department of Computer Science Department of Computer Science
University of North Texas University of North Texas
Denton, TX 76203 Denton, TX 76203
USA USA
Hanns Juergen Schwarzbauer Tel: +49-89-722-24236 Hanns Juergen Schwarzbauer Telephone: +49-89-722-24236
SIEMENS AG EMail: HannsJuergen.Schwarzbauer@icn.siemens.de SIEMENS AG EMail: HannsJuergen.Schwarzbauer@Siemens.com
Hofmannstr. 51 Hofmannstr. 51
81359 Munich 81359 Munich
Germany Germany
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Telephone: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA 20171 Herndon, VA 20171
USA USA
This Internet Draft expires April 2004. This Internet Draft expires July 2004.
 End of changes. 

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