SIGTRAN Plugtest Day 1

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