RE: SIGTRAN Plugtest Day 1

Hi Barry,

My 2 cents below...

   Thanks,
   Tolga

> -----Original Message-----
> From: Barry Nagelberg [mailto:[email protected]]
> Sent: Tuesday, April 17, 2007 3:26 AM
> To: SIGTRAN Mailing List
> Subject: [Sigtran] 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.
[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.
> 
> *******
> 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."
[TOLGA]Would something be really broken if we allow only one stream? I
guess Michael's point was also this.
> 
> *******
> 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?
[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.
> 
> 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?
[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)
> 
> 
> Barry Nagelberg
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran