Subject: SUAv7: Comments

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 09:53:25 -0500

John,

The following are some comments for last call on the SUAv7 draft:

Section 1.3.1.1 SG as endpoint 

     -  Source address: unique address provided so that when used as 
        the SCCP called party address in the SEP, it MUST yield the 
        same AS, the SSN might be sufficient. 

Change "MUST" to "must".  There is no need for "MUST" in an example.

Section 1.5.1 Address Mapping at the SG 

     If there is no match for an incoming message, a default treatment 
     MUST be specified.  ...
     
Change "MUST" to "MAY" (this is consistent with M3UA) as there is
no interoperability issue.  For some RKs, rather than providing a
default treatment, a non-default treatment within SCCP might be more
appropriate.

Section 1.5.2 Address Mapping at the ASP 

     To direct messages to the SS7 network, the ASP MUST perform an 
     address mapping to choose the proper SGP for a given message.

Not that I disagree with this requirement, but it is inconsistent
with M3UA's view of the world.

Section 1.5.3 Address Mapping Function at a Relay Node 

     To prevent looping, a hop counter is used. The originating end node 
     (be it an SS7 or an IP node) sets the value of the hop counter to 
     the maximum value (15 or less). Each time the relay function is 
     invoked within an intermediate (relay) node, the hop counter MUST be 
     decremented. When the value reaches zero, the return or refusal 
     procedures are invoked with reason "Hop counter violation". 

The wording appears to place a requirement ("MUST") on the SS7
network.  Change "MUST be" to "is".

Section 1.5.4 SCTP Stream Mapping

   SUA MUST use stream 0 for SUA management messages. It is recommended 
   that sequenced delivery be used to preserve the order of management 
   message delivery. 

No significant interoperability issue will result if SUA management
messages are presented on another stream.  Change "MUST" to "SHOULD".
Also, change "recommended" to "RECOMMENDED".

     -    Protocol class 0: SUA SHOULD select an unordered stream. 
     -    Protocol class 1: SUA MUST select an ordered stream, based on 
          a sequence parameter given by the upper layer over the 
          primitive interface. 
     -    Protocol classes 2 and 3: SUA will select an ordered stream, 
          based on its own source local reference. 

Change the wording "unordered stream" and "ordered stream" to
"unordered delivery" and "ordered delivery within a stream".
For protocol classes 2 and 3, change "will" to "MUST".

Section 3.8.5 Affected Point Code 

   For use in SUA, the mask parameter MUST always be coded zero and 
   there MUST be only a single point code present. 

Change the first "MUST" to "SHOULD" and add "The SUA mask parameter
SHOULD be ignored by the receiving peer."

Section 3.9.2.3 Global Title 

   All filler bits MUST be set to 0. 

Change "MUST" to "SHOULD".  There are no interoperability issues
with setting filler bits to random patterns.

Section 4.1 SCCP û SUA Interworking at the SG 

   The SGP MUST take care of any segmentation / reassembly issues at 
   the border of the SS7 and IP networks.  The IPSP may not have any 

Change "MUST" to "SHOULD".

Section 4.1.1 Connection Oriented Procedures 

   The SGP MUST take care of any segmentation / reassembly issues at 
   the border of the SS7 and IP networks.  The IPSP may not have any 

Again here, but this is the Segmentation/Reassembly issue.

The "SUA-User" is not defined in the terminology.  It is not clear
whether this is an SCCP-User or not.  It appears:

  Section 1.5.3 Address Mapping Function at a Relay Node 

     -    A local SUA-user (combined relay/end node) 

  Section 1.5.4 SCTP Stream Mapping 

     The SUA supports SCTP streams. The SG/AS needs to maintain a list of 
     SCTP and SUA-users for mapping purposes.  SCCP-users requiring 

  Section 3.4.1 Destination Unavailable (DUNA) 

     The SUA-User at the ASP is expected to stop traffic to the affected 
     destination or SCCP-user through the SGP or relay node initiating 

  Section 3.4.2 Destination Available (DAVA) 

     reachable. The ASP SUA-User protocol is expected to resume traffic 
     to the affected destination through the SGP or relay node initiating 
     the DAVA.  

  Section 4.2 Primitives received from the local SUA-user 

     The address information passed by the SUA-user at an ASP MUST 
     contain either: 
    
       -    A valid SS7 address to reach a destination in the SS7 network 
            via the appropriate SCTP association to a SG. 
       -    A valid IP address/hostname to reach another ASP in the IP 
            network via the appropriate SCTP association. 

It is very unclear from these passages whether an SUA-User is the
same as the SCCP-User or not, and if it is different, what the
differences are.  This last "MUST" is particularly confusing:
existing SCCP-Users do not pass IP address/hostname information.

Section 1.5.2 Address Mapping at the ASP 

     An ASP SHOULD send responses only to that SGP that it received 
     messages from; within the routing context which it is currently 
     active and receiving traffic.  The routing context itself is 
     effectively used by the ASP to select the SGP. 

No disagreement here, but this is rather inconsistent with M3UA's
view of the world.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Tue, 21 Aug 2001 13:34:50 +0300

Brian,

Before I throw this one onto the issues list, some clarification
is needed.

> Change "MUST" to "must".  There is no need for "MUST" in an example.

Agreed.

> default treatment, a non-default treatment within SCCP might be more

Agreed

> with M3UA's view of the world.

What is it that you wish SUA to do?

> network.  Change "MUST be" to "is".

Agreed.

> Also, change "recommended" to "RECOMMENDED".

Agreed.

> For protocol classes 2 and 3, change "will" to "MUST".

Agreed.

> SHOULD be ignored by the receiving peer."

Agreed.

> with setting filler bits to random patterns.

Agreed.

> Change "MUST" to "SHOULD".

Agreed.

> Again here, but this is the Segmentation/Reassembly issue.

That will be handled in the other issue.

> existing SCCP-Users do not pass IP address/hostname information.

Would ULP be better (Upper Layer Protocol)?  The last part (4.2) is
an either/or statement - so if the first clause is met, then the
MUST is covered.

> No disagreement here, but this is rather inconsistent with M3UA's

What is it that you wish SUA to do?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 14:48:27 -0500

John,

The "Agreed's" need not be issues if they can be closed now.

The AMF inconsistency with M3UA I would like to be logged as an issue.
(Perhaps that issue will resolve itself.)

The SUA-User is another issue.  Calling it an ULP doesn't resolve the
confusion as to what this SUA-User thing is and why is it different from an
SCCP-User.  It looks like this SUA-User can provide addresses of which
SCCP-Users are not capable.  Why?  I though SUA was transporting SCCP?  If you
want a general purpose network protocol similar to SCCP but with different
addressing schemes, use OSI NSD.  Why have this definition for SUA which is
not in SCCP?  Well,... you get my point.  That's the issue.  Perhaps
call it "Suitability of SUA-User Definition".

--brian

John Loughney wrote:                                         (Tue, 21 Aug 2001 13:34:50)
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 15:48:45 +0200

Let me venture a definition of SUA-user :

- it can be an SCCP-user, for which SUA provides the same services as
expected from SCCP
- it can be a new (SUA-)user, identified nonetheless by an SSN as well,
using hostname and IP address as address parameters; something which the
classic SCCP-users wouldn't do (they continue using GT or PC).

Regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 21 augustus 2001 21:48
To: sigtran
Subject: Re: SUAv7: Comments

John,

SCCP-Users are not capable.  Why?  I though SUA was transporting SCCP?  If
you

--brian

John Loughney wrote:                                         (Tue, 21 Aug
2001 13:34:50)
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 12:41:50 -0500

Gery,

That's what I was afraid of...  Do you think that it is within
the scope of SUA or even the SIGTRAN charter to define new
or enhanced user parts for SS7?

If so, we had better augment OPC and DPC in M3UA with IP address
as well, rather than just SI, let's add SCTP port number for
identifying user parts, and maybe we should add Ethernet MAC to
M2UA, .... ;)

It might be better to hold to the scope of transporting SCCP
in the SUA draft without augmentations to SCCP-Users.  There is
plenty of room for augmentations if required in extension drafts
under a more suitable charter than SIGTRAN's.

--brian

Verwimp Gery wrote:                                       (Wed, 22 Aug 2001 15:48:45)

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

---