draft-ietf-sigtran-m2pa-11.txt   draft-ietf-sigtran-m2pa-12.txt 
skipping to change at page 1, line 14 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 July 2004 January 29, 2004 Expires December 2004 June 16, 2004
SS7 MTP2-User Peer-to-Peer Adaptation Layer Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User
<draft-ietf-sigtran-m2pa-11.txt> Peer-to-Peer Adaptation Layer (M2PA)
<draft-ietf-sigtran-m2pa-12.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 2, line 5 skipping to change at page 1, line 45
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
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 (C) The Internet Society (2004). All Rights Reserved.
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
signaling messages. The protocol operates in a manner similar to MTP signaling messages. The protocol operates in a manner similar to MTP
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............................. 9 1.6 Services Provided by M2PA............................. 8
1.7 Functions Provided by M2PA............................10 1.7 Functions Provided by M2PA............................ 9
1.8 Definition of the M2PA Boundaries.....................11 1.8 Definition of the M2PA Boundaries.....................10
1.9 Differences Between M2PA and M2UA.....................11 1.9 Differences Between M2PA and M2UA.....................11
2. Protocol Elements........................................13 2. Protocol Elements........................................13
2.1 Common Message Header.................................13 2.1 Common Message Header.................................13
2.2 M2PA Header...........................................14 2.2 M2PA Header...........................................14
2.3 M2PA Messages.........................................15 2.3 M2PA Messages.........................................15
3. State Control............................................19 3. State Control............................................18
3.1 SCTP Association State Control........................19 3.1 SCTP Association State Control........................18
3.2 M2PA Link State Control...............................20 3.2 M2PA Link State Control...............................19
4. Procedures...............................................21 4. Procedures...............................................20
4.1 Procedures to Support MTP2 Features...................21 4.1 Procedures to Support MTP2 Features...................20
4.2 Procedures to Support the MTP3/MTP2 Interface.........32 4.2 Procedures to Support the MTP3/MTP2 Interface.........31
4.3 SCTP Considerations...................................36 4.3 SCTP Considerations...................................35
5. Examples of M2PA Procedures..............................37 5. Examples of M2PA Procedures..............................36
5.1 Link Initialization (Alignment).......................38 5.1 Link Initialization (Alignment).......................36
5.2 Message Transmission and Reception....................40 5.2 Message Transmission and Reception....................39
5.3 Link Status Indication................................40 5.3 Link Status Indication................................39
5.4 Link Status Message (Processor Outage)................41 5.4 Link Status Message (Processor Outage)................40
5.5 Level 2 Flow Control..................................45 5.5 Level 2 Flow Control..................................44
5.6 MTP3 Signaling Link Congestion........................47 5.6 MTP3 Signaling Link Congestion........................46
5.7 Link Deactivation.....................................47 5.7 Link Deactivation.....................................47
5.8 Link Changeover.......................................48 5.8 Link Changeover.......................................48
6. Security.................................................49 6. Security.................................................50
6.1 Security Requirements.................................49 7. IANA Considerations......................................51
6.2 Protecting Confidentiality............................49 7.1 SCTP Payload Protocol Identifier......................51
7. IANA Considerations......................................50 7.2 M2PA Protocol Extensions..............................51
7.1 SCTP Payload Protocol Identifier......................50 8. Acknowledgements.........................................54
7.2 M2PA Protocol Extensions..............................50 9. References...............................................54
8. Acknowledgements.........................................53 9.1 Normative..............................................54
9. References...............................................53 9.2 Informative............................................56
9.1 Normative..............................................53 10. Author's Addresses.......................................57
9.2 Informative............................................55 11. Full Copyright Statement.................................58
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 28, line 31 skipping to change at page 27, line 31
If M2PA receives a Continue command from MTP3, M2PA SHALL begin If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged processing the incoming messages that were queued and unacknowledged
during the processor outage condition. during the processor outage condition.
When the local processor outage condition ends, M2PA SHALL send a Link When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer on the User Data Status Processor Recovered message to its peer on the User Data
stream. This message is used to signal the end of the processor outage stream. This message is used to signal the end of the processor outage
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. M2PA
SHALL cease transmitting User Data messages after sending the Link
Status Processor Recovered message, until it has received the Link
Status Ready message (see below).
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 Upon receiving the Link Status Ready message, the M2PA formerly in LPO
SHALL respond with a Link Status Ready message on the User Data 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
skipping to change at page 45, line 7 skipping to change at page 44, line 7
. User Data FSN=6 BSN=13 . . . . User Data FSN=6 BSN=13 . . .
. ------------------------------------> . . ------------------------------------> .
. . . User Data FSN=14 BSN=5 . . . . User Data FSN=14 BSN=5 .
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
Figure 16. Example: Processor Outage and Recovery Figure 16. Example: Processor Outage and Recovery
5.5 Level 2 Flow Control 5.5 Level 2 Flow Control
Figures 16 and 17 illustrate the Level 2 Flow Control procedure. In Figures 17 and 18 illustrate the Level 2 Flow Control procedure. In
Figure 16, congestion ceases before timer T6 expires. Figure 17 shows Figure 17, congestion ceases before timer T6 expires. Figure 18 shows
the case where T6 expires. the case where T6 expires.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . determination of M2PA . .
. receive congestion onset . . . receive congestion onset . .
. . . . . . . . . . . .
. Link Status Busy . . . . Link Status Busy . . .
skipping to change at page 47, line 7 skipping to change at page 46, line 7
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
. . . . Out of Service . . . . Out of Service
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
Figure 18. Example: Level 2 Flow Control - Timer T6 Expires Figure 18. Example: Level 2 Flow Control - Timer T6 Expires
5.6 MTP3 Signaling Link Congestion 5.6 MTP3 Signaling Link Congestion
In Figure 18, M2PA notifies MTP3 of congestion onset and In Figure 19, M2PA notifies MTP3 of congestion onset and
abatement. The notification includes the congestion level, if there abatement. The notification includes the congestion level, if there
are levels of congestion defined. are levels of congestion defined.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . . determination of M2PA . . .
. transmit congestion . . . . transmit congestion . . .
. onset (level) . . . . onset (level) . . .
skipping to change at page 47, line 37 skipping to change at page 47, line 7
. . . . . . . . . . . .
Congestion Indication . . . . Congestion Indication . . . .
(level) . . . . . (level) . . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 19. Example: MTP3 Signalling Link Congestion Figure 19. Example: MTP3 Signalling Link Congestion
5.7 Link Deactivation 5.7 Link Deactivation
Figure 19 shows an example of link deactivation. MTP3 can request that Figure 20 shows an example of link deactivation. MTP3 can request that
a link be taken out of service. a link be taken out of service.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
Stop . . . . . Stop . . . . .
------------> . . . . ------------> . . . .
. . . . . . . . . . . .
. Link Status Out of Service . . . Link Status Out of Service . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
Out of Service . . . . Out of Service . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 20. Example: Link Deactivation Figure 20. Example: Link Deactivation
5.8 Link Changeover 5.8 Link Changeover
In Figure 20, MTP3 performs a changeover because the link went out of In Figure 21, MTP3 performs a changeover because the link went out of
service. MTP3 selects a different link to retransmit the service. MTP3 selects a different link to retransmit the
unacknowledged and unsent messages. unacknowledged and unsent messages.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Communication Lost . . . . Communication Lost . . .
. <------------ . . . . <------------ . . .
. . . . . . . . . . . .
Out of Service . . . . Out of Service . . . .
skipping to change at page 49, 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.
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. Implementers of M2PA MUST guidance on the use of security protocols. Implementers of M2PA MUST
follow the guidelines in [Security]. 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
Particularly for wireless users, the requirement for confidentiality
MAY include the masking of IP addresses and ports. In this case
application-level encryption is not sufficient. IPSec ESP SHOULD be
used instead [RFC2401]. Regardless of which level performs the
encryption, the IPSec ISAKMP service SHOULD be used for key
management.
7. IANA Considerations 7. IANA Considerations
7.1 SCTP Payload Protocol Identifier 7.1 SCTP Payload Protocol Identifier
The SCTP (and TCP) Registered User Port Number Assignment for M2PA The SCTP Registered User Port Number Assignment for M2PA is 3565. The
is 3565. TCP Registered User Port Number 3565 is also assigned to M2PA, in case
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
SCTP Payload Data chunk is SCTP Payload Data chunk is
M2PA 5 M2PA 5
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
skipping to change at page 54, line 31 skipping to change at page 55, line 31
[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] [RFC2196]
B. Y. Frazer, "Site Security Handbook," RFC 2196, Internet B. Y. Frazer, "Site Security Handbook," RFC 2196, Internet
Engineering Task Force (September 1997). Engineering Task Force (September 1997).
[RFC2401]
S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol," RFC 2401, Internet Engineering Task Force (November
1998).
[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] [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-03.txt (June 2003). draft-ietf-sigtran-security-03.txt (June 2003), Work in
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 56, line 38 skipping to change at page 58, line 5
Hofmannstr. 51 Hofmannstr. 51
81359 Munich 81359 Munich
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
This Internet Draft expires July 2004. 11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
This Internet Draft expires December 2004.
 End of changes. 

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