Re: SIGTRAN Plugtest Day 1

Hi Barry,

another comment regarding the streams issue... This time at the SIGTRAN
layer:

 From a general point of view, an user protocol might break, if it
expects several messages to be received in sequence, but they aren't.
So if a protocol spec requires several messages to be transported
in one stream an the sender violates this rule, the user protocol
might break. But this is not relevant here.

Here is the question: What happens if the sender puts several messages
in one stream? Since the stream ID is not used by the receiver to figure
out what kind of message it is, the receiver should be able to handle
it. Using less streams 'only' makes the possibility of head of line
blocking higher. Basically this means the the choice of the stream
is a sender side only issue.

So as a receiver, I could receive messages also, when received on the
wrong stream, at least I do not see how this would break the protocol.
On the other hand, if peer does not provide enough streams for me to
send on, I could use less and communicate, or do not communicate at
all. I'm not sure what is better here. Probably communicating at all.

Regarding the specs... If a clarification is needed. What about  
requiring
multiple streams with a SHOULD like for M2PA, but also state that the
receiver MUST not look at the stream ID. And messages SHOULD be sent
on particular streams. This would result in
- implementations are highly encouraged and required to use
   multiple streams.
- being able to communicate with a peer not being able to handle  
multiple
   streams.

But as you see, this is a general problem and it should be solved for  
all
adaptation layers...

Best regards and happy testing
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?
> *******
>
> Some implementations accept this and allow the assoc to come up and  
> be used.
> Some implementations are not responding at all.
> Some implementations are responding with an INIT_ACK chunk with
> OUT_OF_RESOURCES error code.
> Some implementations are allowing the assoc to come up but are then  
> aborting
> the assoc.
>
> 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
>