Re: SIGTRAN Plugtest Day 1

Hi Barry,

thank you very much the report. I would like to comment on the second  
item.
See the comments in-line.

Best regards
Michael

On Apr 17, 2007, at 9:25 AM, Barry Nagelberg wrote:

> Greetings from Moscow! Here is the wrap-up report for Day 1 of the  
> SIGTRAN
> Plugtest.
>
> Protocols tested:
> M2PA - 3 implementations
> M2UA - 2 implementations
> M3UA - 7 implementations
> SUA  - 3 implementations
>
> Issues raised during testing:
>
> *******
> Issue 1 - How to handle an M3UA registration request (REG_REQ) msg  
> received
> without a Network Appearance (NA) param.
> *******
>
> Example: An M3UA SGP is configured with multiple SS7 networks. The SGP
> receives a REG_REQ msg without the optional NA param. How should  
> the SGP
> handle the registration request? The problem is that the SGP  
> doesn't know to
> which SS7 network to apply the routing information.
>
> Some implementations are returning REG_RESP msg with Registration  
> Status =
> Error - Invalid Network Appearance.
> Some implementations are returning REG_RESP msg with Registration  
> Status =
> Error - Invalid Routing Key.
>
> The consensus of the group is that while RFC 4666 has tried to  
> address this
> issue, in the description of the "Network Appearance" param of the  
> REG_REQ
> msg, there is still a lot of confusion. In this section, the RFC  
> states
> that:
>
> <snip>
> .....If the
> Network Appearance is not specified and the Routing Key applies to
> all Network Appearances, then this Routing Key MUST be the only
> one registered for the association.
> <snip>
>
> There were several problems identified with this statement:
> a. It is not clear how the SGP can possibly know whether or not  
> "the Routing
> Key applies to all Network Appearances".
>
> b. Even if the SGP can somehow discern whether or not "the Routing Key
> applies to all Network Appearances", it is not stated what the SGP  
> should do
> if the Routing Key DOES NOT apply to all Network Appearances.
>
> *******
> Issue 2 - How should M3UA/SUA handle an SCTP INIT chunk in which  
> the number
> of inbound/outbound streams is specified as 1?
> *******
>
This is a general problem and section 2.19 of RFC 4460 covers it
partially. Basically it takes away the decision from SCTP and requires
that the decision is made by the upper layer.
> Some implementations accept this and allow the assoc to come up and  
> be used.
I think the full SCTP handshake is a good thing.
> Some implementations are not responding at all.
This is bad, because the sender will retry and has no indication what  
is wrong.
> Some implementations are responding with an INIT_ACK chunk with
> OUT_OF_RESOURCES error code.
You can not bundle an INIT-ACK chunk with an ERROR chunk. So how can  
you report
OUT_OF_RESOURCES?
> Some implementations are allowing the assoc to come up but are then  
> aborting
> the assoc.
That is within the SCTP spec. It would be nice to give an indication  
what is
wrong. Maybe an M3UA/SUA error message. Then you could initiate the  
SHUTDOWN
procedure of SCTP.
>
> The M2PA spec (RFC 4165) addresses this most clearly by stating  
> that "The
> association SHALL contain two streams in each direction."
>
> The consensus of the group is that the M3UA/SUA specs are unclear  
> about how
> to handle this. Based on the stream usage restrictions stated in  
> section
> 1.4.7. (SCTP Stream Mapping), the group feels that the intention of  
> M3UA/SUA
> is probably to state something like "The association SHALL contain  
> at least
> two streams in each direction."
>
> *******
> Issue 3 - IPSP issues in SUA
> *******
>
> For Double-Exchange: How should an implementation handle an ASP- 
> ACTIVE msg
> if it has not yet sent ASPUP?
>
> For Single-Exchange:
>
> a. How should an implementation handle an ASPUP msg if it is not  
> yet ready
> to go up, for example if it is not completely configured?
>
> b. Is it OK for the server to send ASPUP?
>
>
> Barry Nagelberg
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>