SIGTRAN Plugtest Day 5
"Barry Nagelberg" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Greetings (and farewell) from Moscow! Here is the wrap-up report for Day 5
of the SIGTRAN Plugtest.
Protocols tested:
M2PA - 3 implementations
M2UA - 3 implementations
M3UA - 6 implementations
SUA - 2 implementations
Issues raised during testing:
*******
Issue 1 - There is a contradiction in the M3UA spec regarding the use of the
ASPUP msg in Double Exchange mode.
*******
Section 4.3.4.1.2. (IPSP Considerations (ASP Up)) states that:
" ... when using the IPSP DE model, an interchange of ASP Up
messages from each end MUST be performed."
However section 5.6.2 shows that the 2nd exchange is optional:
5.6.2. Double Exchange
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
*******
Issue 2 - There is a contradiction in the M3UA spec regarding the use of the
"Invalid Routing Context" error code.
*******
Section 3.8.1. (Error) states:
" The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value.
For this error, the invalid Routing Context(s) MUST be included in
the Error message."
However section 4.3.4.3. (ASP Active Procedures) states the opposite:
" - If the RC parameter is not included in the ASP Active message and
there are no RKs defined, the peer node SHOULD respond with and
ERROR message with the Error Code "Invalid Routing Context".
*******
Issue 3 - There is a contradiction between the M3UA spec and the other specs
regarding the port number.
*******
M3UA states that implementations MAY use a port number other than the IANA
port number, while the other xUA specs are silent on this matter.
*******
Issue 4 - Alternate personalities
*******
There is a fielded M3UA implementation that is behaving alternately as
either an SPG or an ASP, on the same IP address and port number. This was
discussed in the group and the consensus is that this is very confusing
behaviour in terms of interoperability. The group feels that it would be
helpful if a definitive statement forbidding such alternate personalities
would be added to the spec.