Subject: [Sigtran] SIGTRAN Plugtest Day 1

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 17 Apr 2007 11:25:57 +0400

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-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Apr 2007 09:49:54 +0200

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

> 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  
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.
> 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  
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.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Apr 2007 13:39:08 +0200

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 17 Apr 2007 08:30:33 -0400

Hi Barry,

My 2 cents below...

   Thanks,
   Tolga

> -----Original Message-----
> From: Barry Nagelberg [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 3:26 AM
> To: SIGTRAN Mailing List
> Subject: [Sigtran] SIGTRAN Plugtest Day 1
> 
> handle the registration request? The problem is that the SGP doesn't
know
> to
> applies to all Network Appearances", it is not stated what the SGP
should
> do
[TOLGA]I guess the biggest mistake with this statement in RFC4666 is
that a RK can apply to more than one network appearance. A RK is not
supposed to span a SPMC. This wasn't there in the previous M3UA RFC. To
me, it is an obvious bug.
> The consensus of the group is that the M3UA/SUA specs are unclear
about
> how
[TOLGA]Would something be really broken if we allow only one stream? I
guess Michael's point was also this.
> if it has not yet sent ASPUP?
[TOLGA]My understanding is that double exchange mode is two coupled
client/server relationships. If the implementation in question received
ASPUP, sent ASPUP-ACK, then it should accept ASP-ACTIVE, even if it did
not send ASPUP yet.
> b. Is it OK for the server to send ASPUP?
[TOLGA]Sure, there are no servers and clients for IPSP (O.K., for double
exchange implicitly there are. Actually I still don't see the need for
double exchange mode. I very well maybe wrong but I guess it would be
beneficial to discuss the need for double exchange mode (both for M3UA
and SUA) in detail in the mailing list)