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]