draft-ietf-sigtran-m2pa-12.txt   draft-ietf-sigtran-m2pa-13.txt 
Network Working Group Tom George Network Working Group Tom George
INTERNET-DRAFT Alcatel INTERNET-DRAFT 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 December 2004 June 16, 2004 Expires August 2005 February 18, 2005
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User
Peer-to-Peer Adaptation Layer (M2PA) Peer-to-Peer Adaptation Layer (M2PA)
<draft-ietf-sigtran-m2pa-12.txt> <draft-ietf-sigtran-m2pa-13.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 1, line 47 skipping to change at page 1, line 46
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Intellectual Property Notice
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668.
Abstract Abstract
This Internet Draft defines a protocol supporting the transport of This Internet Draft defines a protocol supporting the transport of
Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
signaling messages over Internet Protocol (IP) using the services of signaling messages over Internet Protocol (IP) using the services of
the Stream Control Transmission Protocol (SCTP). This protocol would the Stream Control Transmission Protocol (SCTP). This protocol would
be used between SS7 Signaling Points using the MTP Level 3 be used between SS7 Signaling Points using the MTP Level 3
protocol. The SS7 Signaling Points may also use standard SS7 links protocol. The SS7 Signaling Points may also use standard SS7 links
using the SS7 MTP Level 2 to provide transport of MTP Level 3 using the SS7 MTP Level 2 to provide transport of MTP Level 3
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.....................11 1.9 Differences Between M2PA and M2UA.....................11
2. Protocol Elements........................................13 2. Protocol Elements........................................14
2.1 Common Message Header.................................13 2.1 Common Message Header.................................14
2.2 M2PA Header...........................................14 2.2 M2PA Header...........................................15
2.3 M2PA Messages.........................................15 2.3 M2PA Messages.........................................16
3. State Control............................................18 3. State Control............................................20
3.1 SCTP Association State Control........................18 3.1 SCTP Association State Control........................20
3.2 M2PA Link State Control...............................19 3.2 M2PA Link State Control...............................21
4. Procedures...............................................20 4. Procedures...............................................22
4.1 Procedures to Support MTP2 Features...................20 4.1 Procedures to Support MTP2 Features...................22
4.2 Procedures to Support the MTP3/MTP2 Interface.........31 4.2 Procedures to Support the MTP3/MTP2 Interface.........33
4.3 SCTP Considerations...................................35 4.3 SCTP Considerations...................................37
5. Examples of M2PA Procedures..............................36 5. Examples of M2PA Procedures..............................38
5.1 Link Initialization (Alignment).......................36 5.1 Link Initialization (Alignment).......................38
5.2 Message Transmission and Reception....................39 5.2 Message Transmission and Reception....................41
5.3 Link Status Indication................................39 5.3 Link Status Indication................................41
5.4 Link Status Message (Processor Outage)................40 5.4 Link Status Message (Processor Outage)................42
5.5 Level 2 Flow Control..................................44 5.5 Level 2 Flow Control..................................46
5.6 MTP3 Signaling Link Congestion........................46 5.6 MTP3 Signaling Link Congestion........................48
5.7 Link Deactivation.....................................47 5.7 Link Deactivation.....................................48
5.8 Link Changeover.......................................48 5.8 Link Changeover.......................................49
6. Security.................................................50 6. Security.................................................50
7. IANA Considerations......................................51 7. IANA Considerations......................................50
7.1 SCTP Payload Protocol Identifier......................51 7.1 SCTP Payload Protocol Identifier......................50
7.2 M2PA Protocol Extensions..............................51 7.2 M2PA Protocol Extensions..............................51
8. Acknowledgements.........................................54 8. Acknowledgements.........................................54
9. References...............................................54 9. References...............................................54
9.1 Normative..............................................54 9.1 Normative..............................................54
9.2 Informative............................................56 9.2 Informative............................................56
10. Author's Addresses.......................................57 10. Author's Addresses.......................................57
11. Full Copyright Statement.................................58 11. Full Copyright Statement.................................58
1. Introduction 1. Introduction
skipping to change at page 42, line 4 skipping to change at page 43, line 58
them. A may continue transmitting messages from MTP3, and them. A may continue transmitting messages from MTP3, and
acknowledging messages that were received before LPO. acknowledging messages that were received before LPO.
. . . . . . . . . . . .
. User Data FSN=4 BSN=13 . . . . User Data FSN=4 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
. User Data FSN=5 BSN=13 . . . . User Data FSN=5 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
. User Data FSN=6 BSN=13 . . . . User Data FSN=6 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
. . . . . .
While in RPO, B may continue acknowledging messages. Suppose that B While in RPO, B may continue acknowledging messages. Suppose that B
receives message 4, but has not processed 5 and 6 yet. receives message 4, but has not processed 5 and 6 yet.
. . . . . . . . . . . .
. (empty) User Data FSN=16 BSN=4 . (empty) User Data FSN=16 BSN=4
. <------------------------------------ . . <------------------------------------ .
LPO ends at A. A flushes 14-16 (the messages that were buffered LPO ends at A. A flushes 14-16 (the messages that were buffered
without acknowledgement). without acknowledgement).
skipping to change at page 43, line 4 skipping to change at page 44, line 55
B should discard any incoming acknowledgements at this point. They B should discard any incoming acknowledgements at this point. They
could have been sent before B's LS Ready. could have been sent before B's LS Ready.
A can use the Link Status Ready information to resynchronize its A can use the Link Status Ready information to resynchronize its
sequence numbers to begin with FSN=6 for the next User Data message. sequence numbers to begin with FSN=6 for the next User Data message.
. . . . . . . . . . . .
. LS Ready FSN=5 BSN=13 . . . . LS Ready FSN=5 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
B can use this information to resynchronize its sequence numbers to B can use this information to resynchronize its sequence numbers to
begin with FSN=14. Each side can resume sending User Data: begin with FSN=14. Each side can resume sending User Data:
. . . . . . . . . . . .
Message for . . . Message for Message for . . . Message for
transmission . . transmission transmission . . transmission
------------> . . <------------ ------------> . . <------------
. User Data FSN=6 BSN=13 . . . . User Data FSN=6 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
skipping to change at page 50, line 23 skipping to change at page 50, line 23
- the network providers - the network providers
- the applications involved - the applications involved
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.
Consult [Security] for a discussion of security requirements and for Consult [RFC3788] for a discussion of security requirements and for
guidance on the use of security protocols. Implementers of M2PA MUST guidance on the use of security protocols. Implementers of M2PA MUST
follow the guidelines in [Security]. follow the guidelines in [RFC3788].
When M2PA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site Security
Handbook" [RFC2196] SHOULD be consulted for guidance.
7. IANA Considerations 7. IANA Considerations
7.1 SCTP Payload Protocol Identifier 7.1 SCTP Payload Protocol Identifier
The SCTP Registered User Port Number Assignment for M2PA is 3565. The The SCTP Registered User Port Number Assignment for M2PA is 3565. The
TCP Registered User Port Number 3565 is also assigned to M2PA, in case TCP Registered User Port Number 3565 is also assigned to M2PA, in case
a specification for M2PA over TCP is created. a specification for M2PA over TCP is created.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
skipping to change at page 55, line 27 skipping to change at page 55, line 27
[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).
[RFC2196]
B. Y. Frazer, "Site Security Handbook," RFC 2196, Internet
Engineering Task Force (September 1997).
[RFC2434] [RFC2434]
T. Narten, H. T. Alvestrand, "Guidelines for Writing an IANA T. Narten, H. T. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," BCP 26, RFC 2434, The Internet Considerations Section in RFCs," BCP 26, RFC 2434, The Internet
Society (October, 1998). Society (October, 1998).
[RFC2960] [RFC2960]
R. Stewart, et. al., "Stream Control Transmission Protocol R. Stewart, et. al., "Stream Control Transmission Protocol
(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] [RFC3788]
J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security
Considerations for SIGTRAN Protocols," Considerations for Signaling Transport (SIGTRAN) Protocols,"
draft-ietf-sigtran-security-03.txt (June 2003), Work in RFC 3788, The Internet Society (June 2004).
Progress.
[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-2001, American National Standards Institute ANSI T1.111-2001, American National Standards Institute
(February 2001). (February 2001).
9.2 Informative 9.2 Informative
[M2UA] [M2UA]
skipping to change at page 57, line 7 skipping to change at page 57, line 7
ITU, "Implementors' guide (version 09/97) for Q.705 (03/93)" ITU, "Implementors' guide (version 09/97) for Q.705 (03/93)"
ITU-T Recommendation Q.Imp705, ITU-T Telecommunication ITU-T Recommendation Q.Imp705, ITU-T Telecommunication
Standardization Sector of ITU (September 1997). 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 Telephone: +1-972-519-3168 Tom George Telephone: +1-972-985-4594
Alcatel EMail: Tom.George@Alcatel.com Plano, TX EMail: tgeorge_tx@verizon.net
3400 West Plano Parkway
Plano, TX 75075
USA USA
Brian Bidulock Telephone: +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. Telephone: +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
skipping to change at page 58, line 7 skipping to change at page 58, line 7
Germany Germany
Ken Morneault Telephone: +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
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
skipping to change at page 58, line 49 skipping to change at page 58, line 49
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
This Internet Draft expires December 2004. This Internet Draft expires August 2005.
 End of changes. 

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