Subject: [Sigtran] M3UA default AS

From: "Wung, Joseph" <[email-masked]>
Date: Thu, 9 Jan 2003 19:02:49 -0500

M3UA section 1.4.2.4 says

	"When there is no matching Routing Key entry for an
	incoming SS7 message, a default treatment MAY be
	specified.  Possible solutions are to provide a default
	AS at the SGP that directs all unallocated traffic to a
	(set of) default ASP(s), or to drop the message and
	provide a notification to layer management."

I have, say, 3 ASPs:
	ASP-1 for OPC/DPC/CIC=1-24
	ASP-2 for OPC/DPC/CIC=25-48
	ASP-3 for OPC/DPC/CIC=49-72,
	where OPC/DPC are the same.

How would the SGP route an incoming message with OPC/DPC/CIC=100.
My question is since the default AS is not registered, thus no
associated traffic mode, how does the SGP know the received 
message should be broadcast to all 3 of the ASPs or select one 
of them to send to?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Jan 2003 18:55:58 -0700

Joseph,

Don't try to use CIC routing for this: use CIC load-sharing.
Then the SG knows that it can send CIC=100 to any of the ASPs in
the load-share AS.  If you need to have controlled load-sharing
consider:

	draft-bidulock-sigtran-loadsel-01.txt and
	draft-bidulock-sigtran-loadgrp-01.txt

that I have just submitted to the I-D drafts editor.

Until they are available on the I-D server, you will find a copy
here:

	http://www.openss7.org/sigtran01.html

--brian

Wung, Joseph wrote:                                                                  (Thu, 09 Jan 2003 19:02:49)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 9 Jan 2003 23:38:11 -0600 (CST)

I think it would be good if we remove all SSN(sub system number)
references from RFC or make a global statement in IG as "SSN will not be
supported by RFC 3332 and wherever it is being referred it should be
ignored"

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Jan 2003 23:38:15 -0700

Samuel,

I agree and it was the concensus of the thread at LC that references
to SSN as routing key be removed from the spec and not mentioned.
Thus leaving it open for someone to implement if they can find a way
(which is not hopeful).

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 09 Jan 2003 23:38:11)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 00:09:34 -0700

Samuel,

The following IG entry would remove references to SSN and CIC from
the document.  It this what you had in mind?

--brian

> supported by RFC 3332 and wherever it is being referred it should be

 ------------------------------------------------------------------------

 3.16 SSN and CIC Routing Keys

 3.16.1 Description of the problem

    Use of SSN and CIC Routing Keys is inadequate in the specification
    leading to non-interoperable solutions.

 3.16.2 Text changes to the document

    ---------
    Old text: (Section 1.4.2.1)
    ---------

    Possible SS7 address/routing information that comprise a Routing Key
    entry includes, for example, the OPC, DPC, SIO found in the MTP3
    routing label, or MTP3-User specific fields (such as the ISUP CIC,
    SCCP subsystem number).  Some example Routing Keys are: the DPC
    alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
    DPC/SSN combination.  The particular information used to define an
    M3UA Routing Key is application and network dependent, and none of
    the above examples are mandated.

    ---------
    New text: (Section 1.4.2.1)
    ---------

    Possible SS7 address/routing information that comprise a Routing Key
    entry includes, for example, the OPC, DPC, SIO found in the MTP3
    routing label.  Some example Routing Keys are: the DPC alone, the
    DPC/OPC combination, or the DPC/OPC/SI combination.  The particular
    information used to define an M3UA Routing Key is application and
    network dependent, and none of the above examples are mandated.

    ---------
    Old text: (Section 1.4.2.2)
    ---------

    Routing Keys SHOULD be unique in the sense that each received SS7
    signalling message SHOULD have a full or partial match to a single
    routing result. It is not necessary for the parameter range values
    within a particular Routing Key to be contiguous.  For example, an AS
    could be configured to support call processing for multiple ranges of
    PSTN trunks that are not represented by contiguous CIC values.

    ---------
    New text: (Section 1.4.2.2)
    ---------

    Routing Keys SHOULD be unique in the sense that each received SS7
    signalling message SHOULD have a full or partial match to a single
    routing result. It is not necessary for the parameter range values
    within a particular Routing Key to be contiguous.

    ---------
    Old text: (Section 1.4.7)
    ---------

    The M3UA layer at both the SGP and ASP also supports the assignment
    of signalling traffic into streams within an SCTP association.
    Traffic that requires sequencing SHOULD be assigned to the same
    stream.  To accomplish this, MTP3-User traffic may be assigned to
    individual streams based on, for example, the SLS value in the MTP3
    Routing Label or the ISUP CIC assignment, subject of course to the
    maximum number of streams supported by the underlying SCTP
    association.

    ---------
    New text: (Section 1.4.7)
    ---------

    The M3UA layer at both the SGP and ASP also supports the assignment
    of signalling traffic into streams within an SCTP association.
    Traffic that requires sequencing SHOULD be assigned to the same
    stream.  To accomplish this, MTP3-User traffic may be assigned to
    individual streams based on, for example, the SLS value in the MTP3
    Routing Label, subject of course to the maximum number of streams
    supported by the underlying SCTP association.

    ---------
    Old text: (Section 1.5.3)
    ---------

    In this example, the SGP contains an instance of the SS7 SCCP
    protocol layer that may, for example, perform the SCCP Global Title
    Translation (GTT) function for messages logically addressed to the SG
    SCCP.  If the result of a GTT for an SCCP message yields an SS7 DPC
    or DPC/SSN address of an SCCP peer located in the IP domain, the
    resulting MTP-TRANSFER request primitive is sent to the local M3UA-
    resident network address translation and mapping function for ongoing
    routing to the final IP destination.

    ---------
    New text: (Section 1.5.3)
    ---------

    In this example, the SGP contains an instance of the SS7 SCCP
    protocol layer that may, for example, perform the SCCP Global Title
    Translation (GTT) function for messages logically addressed to the SG
    SCCP.  If the result of a GTT for an SCCP message yields an SS7 DPC
    or DPC/SI address of an SCCP peer located in the IP domain, the
    resulting MTP-TRANSFER request primitive is sent to the local M3UA-
    resident network address translation and mapping function for ongoing
    routing to the final IP destination.

    ---------
    Old text: (Section 1.5.3)
    ---------

    For internal SGP modeling purposes, this may be accomplished with the
    use of an implementation-dependent nodal interworking function within
    the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
    request/indication messages to/from both the MTP3 and the M3UA layer,
    based on the SS7 DPC or DPC/SSN address information.  This nodal
    interworking function has no visible peer protocol with either the
    ASP or SEP.

    ---------
    New text: (Section 1.5.3)
    ---------

    For internal SGP modeling purposes, this may be accomplished with the
    use of an implementation-dependent nodal interworking function within
    the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
    request/indication messages to/from both the MTP3 and the M3UA layer,
    based on the SS7 DPC or DPC/SI address information.  This nodal
    interworking function has no visible peer protocol with either the
    ASP or SEP.

    ---------
    Old text: (Section 3.2)
    ---------

         Congestion Indications                0x0205
         Concerned Destination                 0x0206
         Routing Key                           0x0207
         Registration Result                   0x0208
         Deregistration Result                 0x0209
         Local_Routing Key Identifier          0x020a
         Destination Point Code                0x020b
         Service Indicators                    0x020c
         Reserved                              0x020d
         Originating Point Code List           0x020e
         Circuit Range                         0x020f
         Protocol Data                         0x0210
         Reserved                              0x0211
         Registration Status                   0x0212
         Deregistration Status                 0x0213

    ---------
    New text: (Section 3.2)
    ---------

         Congestion Indications                0x0205
         Concerned Destination                 0x0206
         Routing Key                           0x0207
         Registration Result                   0x0208
         Deregistration Result                 0x0209
         Local_Routing Key Identifier          0x020a
         Destination Point Code                0x020b
         Service Indicators                    0x020c
         Reserved                              0x020d
         Originating Point Code List           0x020e
         Protocol Data                         0x0210
         Reserved                              0x0211
         Registration Status                   0x0212
         Deregistration Status                 0x0213

    ---------
    Old text: (Section 3.6.1)
    ---------

       |                  Traffic Mode Type (optional)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Network Appearance (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Circuit Range List (optional)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                              ...                              /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination Point Code                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Service Indicators (optional)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Originating Point Code List (optional)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Circuit Range List (optional)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
       Note: The Destination Point Code, Service Indicators, Originating
       Point Code List and Circuit Range List parameters MAY be repeated
       as a grouping within the Routing Key parameter, in the structure
       shown above.

    ---------
    New text: (Section 3.6.1)
    ---------

       |                  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.

    ---------
    Old text: (Section 3.6.1)
    ---------

    Circuit Range:
 
       An ISUP controlled circuit is uniquely identified by the SS7 OPC,
       DPC and CIC value.  For the purposes of identifying Circuit Ranges
       in an M3UA Routing Key, the optional Circuit Range parameter
       includes one or more circuit ranges, each identified by an OPC and
       Upper/Lower CIC value.  The DPC is implicit as it is mandatory and
       already included in the DPC parameter of the Routing Key.  The
       absence of the Circuit Range parameter in the Routing Key
       indicates the use of any Circuit Range values, in the case of
       ISUP/TUP traffic.  The Origination Point Code is encoded the same
       as the Destination Point Code parameter, while the CIC values are
       16-bit integers.

    ---------
    New text: (Section 3.6.1)
    ---------

    (none)
 
    ---------
    Old text: (Section 3.6.1)
    ---------

    The Circuit Range format 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag = 0x020f        |              Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Mask = 0   |          Origination Point Code #1            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Lower CIC Value #1      |      Upper CIC Value #1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Mask = 0   |          Origination Point Code #2            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Lower CIC Value #2      |      Upper CIC Value #2       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                              ...                              /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Mask = 0   |          Origination Point Code #n            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Lower CIC Value #n      |      Upper CIC Value #n       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    ---------
    New text: (Section 3.6.1)
    ---------

    (none)

    ---------
    Old text: (Section 3.7.1)
    ---------

       An Application Server Process may be configured to process traffic
       for more than one logical Application Server.  From the
       perspective of an ASP, a Routing Context defines a range of
       signalling traffic that the ASP is currently configured to receive
       from the SGP.  For example, an ASP could be configured to support
       call processing for multiple ranges of PSTN trunks and therefore
       receive related signalling traffic, identified by separate SS7
       DPC/OPC/CIC ranges.

    ---------
    New text: (Section 3.7.1)
    ---------

       An Application Server Process may be configured to process traffic
       for more than one logical Application Server.  From the
       perspective of an ASP, a Routing Context defines a range of
       signalling traffic that the ASP is currently configured to receive
       from the SGP.  For example, an ASP could be configured to support
       call processing for multiple ranges of PSTN trunks and therefore
       receive related signalling traffic, identified by separate SS7
       DPC/OPC/SI ranges.

    ---------
    Old text: (Section 4.4.1)
    ---------

    If an SGP determines that one or more of the Routing Key parameters
    are not supported for the purpose of creating new Routing Key
    entries, the SGP returns a Registration Response message to the ASP,
    containing a Registration Result "Error - Unsupported RK parameter
    field".  This result MAY be used if, for example, the SGP does not
    support RK Circuit Range Lists in a Routing Key because the SGP does
    not support ISUP traffic, or does not provide CIC range granularity.

    ---------
    New text: (Section 4.4.1)
    ---------

    If an SGP determines that one or more of the Routing Key parameters
    are not supported for the purpose of creating new Routing Key
    entries, the SGP returns a Registration Response message to the ASP,
    containing a Registration Result "Error - Unsupported RK parameter
    field".

    ---------
    Old text: (Section A.2.1)
    ---------

    For example, where Application Servers are defined using ranges of
    ISUP CIC values, the Operator is implicitly splitting up control of
    the related circuit groups.  Some CIC value range assignments may
    interfere with ISUP circuit group management procedures.

    ---------
    New text: (Section A.2.1)
    ---------

    (none)
 
 3.16.3 Solution description

    The removal of reference to SSN and CIC used in Routing Keys as well
    as removal of Circuit Range from the Routing Key parameter removes
    the unclear text from the specification.

 ------------------------------------------------------------------------

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 10 Jan 2003 02:22:27 -0600 (CST)

Brian,

Ok, new changes hold good.

section 1.5.3

SCCP layer(an instance of the SS7 SCCP protocol layer) is placed above
M3UA layer and even performs GTT.
Once GTT is performed , nobody can restrict that result should be only
DPC, but result can be DPC/SSN also.

When you use M3UA , it conveys that your user-part services are
(including GTT) are offered remotely. So it causes little inconvenience
to view SCCP layer above M3UA.

--Samuel