Signaling Transport Working Group B. Nagelberg Internet-Draft Adax Intended status: Informational November 2, 2007 Expires: May 5, 2008 M2UA Implementor's Guide 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. 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 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document contains a compilation of all defects found since the publication date for M2UA [RFC3331]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M2UA to clarify errors in the original M2UA document. This document updates RFC3331 and text within this document supersedes the text found in RFC3331. Nagelberg Expires May 5, 2008 [Page 1] Internet-Draft M2UA Implementor's Guide November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Corrections to RFC3331 . . . . . . . . . . . . . . . . . . . . 3 2.1. n+k redundancy . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Messages and Streams . . . . . . . . . . . . . . . . . . . 8 2.3. Parameter Containing Subparameters with Padding Bytes . . 9 2.4. Multiple Parameters of the Same Type in a Message . . . . 10 2.5. How to indicate that Dynamic Registration is not supported . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Explanatory text for "Unsupported Message Type" error code is missing . . . . . . . . . . . . . . . . . . . . . 13 2.7. Need additional error code . . . . . . . . . . . . . . . . 13 2.8. Notify(ASP-Failure) usage clarification . . . . . . . . . 14 2.9. Alignment of ASP Active message with ASP Inactive message . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.10. Response to an ASPIA message . . . . . . . . . . . . . . . 17 2.11. NOTIFY messages are missing in Examples section . . . . . 19 2.12. Error handling in the Retrieval Confirm message for ACTION_RTRV_BSN . . . . . . . . . . . . . . . . . . . . . 21 2.13. Error handling in the Retrieval Confirm message for ACTION_RTRV_MSGS . . . . . . . . . . . . . . . . . . . . . 23 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . . 25 6.2. Informative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Nagelberg Expires May 5, 2008 [Page 2] Internet-Draft M2UA Implementor's Guide November 2007 1. Introduction This document contains a compilation of all defects found since the publication date for M2UA [RFC3331]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M2UA to clarify errors in the original M2UA document. This document updates RFC3331 and text within this document supersedes the text found in RFC3331. Each error will be detailed within this document in the form of: o The problem description o The text quoted from RFC3331 o The replacement text o A description of the solution 1.1. Terminology The terms are commonly identified in related work M2UA [RFC3331]. 1.2. Requirements Language 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 [RFC2119]. 2. Corrections to RFC3331 2.1. n+k redundancy 2.1.1. Description of the problem The n+k redundancy model is explained as a general model but there is no reference to it in the current AS state diagram, and sometimes it is not clear when it should be used. Also the term "n+k" is subject to multiple interpretations. 2.1.2. Text changes to the document --------- Old text: (Section 1.3.2) --------- The M2UA layer supports a n+k redundancy model (active-standby, load Nagelberg Expires May 5, 2008 [Page 3] Internet-Draft M2UA Implementor's Guide November 2007 sharing, broadcast) where n is the minimum number of redundant ASPs required to handle traffic and k ASPs are available to take over for a failed or unavailable ASP. Note that 1+1 active/standby redundancy is a subset of this model. A simplex 1+0 model is also supported as a subset, with no ASP redundancy. --------- New text: (Section 1.3.2) --------- The M2UA layer supports an "n+k" redundancy model, where "n" ASPs is the number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be either active at the same time as "n" or kept inactive until needed due to a failed or unavailable ASP. A "1+1" active/backup redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no ASP redundancy. --------- Old text: (Section 4.3.2) --------- AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server MUST be in the AS-DOWN state before it can be removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP- INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired. AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state. AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP- DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP. If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops Nagelberg Expires May 5, 2008 [Page 4] Internet-Draft M2UA Implementor's Guide November 2007 queuing messages and discards all previously queued messages. The AS will move to the AS-INACTIVE state if at least one ASP is in the ASP- INACTIVE state, otherwise it will move to the AS-DOWN state. Figure 6 shows an example AS state machine for the case where the AS/ ASP data is pre-configured. For other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at the creation of the AS. For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the first successful REG REQ from an ASP. Another example is where the AS/ASP configuration data is not created until the first ASP successfully enters the ASP-ACTIVE state. In this case the AS-ACTIVE state is entered directly. Figure 6: AS State Transition Diagram +----------+ one ASP trans to ACTIVE +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ ASP in ASP-INACTIVE | | | | \ | | | | \ | | | | \ | | one ASP | | all ASP \ one ASP | | Last ACTIVE trans | | trans to \ trans to | | ASP trans to to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE ASP- | | \ ACTIVE | | or ASP-DOWN INACTIVE| | \ | | (start Tr) | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queuing) | | |<----------------------------| | +----------+ Tr Expiry and no ASP +-------------+ in ASP-INACTIVE state Tr = Recovery Timer Nagelberg Expires May 5, 2008 [Page 5] Internet-Draft M2UA Implementor's Guide November 2007 --------- New text: (Section 4.3.2) --------- AS-DOWN: The Application Server is unavailable. This state implies that all the ASPs are in the ASP-DOWN state. Initially the AS will be in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active. One or more ASPs are in ASP-INACTIVE state and/or the number of ASPs in ASP-ACTIVE state has not reached n. The recovery timer T(r) is not running or has expired. AS-ACTIVE: The Application Server is available and application traffic is active. The AS moves to this state after being in AS- INACTIVE and getting n ASPs in ASP-ACTIVE state or, after reaching AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. When it is considered that one ASP is enough to handle traffic (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the first ASP moves to the ASP-ACTIVE state. AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to ASP-INACTIVE or ASP-DOWN. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP. If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP MAY stop queuing messages and discard all previously queued messages. The AS will move to the AS-INACTIVE state if at least the number of ASPs in ASP-INACTIVE sum n, otherwise it will move to AS-DOWN state. Figure 6 shows an example AS state machine for the case where the AS/ ASP data is preconfigured and an n+k redundancy model. Nagelberg Expires May 5, 2008 [Page 6] Internet-Draft M2UA Implementor's Guide November 2007 Figure 6: AS State Transition Diagram +----------+ IA2AC +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<----------- | | +----------+ \ +-------------+ ^ | \ ^ | | | IA2DN \ PN2IA | | AC2PN | | \ | | DN2IA | | \ PN2AC | | | v \ | v +----------+ \ +-------------+ | | ----------| | | AS-DOWN | | AS-PENDING | | | PN2DN | (queueing) | | |<----------------------------| | +----------+ +-------------+ DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN. IA2AC: One ASP moves to ASP-ACTIVE, causing the number of ASPs in the ASP-ACTIVE state to be n. In a special case of smooth start, this transition MAY be done when the first ASP moves to ASP-ACTIVE state. AC2PN: The last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- DOWN states. PN2AC: One ASP moves to ASP-ACTIVE. PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE. PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state. An AS becomes AS-ACTIVE when n ASPs reach the ASP-ACTIVE state during the start-up phase (except for smooth start). Once the traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP switches to a state other than ASP-ACTIVE. This avoids unnecessary traffic disturbances as long as there are ASPs available, in the assumption that the system will not always be exposed to the maximum load. There are other cases where the AS/ASP configuration data is created dynamically. In those cases there would be differences in the state machine, especially at creation of the AS. For example, where the Nagelberg Expires May 5, 2008 [Page 7] Internet-Draft M2UA Implementor's Guide November 2007 AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the nth successful REG REQ from an ASP belonging to that AS. --------- Old text: (Section 4.3.4.3, for both loadsharing and broadcast) --------- An SGP, upon reception of an ASP Active message for the first ASP in a Load share AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). --------- New text: (Section 4.3.4.3, for both loadsharing and broadcast) --------- At start-up or re-start phases, an SGP, upon reception of an ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. 2.1.3. Solution description The AS state machine reflects the state changes as a function of the "n" number from the n+k redundancy model. This solution is compliance with the previous one: 1+0 model. The change from MAY to SHOULD NOT makes it recommendable to send traffic only when the require ASPs number are in ASP-ACTIVE state. 2.2. Messages and Streams 2.2.1. Description of the problem The instructions for stream usage are distributed across different sections. 2.2.2. Text changes to the document --------- Old text: (Section 1.5.4.1) --------- SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) Nagelberg Expires May 5, 2008 [Page 8] Internet-Draft M2UA Implementor's Guide November 2007 messages (see Section 3) since stream '0' SHOULD only be used for ASP Management (ASPM) messages (see Section 4.3.3). --------- New text: (Section 1.5.4.1) --------- o SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages. o All MGMT messages, with the exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP stream '0'. o All ASPTM messages SHOULD be sent on the stream which normally carries the data traffic to which the message applies. o BEAT and BEAT Ack messages MAY be sent on any stream. --------- Old text: (Section 4.2.1) --------- All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. All MGMT messages, with the exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP stream '0'. All ASPTM messages SHOULD be sent on the stream which normally carries the data traffic to which the message applies. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery, and MAY be sent on any stream. --------- New text: (Section 4.2.1) --------- All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery 2.2.3. Solution description The instructions for stream usage are combined into a single section. 2.3. Parameter Containing Subparameters with Padding Bytes Nagelberg Expires May 5, 2008 [Page 9] Internet-Draft M2UA Implementor's Guide November 2007 2.3.1. Description of the problem If a parameter contains subparameters with padding bytes, it is not clear if the parameter length should include the subparameter padding bytes or not. 2.3.2. Text changes to the document --------- Old text: (Section 3.1.6) --------- Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. --------- New text: (Section 3.1.6) --------- Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. If the parameter contains subparameters, the Parameter Length field will include all the bytes of each subparameter including subparameter padding bytes (if any). 2.3.3. Solution description Clarified that when calculating the length of a parameter that contains subparameters, the padding bytes of the subparameters should be included. 2.4. Multiple Parameters of the Same Type in a Message 2.4.1. Description of the problem It is not clear whether or not multiple parameters of same type are allowed in a message. Nagelberg Expires May 5, 2008 [Page 10] Internet-Draft M2UA Implementor's Guide November 2007 2.4.2. Text changes to the document --------- Old text: --------- None. --------- New text: (Section 3.1.6) --------- Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. Unless explicitly stated or shown in a message format diagram, only one parameter of the same type is allowed in a message. 2.4.3. Solution description Clarified that multiple parameters of the same type are forbidden in messages unless explicitly allowed. 2.5. How to indicate that Dynamic Registration is not supported 2.5.1. Description of the problem There is a need to be able to correlate a "Dynamic Registration not supported" error to a Registration Request. 2.5.2. Text changes to the document --------- Old text: --------- None. --------- New text: (Section 4.4.1) --------- If the SGP does not support the dynamic registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Class". --------- Nagelberg Expires May 5, 2008 [Page 11] Internet-Draft M2UA Implementor's Guide November 2007 Old text: (Section 3.3.3.1) --------- The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. --------- New text: (Section 3.3.3.1) --------- The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 bytes of the offending message. --------- Old text: (Section 3.3.3.1) --------- The ERR message contains the following parameters: Error Code (mandatory) Interface Identifier (optional) Diagnostic Information (optional) --------- New text: (Section 3.3.3.1) --------- Error Code (mandatory) Interface Identifier (optional) Diagnostic Information (conditional) 2.5.3. Solution description An SGP that does not support dynamic registration must return an Error message (Unsupported Message Class), including the first 40 bytes of the offending message (i.e. any Link Key Management message sent by the ASP) so that the ASP can correlate this error to the Registration Request message. Note that the change to the "Unsupported Message Class" text make this a general solution that allows the ASP or SG side to correlate these error responses with the offending message. Nagelberg Expires May 5, 2008 [Page 12] Internet-Draft M2UA Implementor's Guide November 2007 2.6. Explanatory text for "Unsupported Message Type" error code is missing 2.6.1. Description of the problem There is no explanatory text for the "Unsupported Message Type" error code. 2.6.2. Text changes to the document --------- Old text: --------- None --------- New text: (Section 3.3.3.1) --------- The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 bytes of the offending message. 2.6.3. Solution description Add explanatory text for the "Unsupported Message Type" error code. 2.7. Need additional error code 2.7.1. Description of the problem There is a need to add an error code to cover the case in which an ASP Active or an ASP Inactive message is received from the ASP without a Interface Identifier parameter, and it is not known by configuration data which Application Servers are referenced. 2.7.2. Text changes to the document --------- Old text: --------- Missing Parameter 0x16 --------- New text: (Section 3.3.3.1) Nagelberg Expires May 5, 2008 [Page 13] Internet-Draft M2UA Implementor's Guide November 2007 --------- Missing Parameter 0x16 Not Used in M2UA 0x17 Not Used in M2UA 0x18 Not Used in M2UA 0x19 No Configured AS for ASP 0x1a The "No Configured AS for ASP" error is sent if an ASP Active or an ASP Inactive message is received from the ASP without a Interface Identifier parameter, and it is not known by configuration data which Application Servers are referenced. 2.7.3. Solution description Add error code. 2.8. Notify(ASP-Failure) usage clarification 2.8.1. Description of the problem It is not clear when Notify (ASP Failure) must be sent. Is it upon failure (SCTP association fails) or any transition to ASP-DOWN state? 2.8.2. Text changes to the document --------- Old text: (Section 3.3.3.2) --------- In the Insufficient ASP Resources case, the SGP is indicating to an ASP-INACTIVE ASP(s) in the AS that another ASP is required in order to handle the load of the AS (Load-sharing mode). For the Alternate ASP Active case, the formerly Active ASP is informed when an alternate ASP transitions to the ASP Active state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message. --------- New text: (Section 3.3.3.2) --------- These notifications are not based on the SGP reporting the state change of an ASP or AS. Nagelberg Expires May 5, 2008 [Page 14] Internet-Draft M2UA Implementor's Guide November 2007 o In the Insufficient ASP Resources case, the SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is required to handle the load of the AS (Loadsharing or Broadcast mode). o For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. o For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has failed. The ASP Identifier (if available) of the failed ASP MUST be placed in the message. 2.8.3. Solution description The term "transitioned to ASP-DOWN" has been changed to "ASP has failed" to clarigy that the ASP failure is the reason of this notification. 2.9. Alignment of ASP Active message with ASP Inactive message 2.9.1. Description of the problem The description of the procedures for ASP Active and ASP Inactive messages are different, and the responses to these messages are not specified for all cases. 2.9.2. Text changes to the document --------- Old text: (Section 4.3.4.3) --------- In the case where an ASP Active message does not contain a Interface Identifier parameter, the receiver must know, via configuration data, of which Application Server(s) the ASP is a member. --------- New text: (Section 4.3.4.3) --------- In the case where an ASP Active message does not contain a Interface Identifier parameter, the receiver must know, via configuration data, of which Application Server(s) the ASP is a member and move the ASP to the ASP-ACTIVE state in all Application Servers. --------- Old text: (Section 4.3.4.3) Nagelberg Expires May 5, 2008 [Page 15] Internet-Draft M2UA Implementor's Guide November 2007 --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Interface Identifiers, allowing the SGP to independently acknowledge the ASP Active message for different (sets of) Interface Identifiers. The SGP MUST send an Error message ("Invalid Interface Identifier") for each Interface Identifier value that cannot be successfully activated. In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently discarded. The SGP MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SGP. --------- New text: (Section 4.3.4.3) --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Interface Identifiers, allowing the SGP to independently acknowledge the ASP Active message for different (sets of) Interface Identifiers. The ASP Active message will be responded in the following way as a function of the presence/need of the Interface Identifier parameter: o If the Interface Identifier parameter is included in the ASP Active message and the corresponding LK has been previously defined (by either static configuration or dynamic registration), the peer node MUST respond with an ASP Active Ack message if it is ready to handle traffic; otherwise it will not respond (meaning that it is not ready to become active). This is valid when the ASP is in the ASP-ACTIVE or the ASP-INACTIVE state. o If the Interface Identifier parameter is included in the ASP Active message and a corresponding LK has not been previously defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with Error Code = "Invalid Interface Identifier". o If the Interface Identifier parameter is not included in the ASP Active message, there are LKs defined (by either static configuration or dynamic registration) and Interface Identifier is not mandatory, the peer node SHOULD respond with an ASP Active Ack Nagelberg Expires May 5, 2008 [Page 16] Internet-Draft M2UA Implementor's Guide November 2007 message and activate all the LKs that are defined for that specific ASP. o If the Interface Identifier parameter is not included in the ASP Active message, there are LKs defined (by either static configuration or dynamic registration) and Interface Identifier is mandatory, the peer node MUST respond with and ERROR message with the Error Code = "Missing Parameter". o If the Interface Identifier parameter is not included in the ASP Active message, there are LKs defined (by either static configuration or dynamic registration) and Interface Identifier is not mandatory, the peer node MUST respond with an ASP Active Ack message if it is ready to handle traffic; otherwise it will not respond (meaning that it is not ready to become active). o If the Interface Identifier parameter is not included in the ASP Active message and there are no LKs defined, the peer node SHOULD respond with and ERROR message with the Error Code = "No configured AS for ASP". 2.9.3. Solution description Align the wording in these two sections. 2.10. Response to an ASPIA message 2.10.1. Description of the problem It is not clear how to act in the following scenario: ASP SGP --- --- | ------ ASPIA (LK1)-----> | | <---- ASPIA Ack ------- | | -----DEREG REQ (LK1)---> | | <----DEREG RSP (LK1)---- | | -------ASPIA (LK1)-----> | What should SG do? 2.10.2. Text changes to the document --------- Old text: (Section 4.3.4.4) --------- Nagelberg Expires May 5, 2008 [Page 17] Internet-Draft M2UA Implementor's Guide November 2007 When an ASP wishes to withdraw from receiving traffic within an AS, the ASP sends an ASP Inactive message to the SGP. This action MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M2UA management function. In the case where an ASP is processing the traffic for more than one Application Server across a common SCTP association, the ASP Inactive message contains one or more Interface Identifiers to indicate for which Application Servers the ASP Inactive message applies. --------- New text: (Section 4.3.4.4) --------- When an ASP wishes to withdraw from receiving traffic within an AS, or the ASP wants to initiate the process of deactivation, the ASP sends an ASP Inactive message to the SGP. The SGP MUST always respond to an ASP Inactive message, in the following way: o If the ASP Inactive message contains an Interface Identifier and the corresponding LK is defined (by either static configuration or dynamic registration), the peer MUST respond with an ASP Inactive Ack message. o If the ASP Inactive message contains an Interface Identifier that is not defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with Error Code = "Invalid Interface Identifier". o If the ASP Inactive message does not contain an Interface Identifier and the LK is defined (by either static configuration or dynamic registration), the peer must turn the ASP/IPSP to ASP- INACTIVE state in all the ASes it serves and MUST respond with an ASP Inactive Ack message. o If the ASP Inactive message does not contain an Interface Identifier and the LK is not defined (by either static configuration or dynamic registration), the peer SHOULD respond with an ERROR message with Error Code = "No configured AS for ASP". The action of sending the ASP Inactive message MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M2UA management function. In the case where an ASP is processing the traffic for more than one Application Server across a common SCTP association, the ASP Inactive Nagelberg Expires May 5, 2008 [Page 18] Internet-Draft M2UA Implementor's Guide November 2007 message contains one or more Interface Identifiers to indicate for which Application Servers the ASP Inactive message applies. 2.10.3. Solution description A more detailed specification of the messages to be sent upon the reception of an ASPIA has been added to the ASP Inactive Procedures Section. 2.11. NOTIFY messages are missing in Examples section 2.11.1. Description of the problem There are some mandatory NOTIFY messages missing in section 5 in the RFC. 2.11.2. Text changes to the document --------- Old text: (Section 5.1.1) --------- SGP ASP1 | | |<-------------ASP Up-----------| |-----------ASP Up Ack--------->| | | |<------- ASP Active------------| |-----ASP Active Ack----------->| | | |-----NTFY(AS-ACTIVE)---------->| | | --------- New text: (Section 5.1.1) --------- SGP ASP1 | | |<-------------ASP Up-----------| |-----------ASP Up Ack--------->| | | |-----NTFY(AS-INACTIVE)-------->| | | |<------- ASP Active(LKn)-------| |-----ASP Active Ack (LKn)----->| Nagelberg Expires May 5, 2008 [Page 19] Internet-Draft M2UA Implementor's Guide November 2007 | | |-----NTFY(AS-ACTIVE)(LKn)----->| | | --------- Old text: (Section 5.1.2) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<----REG REQ-------------------| |----REG REQ RESP-------------->| | | |<------- ASP Active------------| |-----ASP Active Ack----------->| | | |-----NTFY(AS-ACTIVE)---------->| | | --------- New text: (Section 5.1.2) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<----REG REQ-------------------| |----REG REQ RESP-------------->| | | |----NTFY(AS-INACTIVE)--------->| | | |<------- ASP Active------------| |-----ASP Active Ack----------->| | | |-----NTFY(AS-ACTIVE)---------->| | | --------- Old text: (Section 5.1.3 --------- Nagelberg Expires May 5, 2008 [Page 20] Internet-Draft M2UA Implementor's Guide November 2007 SGP ASP1 ASP2 | | | |<--------ASP Up---------| | |-------ASP Up Ack------>| | | | | |<----------------------------ASP Up----------------| |----------------------------ASP Up Ack------------>| | | | | | | |<-------ASP Active------| | |------ASP Active Ack--->| | | | | --------- New text: (Section 5.1.3 --------- SGP ASP1 ASP2 | | | |<--------ASP Up---------| | |-------ASP Up Ack------>| | | | | |--NOTIFY(AS-INACTIVE)-->| | | | | |<----------------------------ASP Up----------------| |----------------------------ASP Up Ack------------>| | | | | | | |<-------ASP Active------| | |------ASP Active Ack--->| | | | | |---NOTIFY(AS-ACTIVE)--->| | |--------------------------NOTIFY(AS-ACTIVE)------->| | | | 2.11.3. Solution description By specifying all the mandatory NOTIFY messages in the drawing, we solve the problem. 2.12. Error handling in the Retrieval Confirm message for ACTION_RTRV_BSN Nagelberg Expires May 5, 2008 [Page 21] Internet-Draft M2UA Implementor's Guide November 2007 2.12.1. Description of the problem There is a contradiction in the RFC regarding error handling in the Retrieval Confirm message for ACTION_RTRV_BSN, for the case in which the SGP cannot retrieve the Backward Sequence Number. Section 3.3.1.10 (Retrieval Confirm) states that "If the BSN could not be retrieved, the Sequence Number field will not be included and the Result field will indicate failure." However Section 5.3.6 (SS7 Link Changeover) shows examples of this error case in which the Sequence Number field is included, and is set to -1. 2.12.2. Text changes to the document --------- Old text: (Section 5.3.6) --------- An example of a message flow with an error retrieving the BSN is shown below. MTP2 M2UA M2UA MTP3 SGP SGP ASP ASP <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> (seq_num = -1) --------- New text: (Section 5.3.6) --------- An example of a message flow with an error retrieving the BSN is shown below. MTP2 M2UA M2UA MTP3 SGP SGP ASP ASP <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- -BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv--> (seq_num field not included) Nagelberg Expires May 5, 2008 [Page 22] Internet-Draft M2UA Implementor's Guide November 2007 2.12.3. Solution description The example has been corrected to not conflict with the message description. 2.13. Error handling in the Retrieval Confirm message for ACTION_RTRV_MSGS 2.13.1. Description of the problem There is a contradiction in the RFC regarding the use of the Sequence Number field in Retrieval Confirm message for the ACTION_RTRV_MSGS case. Section 3.3.1.10 (Retrieval Confirm) states that "For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of the Result field will indicate success or failure. A failure means that the buffers could not be retrieved. The Sequence Number field is not used with ACTION_RTRV_MSGS." However Section 5.3.6 (SS7 Link Changeover) shows examples of the retrieval confirm message for ACTION_RTRV_MSGS in which the Sequence Number field is included. 2.13.2. Text changes to the document --------- Old text: (Section 5.3.6) --------- MTP2 M2UA M2UA MTP3 SGP SGP ASP ASP <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- (seq_num = 0) -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> (seq_num = BSN) <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- (seq_num = FSN) -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> (seq_num = 0) --------- New text: (Section 5.3.6) --------- Nagelberg Expires May 5, 2008 [Page 23] Internet-Draft M2UA Implementor's Guide November 2007 MTP2 M2UA M2UA MTP3 SGP SGP ASP ASP <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- (seq_num = 0) -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> (seq_num = BSN) <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- (seq_num = FSN) -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> (seq_num field not included) --------- Old text: (Section 5.3.6) --------- An example of a message flow with an error retrieving the messages is shown below. <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> (seq_num = BSN) <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- (seq_num = FSN) -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> (seq_num = -1) --------- New text: (Section 5.3.6) --------- An example of a message flow with an error retrieving the messages is shown below. Nagelberg Expires May 5, 2008 [Page 24] Internet-Draft M2UA Implementor's Guide November 2007 <-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req--- -Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm--> (seq_num = BSN) <-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req--- (seq_num = FSN) -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> (seq_num field not included) 2.13.3. Solution description The example has been corrected to not conflict with the message description. 3. Acknowledgements The author would like to thank Javier Pastor-Balbas, Ken Morneault, Lyndon Ong, Tolga Asveren, Brian Bidulock, Umesh Vats, Samuel Dur D. Jeyaseelan, Antonio Canete, Kamesh Kaul, Vivek Toky, Daniel Cohn and many others for their valuable comments and suggestions. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations No new threats have been identified besides the already known in [RFC3331]. 6. References 6.1. Normative References [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002. Nagelberg Expires May 5, 2008 [Page 25] Internet-Draft M2UA Implementor's Guide November 2007 6.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4666] Morneault, K. and J. Pastor-Balbas, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 4666, September 2006. Author's Address Barry Nagelberg Adax, Inc. 520 Fellowship Rd. Suite C-304 Mount Laurel, NJ 08054 US Phone: +1 856 642 7757 Email: barryn@adax.com Nagelberg Expires May 5, 2008 [Page 26] Internet-Draft M2UA Implementor's Guide November 2007 Full 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. 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. 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 provided by the IETF Administrative Support Activity (IASA). Nagelberg Expires May 5, 2008 [Page 27]