INTERNET-DRAFT Kamesh Kaul[EDITOR] Hughes Software Systems Issued: Jan 2002 Expires: Jul 2003 M3UA Congestion procedures Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 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. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Kamesh Kaul, HSS [Page 1] Internet Draft M3UA Congestion Procedures Jan 2003 Abstract This Internet-Draft describes congestion procedures applicable for both M3UA [2] ASP and SG nodes. Draft explains all the procedures needed by M3UA [2] ASP and SG to handle local and network congestion communicated between M3UA [2] SG and ASP through SSNM messages. Congestion procedures proposed are in line with MTP3 Q.704 with some alteration to suit sigtran architecture. TABLE OF CONTENTS 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . . 3 1.3 Conventions. . . . . . . . . . . . . . . . . . . . . . 3 1.4 Overview . . . . . . . . . . . . . . . . . . . . . . . 3 2. Congestion handling at M3UA [2] ASP . . . . . . . . . . . . 4 2.1 Handling local node congestion . . . . . . . . .. . . 4 2.2 Handling SCON messages . . . . . . . . . . . . . . . . 5 2.2.1 International/National-networks-without-priority 5 2.2.2 National-networks-with-priority . . . . . . . . 5 2.2.2.1 Congestion provisioning without timer. . . 5 2.2.2.2 Congestion provisioning with timer. . . . .6 2.3 Handling of MTP3 user messages . . . . . . . . . . . . 7 2.4 Generation of SCON messages. . . . . . . . . . . . . . 8 3. Congestion handling at M3UA [2] SGP . . . . . . . . . . . . 8 3.1 Handling local node congestion. . . . . . . . . . . . .8 3.2 Handling SCON messages. . . . . . . . . . . . . . . . .9 3.2.1 International/National-networks-without-priority 9 3.2.2 National-networks-with-priority . . . . . . . . 10 3.3 Handling of NIF/local-user messages. . . . . . . . . . 12 4. Examples of network congestion . . . . . . . . . . . . . . .14 4.1 ASP network congestion with multiple SG's . . . . . . .14 4.2 ASP network congestion abatement with multiple SG's . .15 4.3 SGP network congestion with multiple AS's . . . . . . .16 5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 17 6. References. . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1 Normative References . . . . . . . . . . . . . . . . . 17 6.2 Informative References . . . . . . . . . . . . . . . . 17 7. Author's Addresses. . . . . . . . . . . . . . . . . . . . . 17 Kamesh Kaul, HSS [Page 2] Internet Draft M3UA Congestion Procedures Jan 2003 1. Introduction 1.1. Scope This Internet-Draft describes congestion procedures, which are necessary for M3UA [2] ASP and SG nodes to handle both local node congestion and network congestion communicated to M3UA ASP or SG nodes via SSNM messages. This draft proposes congestion procedures, which makes M3UA [2] ASP and SG nodes handle congestion in line with MTP3(Q.704) specified congestion procedures with some alterations. 1.2. Terminology M3UA congestion draft uses the terminology used in the M3UA RFC[3332]. 1.3. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3]. 1.4 Overview The purpose of this draft is to propose congestion procedures applicable for M3UA ASP and SG nodes in the same lines as suggested by MTP3 (Q.704) with some variations. By following MTP3 congestion procedures congestion handling will be done in similar fashion across the networks, no matter in which domain (SS7 or IP) node resides. This will result in effective interworking of congestion handling mechanisms between SS7 and M3UA SG/ASP nodes. Kamesh Kaul, HSS [Page 3] Internet Draft M3UA Congestion Procedures Jan 2003 2. Congestion handling at M3UA [2] ASP 2.1 Handling local node congestion M3UA ASP node undergoes congestion due to local SCTP association congestion (which is implementation dependent and may be in a way determined from current transmitting buffer occupancy of association at SCTP or M3UA level). Change in congestion status of an SCTP association may result in the congestion status update of the SG (route) which can be reached through congested association. This change in congestion status of SG may result in congestion status update of all the point codes which can be reached via congested SG. If a point code can be reached through more than one SG's, congestion status of point code is equal to the congestion level of maximum congested SG (route). Figure below shows ASP connected with two SG's SG1 (association a) and SG2 (association b).Point code X-Y-Z is reachable through both the SG's. +--+----++ assoc a | | +--- -- ----+ SG1 +-----+ | | | | | +--------+ | SS7 NODE +--+----++ | | +----------+ | | | | | PC | | ASP +-----+ +----+ X-Y-Z | | | | | | | +--------+ | | +----------+ | +--+----++ | AS:A-B-C | | | | +----------+ SG2 +------+ assoc b | | +--------+ Figure: 1 Now if "association a" undergoes congestion, congestion status of point code X-Y-Z maintained at ASP gets updated. If after some time "association b" undergoes congestion. Congestion status of point code X-Y-Z is updated if "association b" undergoes more congestion than "association a". Kamesh Kaul, HSS [Page 4] Internet Draft M3UA Congestion Procedures Jan 2003 2.2 Handling SCON messages Processing of SCON message received from SG depends on the network with which affected point codes are associated. 2.2.1 International/National-networks-without-priority If the affected point code is associated with international network, congestion level obtained from received SCON message is notified to MTP3 user parts. M3UA [2] at ASP does not retain congestion level received in SCON message. 2.2.2 National-networks-with-priority 2.2.2.1 Congestion provisioning without timer If the affected point code is associated with national network with congestion priority, M3UA at ASP updates the change in congestion status of affected point code configured at ASP. MTP3 user parts are notified, if congestion status of affected point code changes. Each user then takes appropriate actions in order to stop generation of signalling messages destined for the affected point code with congestion priorities lower than the specified congestion status. At the same time DAUD timer is started to send DAUD messages to SG as proposed by M3UA [2] rfc 3332. DAUD messages are send with affected point code to SG, until SCON message with 0 congestion level is not received from SG. Assuming no local congestion, congestion status of affected point code configured at ASP is marked non-congested when SCON with 0 congestion level is received from all the SG's which have previously send SCON message with level greater than 0. As shown in figure 2 below SCON (1) and SCON (3) messages received from SG1 and SG2 respectively for affected point code X-Y-Z results in change of congestion status to 3 for point code X-Y-Z configured at ASP. Kamesh Kaul, HSS [Page 5] Internet Draft M3UA Congestion Procedures Jan 2003 SCON (1)+--+----++ <------- | | +-----------+ SG1 +-----+ | | | | | +--------+ | SS7 NODE +--+----++ | | +----------+ | | | | | PC | | ASP +-----+ +----+ X-Y-Z | | | | | | | +--------+ | | +----------+ | +--+----++ | AS:A-B-C | | | | +----------+ SG2 +------+ <------- | | SCON(3) +--------+ Figure: 2 Point code X-Y-Z configured at ASP is marked non-congested if SCON messages with congestion level 0 is obtained from both SG's (SG1 and SG2). 2.2.2.2 Congestion provisioning with timer Alternative approach for national option with congestion priority is to provision congestion at ASP using congestion timer. In this approach congestion abatement of affected point code is entirely dependent on congestion timer expiry. When an SCON message with affected point code is received DAUD timer is started. Any SCON message received during DAUD time may update the congestion status of affected point code. After DAUD timer expiry DAUD message is send to peer SG to audit the present congestion status of the affected point code. Congestion timer is started along with DAUD timer. If SCON message with affected point code is not received till congestion timer expiry, congestion level of affected point code is decremented by 1 and the procedure starts again till congestion level of affected point code reaches 0 (no-congestion). Congestion timer is per SG similar to DAUD timer; it provisions congestion status of all the point codes reachable through a given SG. One of the advantages of this approach is that provisioning of congestion is done even if SCON messages are lost in transit from SG to ASP. Kamesh Kaul, HSS [Page 6] Internet Draft M3UA Congestion Procedures Jan 2003 Figure 3 below shows the mechanism of provisioning congestion using congestion timer. The value of congestion timer should be at least equal to round trip time between ASP and SG. ASP SG SCON (2) PC X-Y-Z Tdaud _ <---------------------- | (Cong 2) starts | | | | | | | | | | | DAUD ( PC X-Y-Z ) | Tcong Tdaud -+- ----------------------->| starts restart | | | | | | PC X-Y-Z Tcong -+- | (Cong 0) expires Figure: 3 2.3 Handling of MTP3 user messages When a message signaling unit from a local user part is received for a congested point code it is handled differently depending on the network appearance associated with the point code. If the network appearance is associated with international networks or national networks without priority following actions are performed: Data message is passed to SCTP (underlying transport layer) for transmission. An MTP-STATUS primitive will be returned to each level 4 user parts, for the initial message or alternatively after every n messages (n = 8) received for the congested point code. If the network appearance is associated with national networks with priority following is applicable: Kamesh Kaul, HSS [Page 7] Internet Draft M3UA Congestion Procedures Jan 2003 Message priority field in the data message is compared with the congestion status of the point code. If the message priority of data message is less than the congestion status of the point code data message is discarded otherwise it is send to SCTP (underlying transport layer) for transmission. On message discard MTP-STATUS indication is given to each level 4 users with the congestion level of the affected point code. 2.4 Generation of SCON messages M3UA ASP node undergoes receive congestion due to local SCTP association congestion (which is implementation dependent and may be in a way determined from current receiving buffer occupancy of association at SCTP or M3UA level).On receiving M3UA Protocol data message on congested association (receive congestion) corresponding to M3UA ASP and SGP, data handling depends on network appearance of DPC in data message: If network appearance is associated with International or national network without priority, following actions are performed: An MTP-TRANSFER indication is given to concerned user part. ASP responds with SCON message for the initial data message or alternatively after every n messages (n = 8) received on the congested association. Affected point code in SCON message is same as DPC of received data message and concerned point code being the OPC of the received data message. If network appearance is associated with national network with congestion priority, M3UA protocol data message received SHOULD be responded with SCON message if receive congestion status at ASP is greater than message priority field in M3UA protocol data message. An MTP-TRANSFER indication is given to concerned user part. 3. Congestion handling at M3UA [2] SGP 3.1 Handling local node congestion M3UA SG node undergoes congestion due to local SCTP association congestion (which is implementation dependent and may be in a way determined from current transmitting buffer occupancy of association at SCTP or M3UA level). Change in congestion status of an SCTP association may result in the congestion status update of remote ASP which can be reached through congested association. This change in congestion status of remote ASP may result in congestion status update of all the SPMC which can be reached via congested ASP. If an SPMC can be reached Kamesh Kaul, HSS [Page 8] Internet Draft M3UA Congestion Procedures Jan 2003 through more than one remote ASP's, congestion status of SPMC is equal to the congestion level of maximum congested remote ASP. Figure below shows SGP connected with two ASP's ASP1 (association a) and ASP2 (association b).ASP1 and ASP2 are serving SPMC A-B-C. AS(A-B-C) +--+----++ assoc a | | +-----------+ ASP1 + | | | | +--------+ +--+----++ | | | | | SGP +-----+ | | | +--------+ | AS(A-B-C) | +--+----++ SPMC:A-B-C | | | +-----------+ ASP2 + assoc b | | +--------+ Figure: 4 Now if "association a" undergoes congestion, congestion status of SPMC A-B-C maintained at SGP gets updated. If after some time "association b" undergoes congestion. Congestion status of SPMC A-B-C is updated if "association b" undergoes more congestion than "association a". 3.2 Handling of SCON messages Processing of SCON message received from ASP depends on the network with which affected SPMC is associated as explained below: 3.2.1 International/National-networks-without-priority If the affected SPMC is associated with international network or national network without priority, congestion level obtained from received SCON message is notified to NIF or local MTP3 user parts. M3UA at SGP does not maintain congestion level of received SCON message. SG Kamesh Kaul, HSS [Page 9] Internet Draft M3UA Congestion Procedures Jan 2003 SHOULD send TFC to convey congestion status to the concerned point code. 3.2.2 National-networks-with-priority If the affected SPMC is associated with national network with congestion priority, M3UA at SGP may update the change in congestion status of affected SPMC configured at SGP. NIF or local MTP3 user parts are notified if congestion status of affected SPMC changes. Congestion timer (Tcong) is started. If SCON message with affected SPMC is not received till congestion timer expiry congestion level of affected SPMC is decremented by one. Congestion timer is restarted and procedure continues until congestion level of affected SPMC reaches 0 (no- congestion). Congestion timer provisions congestion status of affected SPMC. As shown in figure 5 below SCON (1) and SCON (3) messages received from ASP1 and ASP2 respectively for affected SPMC A-B-C results in update of SPMC A-B-C congestion status to 3 at SGP. AS(A-B-C) SCON(1) +--+----++ <------ | | +-----------+ ASP1 + | | | | +--------+ +--+----++ | | | | | SGP +-----+ | | | +--------+ | AS(A-B-C) | +--+----++ SPMC:A-B-C | | | +-----------+ ASP2 + <------ | | SCON(3) +--------+ Figure : 5 As shown in figure 6.1 and 6.2 congestion abatement of SPMC A-B-C configured at SGP is totally dependent on congestion provisioning timer Tcong. Kamesh Kaul, HSS [Page 10] Internet Draft M3UA Congestion Procedures Jan 2003 When an SCON message with affected point code is received Tcong timer is started. Any SCON message received during Tcong time may update the congestion status of affected SPMC and congestion timer is restarted. After Tcong timer expiry congestion level of affected SPMC is decremented by 1 and congestion timer starts again till congestion level of affected SPMC reaches 0 (no-congestion). SGP ASP1 ASP2 SCON (2) SPMC A-B-C Tcong _ <------------------------+ | (cong 2) starts | | | <---------- | | | notify NIF | | | (local user) | | | | | | | | | SPMC A-B-C Tcong +- | | (cong 1) restart | | | <---------- | | | notify NIF | | | (local user) | | | | | | | | | SPMC A-B-C Tcong -+- (Cong 0) expires <--------- notify (local user) Figure 6.1 Kamesh Kaul, HSS [Page 11] Internet Draft M3UA Congestion Procedures Jan 2003 SGP ASP1 ASP2 SCON (1) SPMC A-B-C Tcong _ <------------------------+ | (cong 1) starts | | | <---------- | | | notify NIF | | | (local user) | | | | SCON (2) | | SPMC A-B-C Tcong -+-<------------------------+-----+ (cong 2) reset -+- | | <---------- (before | | | notify NIF expiry) | | | (local user | | | | | | | | | SPMC A-B-C Tcong -+- | | (Cong 1) expires | | | <--------- (restart)| | | notify NIF | | | (local user) | | | | | | | | | SPMC A-B-C Tcong -+- + + (Cong 0) expires <--------- notify (local user) Figure 6.2 3.3 Handling of NIF/local-user messages When a message signaling unit from NIF/local-user part is received for a congested SPMC it is handled differently depending on the network appearance associated with the SPMC. If the network appearance is associated with international networks or national networks without priority following actions are performed: Data message is passed to SCTP (underlying transport layer) for transmission. Kamesh Kaul, HSS [Page 12] Internet Draft M3UA Congestion Procedures Jan 2003 An MTP-STATUS primitive will be returned to NIF/local-users for the initial message or alternatively after every n messages (n = 8) received for the congested SPMC. If the network appearance is associated with national networks with priority following is applicable: The message priority field in the data message is compared with the congestion status of the concerned SPMC. If the message priority of data message is less than the congestion status of the affected SPMC data message is discarded otherwise it is send to SCTP (underlying transport layer) for transmission. On message discard MTP-STATUS indication is given to NIF/local-users with the congestion level of the affected SPMC. Kamesh Kaul, HSS [Page 13] Internet Draft M3UA Congestion Procedures Jan 2003 4. Examples of network congestion 4.1 ASP network congestion with multiple SG's In the following scenario, SG1 consists of SGP1, SG2 consisits of SGP2 and SG3 consists of SGP3. Point code X-Y-Z is configured SG1 SCON (3) ++-----+-++ <--------- | | +--------------+ SGP1 +---+-------++ | | | | | +---------+ | | | | SG2 | +------+-++ | SCON (2) ++-----+-++ +--++--+-++ | | | <--------- | | | | | ASP +-----+--------------+ SGP2 +-- +----+ PC + | | | | | | (X-Y-Z) | +---------+ | +---------+ +----+----+ PC (X-Y-Z) | | | SG3 | | SCON (1) +------+-++ | | <---------- | | | +--------------+ SGP3 +---+---------+ | | +---------+ Kamesh Kaul, HSS [Page 14] Internet Draft M3UA Congestion Procedures Jan 2003 at ASP.As shown in figure above SCON messages received from SG1,SG2 and SG3 are SCON(3),SCON(2)and SCON(1) respectively. Assuming no local congestion, congestion status of point code X-Y-Z configured at ASP after receiving SCON messages is 3. 4.2 ASP network congestion abatement with multiple SG's As shown in figure below congestion status of point code X-Y-Z configured at ASP is marked 0 (non-congested) when SCON (0) is received from SG1,SG2 and SG3 (all the routes through which point code is reachable). This example is valid if no timer is used to provision congestion at ASP. SG1 SCON (0) ++-----+-++ <--------- | | +--------------+ SGP1 +---+-------++ | | | | | +---------+ | | | | SG2 | +------+-++ | SCON (0) ++-----+-++ +--++--+-++ | | | <--------- | | | | | ASP +-----+--------------+ SGP2 +-- +----+ PC + | | | | | | (X-Y-Z) | +---------+ | +---------+ +----+----+ PC (X-Y-Z) | | | SG3 | | SCON (0) +------+-++ | | <---------- | | | +--------------+ SGP3 +---+---------+ | | +---------+ Kamesh Kaul, HSS [Page 15] Internet Draft M3UA Congestion Procedures Jan 2003 4.3 SGP network congestion with multiple AS's In the following scenario, AS1 consists of ASP1, AS2 consists of ASP2 and AS3 consists of ASP3. SPMC A-B-C is configured. Routing key type for all the AS's is DPC+SIO+CIC. Routing keys for AS1,AS2 and AS3 are (A-B-C)+ (ISUP) + (1-10), (A-B-C)+ (ISUP) + (11-20) and (A-B-C)+ (ISUP) + (21-30) respectively. As shown in figure below SCON messages received from ASP1,ASP2 and ASP3 are SCON(3),SCON(2)and SCON(1) respectively. Assuming no local congestion, congestion status of SPMC A-B-C configured at ASP after receiving SCON messages is 3. AS1 SCON (3) ++-----+-++ <--------- | | +--------------+ ASP1 + | | | | +---------+ | | AS2 +------+-++ | SCON (2) ++-----+-++ | | | <--------- | | | SGP +-----+--------------+ ASP2 + | | | | | +---------+ | +---------+ SPMC (A-B-C) | | AS3 | SCON (1) +------+-++ | <---------- | | +--------------+ ASP3 + | | +---------+ Congestion abatement of SPMC A-B-C is provisioned by congestion timer explained in earlier text. Kamesh Kaul, HSS [Page 16] Internet Draft M3UA Congestion Procedures Jan 2003 5. Acknowledgements The authors would like to thank Anshoo Sharma, Sandeep Mahajan and Priyaranjan for their valuable comments and suggestions. 6. References 6.1 Normative References [1] ITU-T Recommendation Q.704 "Specifications of Signalling System No. 7 - Message transfer part Signalling network functions and messages" [2] RFC[3332] "SS7 MTP3 - User Adaptation Layer (M3UA)" 6.2 Informative References [4] RFC[2119] "Key words for use in RFCs to Indicate Requirement Levels" 7. Author's Addresses Kamesh Kaul Hughes Software Systems Delhi EMail : kakaul@hss.hns.com,kkk_kaul@yahoo.com Kamesh Kaul, HSS [Page 17]