Subject: RE: [Sigtran] SIGTRAN Interop, Day 3 - M2PA v13 Procedures

From: [email-masked]
Date: Thu, 15 Sep 2005 04:03:44 -0700

All,

As Michael indicated in his original email, here are the M2PA v13 issues
observed at the SIGTRAN Interop, Day 3:

-In M2PA v13, an interpretation of the LPO Procedure / Process as
follows:- 
When an IPSP (A) enters LPO, the Link Status LPO is sent to the Peer
IPSP (B). 
During LPO, IPSP A will not send User Data to B, nor will it Ack User
Data received from B.
When IPSP A then sends LS PR to IPSP B, it will continue to not send
User Data to B, nor will it Ack User Data received from B until LS Ready
are exchanged.
Once LS Ready are sent and received from A and B, User Data and Acks
will start.

1. Comments on this interpretation?
2. Minor question: should there be any timer or other mechanism that
checks against receipt of Peer's LS Ready after PR has been sent?

-RPO / LS Ready receipt behavior in M2PA v13- 
In M2PA v13, when a peer IPSP (A) is in RPO, and receives LS PR from the
peer IPSP (B), IPSP (A) sends LS Ready. 
In the case where IPSP (B) never sends LS Ready in response, what should
be the behavior at IPSP (A)?

-It was generally agreed by the group here that an IPSP should enforce
the SCTP Stream Mapping for messages sent as defined in version 13, but
should accept messages on either stream on the receive side.-

Regards,
Charles 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Tuexen
Sent: Thursday, September 15, 2005 5:04 AM
To: Sigtran
Subject: [Sigtran] SIGTRAN Interop, Day 3

Dear all,

SUA and M2PA issues will be sent out separately.

First issue:
draft-ietf-sigtran-rfc3332bis-04.txt states:

    Routing Key - A Routing Key describes a set of SS7 parameters and
    parameter values that uniquely define the range of signalling
traffic
    to be handled by a particular Application Server. Parameters within
    the Routing Key cannot extend across more than a single Signalling
    Point Management Cluster.

and

    The format of the Routing Key parameter is as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Local-RK-Identifier                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Routing Context (optional)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Traffic Mode Type (optional)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Network Appearance (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                              ...                              /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Note: The Destination Point Code, Service Indicators, and
       Originating Point Code List parameters MAY be repeated as a
       grouping within the Routing Key parameter, in the structure shown
       above.

Using the definition above there should be no multiple DPCs in the
routing key.

Second issue:
draft-ietf-sigtran-rfc3332bis-04.txt states:

       The optional ASP Identifier parameter contains a unique value
that
       is locally significant among the ASPs that support an AS.

This text is not clear.

It was consensus here, that
- Every ASP has one ASP Identifier
- For every AS these values have to be unique between all ASPs in that
AS.

Is that correct? Can the text be changed?

Third issue:
There is no limit on message sizes. Could there be a specified minimum
message size that can be handled by every implementation? It would also
be good to say how, for example, long BEAT messages are handled. Some
implementations can not handle, for example, 50000 byte BEAT message and
send back an ERROR. 
Having this
described and having a limit which BEAT are really reflected seems to be
helpful.

Fourth issue:
It was discussed how an ASP should react if it gets a DAVA for its own
PC. The result was that it should send an ERR or so.

Fifth issue:
It is not specified how you handle incorrect PPIDs. For example if an
M3UA SG receives a message with a PPID indicating SUA.

Best regards
Michael

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Sep 2005 06:40:00 -0600

charles.hastings,

[email-masked] wrote:                                    (Thu, 15 Sep 2005 04:03:44)
> checks against receipt of Peer's LS Ready after PR has been sent?

We already pretty much agreed to alter this in 48 Hours (which is now)
to allow data transmission once the peer has _sent_ LS Ready rather than
when it has _received_ it.  The other timer in play is MTP3's T1 timer
that will fail the link if it is blocked too long.

> be the behavior at IPSP (A)?

The above modification handles that.  IPSP (A) starts sending data once
it has _sent_ LS Ready.

> should accept messages on either stream on the receive side.-

It would be foolish to accept message on either stream, because placing
message on the wrong stream will result in missequencing and loss of
messages across a number of procedures.  Any implementation that is that
lax at sending them should use UDP. ;)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/