Internet DRAFT - draft-chen-sigtran-m2pa-revision
draft-chen-sigtran-m2pa-revision
SIGTRAN Chen Xu
Internet Draft Zhang Hao
Intended status: Informational Duan Xiaodong
Expires: May 2008 China Mobile
November 13, 2007
The proposal of revision to procedure description in RFC4165
draft-chen-sigtran-m2pa-revision-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Chen,Zhang,Duan Expires May 13, 2008 [Page 1]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
According to the conclusion of problem statement for RFC4165, an
amendment of M2PA is needed. This document gives the suggested list
of the contents to be revised and supplemented describes the reason
to change and supplement ,and provides a proposal for revision.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction......................................... 2
1.1. Scope.......................................... 3
2. Conventions ......................................... 3
3. Clarifications and supplements ........................ 3
3.1. Update Section 4.1.3 Link Alignment procedure ......... 3
3.2. Update Section 4.1.4 Processor Outage................ 5
3.3. Update section 4.2.1 Sending and Receiving Messages .... 7
3.4. Delete Section 4.2.3.1 Multiple User Data Streams and
Changeover......................................... 10
3.5. Supplement the definition and range of M2PA Timers.... 10
4. Security Considerations............................... 11
5. IANA Considerations.................................. 11
6. Conclusions ........................................ 11
7. Acknowledgments..................................... 11
8. References......................................... 12
8.1. Normative References............................. 12
8.2. Informative References........................... 12
Author's Addresses..................................... 12
Intellectual Property Statement .......................... 12
Disclaimer of Validity.................................. 13
1. Introduction
RFC 4165 defines a protocol for supporting the transport of SS7 MTP3
Level 3 signaling messages over IP using the services of the Stream
Control Transmission Protocol between SS7 Signaling Points using the
MTP Level 3 protocol. During implementation and interoperability test
Chen,Zhang,Duan Expires May 13, 2008 [Page 2]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
of RFC 4165, some ambiguities and common misinterpretations have been
identified.
This document summarizes identified issues and provides
clarifications needed for implementations of RFC 4165 interoperate,
and also makes supplement to RFC 4165.
1.1. Scope
1) Supplement the phases description, the correlated messages and
Timers of Link Alignment procedure.
2) Supplement the whole idea of Processor Outage procedure, and
describe the rules of LPO and RPO processing separately.
3) Supplement the rules of usage of FSN and BSN in M2PA Header.
4) Supplement the definition and range of M2PA Timers.
2. Conventions
In this document, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL
NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and
OPTIONAL are to be interpreted as described in [RFC2119].
3. Clarifications and supplements
3.1. Update Section 4.1.3 Link Alignment procedure
(Note: Updating this section by supplementing the phases description,
the correlated messages and Timers of Link Alignment procedure.)
The purposes of the alignment procedure are:
(1) To provide a handshaking procedure so that both endpoints are
prepared to send SS7 traffic, and to prevent traffic from being sent
before the other end is ready.
(2) To verify that the SCTP association is suitable for use as an SS7
link.
Link initialization procedure contains 3 phases: Alignment, Proving
and In Service;and relates to Timer T1/T2/T3/T4.
1) The Link initialization-alignment
Chen,Zhang,Duan Expires May 13, 2008 [Page 3]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
Link alignment takes place after the association is established. If
SCTP fails to establish the association, and M2PA has received a
Start Request from its MTP3, then M2PA SHALL report to MTP3 that the
link is out of service.
After the association is established, before link alignment starts,
M2PA SHALL send a Link Status Out of Service message to its peer. The
Link Status Out of Service message replaces the SIOS message of MTP2.
Unlike MTP2, the message SHOULD NOT be transmitted continuously.
Sending additional Link Status Out of Service messages is not allowed.
After the association is established, and M2PA has received a Start
Request from its MTP3, then M2PA SHALL start link alignment. Link
Status Alignment message is sent to signal the beginning of the
alignment. This message replaces the SIO message of MTP2. The Link
Status Alignment message SHOULD NOT be transmitted continuously.
Sending additional Link Status Alignment messages is not allowed.
After sending Link Status Alignment message, M2PA start T2, until it
receives Link Status Alignment, Link Status Proving Normal, or Link
Status Proving Emergency from the peer.M2PA stops T2 and starts
Proving procedure when receives one of these three messages during T2
is running. When T2 expires, M2PA SHALL report to MTP3 that the link
is out of service and send a Link Status Out of Service message to
its peer.
2) The Link initialization-proving
The proving procedure is Mandatory to adapt to SCTP Slow Start.
When starts alignment, if none of the links in the linkset is in
service, M2PA SHOULD perform emergency proving; otherwise, M2PA
SHOULD perform normal proving.
When performs normal proving, M2PA Should send a Link Status Proving
Normal message to its peer and start T3.During the T3 is running, if
a Link Status Proving Normal message is received, then stops T3,
starts T4n, and M2PA SHALL send Link Status Proving Normal messages
to its peer at an interval defined by the protocol parameter
Proving_Interval; if a Link Status Proving Emergency message is
received, then stops T3, starts T4e,and still send Link Status
Proving Normal messages to its peer at an interval defined by the
protocol parameter Proving_Interval.
When performs emergency proving, M2PA Should send a Link Status
Proving Emergency message to its peer and start T3.During the T3 is
running, if a Link Status Proving Emergency message is received, then
Chen,Zhang,Duan Expires May 13, 2008 [Page 4]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
stops T3, starts T4e, and M2PA SHALL send Link Status Proving
Emergency messages to its peer at an interval defined by the protocol
parameter Proving_Interval; if a Link Status Proving Normal message
is received, does the same.
The requirement that Link Status Proving messages during the proving
period is comparable to the normal traffic load expected when the
link is in service is unnecessary.
During the T3 is running, if a Link Status Out Of Service message is
received, M2PA SHALL stop T3, report to MTP3 that the link is out of
service and send a Link Status Out of Service message to its peer.
During the T3 is running, if a Stop Request from its MTP3 is received,
M2PA SHALL stops T3, report to MTP3 that the link is out of service
and send a Link Status Out of Service message to its peer.
When T3 expires, M2PA SHALL report to MTP3 that the link is out of
service and send a Link Status Out of Service message to its peer.
3) In Service
During the T4 is running, if a Link Status Alignment message is
received, M2PA SHALL restart T3 and wait for a proving message sent
from its peer.
When T4 expires(ie the proving is ending), M2PA SHALL send a Link
Status Ready message to its peer and start T1,wait for a Ready
message sent from its peer.
The Link Status Ready message is used to verify that both ends have
completed proving. The Link Status Ready message is sent on the Link
Status stream.
During the T1 is running, if a Link Status Ready message or a User
Data message is received, M2PA SHALL stop T1, report to MTP3 that the
link is in service.
3.2. Update Section 4.1.4 Processor Outage
(Note: Updating this section by describing the rules of LPO and RPO
processing separately, and supplement a requirement for RPO.)
The Link Status Processor Outage message replaces the SIPO message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where
Chen,Zhang,Duan Expires May 13, 2008 [Page 5]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists. The Link Status
Processor Outage message SHALL be sent on the User Data stream.
1) Local Processor Outage (LPO)
While in a local processor outage (LPO) condition:
(a) Any User Data messages received from the peer MUST NOT be
acknowledged and MUST be buffered.
(b) M2PA SHOULD continue to acknowledge User Data messages
received and accepted by MTP3 before the local processor outage.
(c) M2PA SHOULD continue to transmit messages that have been sent
by its upper layer MTP3.
When the local processor outage condition ends, M2PA SHALL send a
Link Status Processor Recovered message to its peer on the User Data
stream. This message is used to signal the end of the processor
outage condition, instead of an MSU or FISU, as is used in MTP2. The
BSN in the Link Status Processor Recovered message is set to the FSN
of the last User 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 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.
When M2PA experiences a local processor outage, it MAY put the link
out of service by sending a Link Status Out of Service message.
1) Remote Processor Outage (RPO)
While there is a remote processor outage (RPO) condition:
(a) M2PA SHOULD continue to acknowledge User Data messages
received and accepted by MTP3, regardless of the remote processor
outage.
(b) If any User Data messages received from the peer after the
Link Status Processor Outage cannot be delivered to MTP3, then these
messages MUST NOT be acknowledged and MUST be buffered.
Chen,Zhang,Duan Expires May 13, 2008 [Page 6]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
(c) M2PA SHALL cease transmitting User Data messages after
receiving a Link Status Processor Outage message from its peer.
Upon receiving the Link Status Processor Recovered message, the M2PA
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 the last User Data message received (and not discarded) from
the peer M2PA.
When LPO or RPO is recovered, MTP3 will send Flush or Continue
command to M2PA at once.
If M2PA receives a Flush command from MTP3,
(a) M2PA SHALL discard any incoming messages that were queued and
unacknowledged during the processor outage condition.
(b) M2PA SHALL discard messages in the transmit and retransmit
queues as required by MTP2.
If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged
during the processor outage condition.
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 this is required by MTP2. M2PA SHALL NOT resume
transmitting User Data messages until it has sent the Link Status
Ready message.
During resynchronization, M2PA SHALL NOT discard any received User
Data messages that were sent after the processor outage ended. In
other respects, M2PA SHOULD follow the same procedures as MTP2 in
processor outage.
3.3. Update section 4.2.1 Sending and Receiving Messages
(Note: Updating this section by supplementing the rules of usage of
FSN and BSN in M2PA Header and amending the description of T7 timer.)
When MTP3 sends a message for transmission to M2PA, M2PA passes the
corresponding M2PA message to SCTP using the SEND primitive.
User Data messages SHALL be sent via the User Data stream (stream 1)
of the association.
Chen,Zhang,Duan Expires May 13, 2008 [Page 7]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
M2PA Link Status messages are passed to SCTP using the SEND primitive.
The following Link Status messages SHALL be sent on the Link Status
stream (stream 0):
- Alignment
- Proving Normal
- Proving Emergency
- Ready (when sent during alignment)
- Busy
- Busy Ended
- Out of Service
The following Link Status messages SHALL be sent on the User Data
stream (stream 1):
- Processor Outage
- Processor Recovered
- Ready (when sent at the end of processor outage)
If M2PA receives a message from SCTP with an invalid Message Class or
unsupported Message Type in the Common Message Header, M2PA SHALL
discard the message.
After the link is in service, the FSN of the first User data message
sent in this link SHALL be 0.
The FSN and BSN of the sending messages SHALL apply the following
rules
1) During alignment, the FSN and BSN of the Link status messages
SHOULD be 0xFFFFFF.
2) After the link is in service, the FSN of the first empty User data
message sent in this link SHALL be 0.When a User data message is sent,
the FSN is incremented by 1 When FSN and BSN reach the maximum, they
will be back to 0.
Chen,Zhang,Duan Expires May 13, 2008 [Page 8]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
3) After the link is in service, the FSN of a Link status message
SHOULD be the FSN of the last User data message sent.
4 After the link is in service, the FSN of an empty User Data
message SHOULD be the FSN of the last User data message sent.
The process of the FSN and BSN of the received messages SHALL apply
the following rules
1) During alignment, the FSN and BSN of Link status messages SHOULD
be 0xFFFFFF.If not, discards the messages.
2) After the link is in service, the FSNs and BSNs of Link status
messages SHOULD NOT be judged.Just accepts the messages.
3) After the link is in service, the FSNs of User Data messages and
empty User Data messages SHOULD be judged. If FSN is invalid
(missequence), then discards the message; otherwise, judges the BSN
of the message. If it's the valid BSN or the first invalid BSN, then
accepts the message with the FSN and BSN. When continuously receives
two messages with valid FSNs and invalid BSNs, M2PA SHALL report to
MTP3 that the link is out of service and send a Link Status Out of
Service message to its peer.
For message types other than User Data, the Forward Sequence Number
is set to the FSN of the last User Data message sent.
When there is a message to acknowledge, M2PA MUST acknowledge the
message with the next User Data message sent. If there is no User
Data message available to be sent when there is a message to
acknowledge, M2PA SHOULD generate and send a User Data message with
no data payload, without delay. (In other words, in the case where
MTP2 would acknowledge a message with a FISU, M2PA SHOULD acknowledge
the message with an empty User Data message.) The FSN for this empty
User Data message is not incremented. It MUST contain the same FSN as
the most recently sent User Data message that contains data. Delaying
of acknowledgements can result in poor SS7 performance.
If M2PA receives an empty User Data message, it SHALL NOT send an
acknowledgement of that message.
Note that there is no reason to place Link Status messages or empty
User Data messages in the M2PA retransmit buffer, since these
messages are not retrieved for changeover and timer T7 does not apply
to them.
Chen,Zhang,Duan Expires May 13, 2008 [Page 9]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
Note that since SCTP provides reliable delivery and ordered delivery
within the stream, M2PA does not perform retransmissions.
Nevertheless, M2PA SHALL retain transmitted User Data messages in a
retransmit queue until they are acknowledged. These messages are
needed in case MTP3 performs data retrieval as part of a changeover
procedure.
Because propagation delays in IP networks are more variable than in
traditional SS7 networks, T7 timer (excessive delay of
acknowledgement) SHOULD be set according to many factors, such as
propagation delays in IP networks, acknowledgement method on
reception of SCTP DATA Chunk, SCTP slow start method, the size of
M2PA transmission buffer and the Timers of upper applications.
3.4. Delete Section 4.2.3.1 Multiple User Data Streams and Changeover
3.5. Supplement the definition and range of M2PA Timers
MTP2 defines following Timers to make sure procedures running in good
order.
M2PA uses the same Timers in MTP2.The default value and range of
these Timers are as follows.
T1 Timer "alignment ready" 40-50 s
T2 Timer "not aligned"= 5-150 s
T3 Timer "aligned"= 1-2 s
T4 Proving period timer
T4n = 7.5-9.5 s Normal proving period, Nominal value 8.2 s
T4e = 400-600 ms Emergency proving period, Nominal value 500 ms
T5 Timer "sending Busy" = 80-120 ms
T6 Timer "remote congestion" =3-6 s
T7 Timer "excessive delay of acknowledgement" =1-7s
The definitions of above Timers refere to Q.703.
Chen,Zhang,Duan Expires May 13, 2008 [Page 10]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
4. Security Considerations
Implementations MUST follow the normative guidance of RFC4165 on the
integration and usage of security mechanisms in SIGTRAN protocol.
5. IANA Considerations
This document contains no new actions for IANA.
6. Conclusions
This document provides some clarifications that is needed for the
implementation of the RFC4165.
7. Acknowledgments
The authors wish to thank Zhao Yuyi, Peng Jin, Zhang Juan, and many
others for their invaluable comments.
Chen,Zhang,Duan Expires May 13, 2008 [Page 11]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] T. George, et al, "Signaling System 7 (SS7) Message Transfer
Part 2 (MTP2) -User Peer-to-Peer Adaptation Layer (M2PA)
",RFC4165, September 2005
8.2. Informative References
[4] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583.
Author's Addresses
Chen Xu
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3163
Email: chenxu@chinamobile.com
Zhang Hao
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3281
Email: zhanghao@chinamobile.com
Duan Xiaodong
China Mobile
53A XiBianMennei Ave, XuanWu District, Beijing, China
Phone: 86 10 66006688 3062
Email: duanxiaodong@chinamobile.com
Intellectual Property Statement
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
Chen,Zhang,Duan Expires May 13, 2008 [Page 12]
Internet-Draft Proposal for RFC4165(M2PA) Revision November 2007
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.
Disclaimer of Validity
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, THE IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chen,Zhang,Duan Expires May 13, 2008 [Page 13]
