RE: Recommendation for SUA modifications
"Haresign Lincoln" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB02544915@us-nj-mail1.comverse.com> |
Valerie, I think this is a good solution. Using the RC also addresses the scenario of the ASP supporting multiple point codes (not something that we do, but the RFC supports it). Since the current SCON message doesn't indicate that multiple point codes can be specified in the SCON, the RC parameter would handle this scenario also. Regards, Lincoln -----Original Message----- From: Valerie Gastaud [mailto:[email protected]] Sent: Friday, October 14, 2005 4:30 AM To: Haresign Lincoln; [email protected]; [email protected] Cc: [email protected] Subject: RE: [Sigtran] Recommendation for SUA modifications Lincoln, Brian et all, Lincoln has explained the problem he tries to solve that requires a modification to the SCON and I think it's a valid case: SG and ASPs share the same Point Code and the ASPs are not provisioned with the PC value. Let's forget about the usefulness of such architecture. Since I don't think there are any other problem than SCON to solve in this case, why not trying to solve it. I propose the following text: 3.4.4. Signalling Congestion (SCON) | When the SCON is from the ASP to the SG, the affected point | code is an optional parameter. If not included, the SG | must assume the affected PC is its own (primary) Point Code. -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Haresign Lincoln Sent: mercredi 12 octobre 2005 17:02 To: [email protected]; [email protected] Cc: [email protected] Subject: [Sigtran] Recommendation for SUA modifications Lode, John, and the SIGTRAN WG, With regards to the current SUA RFC, it is my humble opinion that there is some missing functionality that needs to be defined. I would like to propose an addition to the current SUA Implementors Guide that you are maintaining. The current SUA RFC indicates that the ASP->SG SCON message is a valid procedure. However, I believe that in the case of sending an SCON message from an ASP to an SG, it is not always necessary to include the affected DPC in the SCON message. When the ASP and the SG share the same point code, some architectures (such as those that use global titles extensively) do not require the ASP (or the SUA layer in the ASP) to be aware of the point code that is being used when the SG converts the CL message to an MSU and builds the L3 MTP routing label. Therefore, requiring the affected PC in the SCON message from the ASP to the SG puts and unnecessary burden on the ASP. There are several ways to solve this problem. I'm proposing two possible solutions below. Personally, I believe the first proposal is a little cleaner. I would welcome any and all feedback and/or alternate solutions. In the end, I'm no so much concerned with how the problem is solved. I would just like a solution that doesn't require the ASP to have knowledge of the point code being used by the SG if the ASP and SG share the same point code. Proposal #1: Use RC 3.4.4. Signalling Congestion (SCON) The SCON message can be sent from the SG or relay node to all concerned ASPs to indicate that the congestion level in the SS7 network to a specified destination has changed. | The SCON message can be sent from an ASP to an SG to indicate local | congestion. The receiving SG MAY trigger the congestion procedures of | the relevant SCCP standard. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x8003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0118 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0112 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Routing Context Optional | Affected Point Code Conditional *1 SSN Optional *1 Congestion Level Mandatory SMI Optional Info String Optional | Note 1: For an SCON from the SG to an ASP, when the SSN is included, the SCON message corresponds to the SCCP N-STATE primitive. When the SSN is not included, the SCON message corresponds to the SCCP N-PCSTATE primitive reporting signalling point or network congestion status. | When the SCON is from the ASP to the SG, the affected point | code is an optional parameter. The SG, if necessary, can | determine the affected PC from the Routing Context. Proposal #2: Use Source Address 3.4.4. Signalling Congestion (SCON) The SCON message can be sent from the SG or relay node to all concerned ASPs to indicate that the congestion level in the SS7 network to a specified destination has changed. | The SCON message can be sent from an ASP to an SG to indicate local | congestion. The receiving SG MAY trigger the congestion procedures of | the relevant SCCP standard. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Tag = 0x0102 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / Source Address / | \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Affected Point Code / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x8003 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0118 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0112 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Info String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameters Routing Context Optional | Source Address Optional *1 | Affected Point Code Conditional *1 | SSN Conditional *1 Congestion Level Mandatory SMI Optional Info String Optional | Note 1: For an SCON from the SG to an ASP, when the SSN is included, the SCON message corresponds to the SCCP N-STATE primitive. When the SSN is not included, the SCON message corresponds to the SCCP N-PCSTATE primitive reporting signalling point or network congestion status. | When the SCON is from the ASP to the SG, the ASP can use | the source address parameter instead of the Affected Point | Code parameter. This is used mainly in the case when the | Routing Keys associated with the ASP may not include a point | code and/or an SSN. The SG should be able to derive the affected | PC from the registration information and take any actions | that might be appropriate to for subsystem congestion in | the network. | | If the ASP is sending Source Address, it is not necessary to | send SSN and/or Affected Point Code as this information is | either contained in the source address, or can be derived at | the SG. Regards, Lincoln Haresign Comverse, Inc. _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran ______________________________________________________________________ This email message has been scanned by PineApp Mail-Secure and has been found clean.