Subject: June 2001 mail archives part 2

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 18 Jul 2001 09:19:04 -0700

X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:51:11 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Missing Primitives
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Per your previous suggestion, ACTION_DROP_MSGS was removed and CLEAR_RTB
added.  I've only looked at the ITU specs so far, but I cannot find the
RB_CLEARED and RTB_CLEARED indications.  Can you provide a reference.
Further, what does MTP3 do with these indications?

Regards,

Ken

At 02:09 PM 6/17/01 -0500, you wrote:
>sigtran,
>
>Can I use Retrieve Request ACTION_DROP_MSGS for CLEAR_RTB?  Retrieve
>Confirm ACTION_DROP_MSGS for RTB_CLEARED?
>
>But should I use Status Confirm FLUSH_BUFFERS for RB_CLEARED?  The
>L2 hasn't necessarily cleared TB or RTB yet...
>
>
>On Sun, 17 Jun 2001, Brian F. G. Bidulock wrote:
>
> > I have three primitives from ANSI/ITU specs that are sent between
> > L2 and L3 that I am having a problem finding an M2UA equivalent:
> > 
> >       RB_CLEARED
> >       RTB_CLEARED
> >       CLEAR_RTB
> > 
> > RB_CLEARED is an independent indication that is sent whenever
> > the Receive Buffer is cleared at L2.  RTB_CLEARED is an independent
> > indication that is sent whenever the Retransmission Buffer is
> > cleared.  CLEAR_RTB is a request which is sent from L3 to L2 to
> > independently clear only the Retransmission Buffer.
> > 
> > Can we add a CLEAR_RTB to the Status Request and a RB_CLEARED
> > and RTB_CLEARED to the Status Indication?
> > 
>
>-- 
>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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 08:59:18 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Registration messages and procedures
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I don't see a need for dynamic provisioning of this type for M2UA.  An
network or element management system would suffice.

Regards,

Ken

At 04:27 PM 6/16/01 -0500, you wrote:
>sigtran,
>
>I would like to propose the attached text to be included
>in the M2UA specification.  The text is consistent (stolen)
>from the M3UA specification and provides the ASP with the
>ability to control the dynamic registration of Interface
>Identifiers in support of the Automatic Allocation of
>Signalling Data Terminals and Signalling Data Links as
>provided for in the Q.704 and other specifications.
>
>--Brian
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>x.x.x Registration Request (REG REQ)
>
>The REG REQ message is sent by an ASP to indicate to a remote M2UA
>peer that it wishes to register one or more given Link Keys with the
>remote peer.  Typically, an ASP would send this message to an SGP,
>and expectes to receive a REG RSP in return with an associated
>Interface Identifier value.
>
>The REG REQ message contains the following parameters:
>
>      Link Key                Mandatory
>
>The format for the REG REQ message 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 = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                           Link Key 1                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                              ...                              /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                           Link Key n                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Link Key: fixed length
>
>    The Link Key parameter is mandatory.  The sender of this message
>    expects the receiver of this message will create a Link Key entry
>    and assign a unique Interface Identifier value to it, if the Link
>    Key entry does not yet exist.
>
>    The Link Key parameter may be present multiple times in the same
>    message.  This is used to allow the registration of multiple Link
>    Keys in a single message.
>
>The format of the Link 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-LK-Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Signalling Data Terminal Identifier           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Signalling Data Link Identifier             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Local-LK-Identifier: 32-bit integer
>
>    The mandatory Local-LK-Identifier field is used to uniquely
>    identify the registration request.  The Identifier value is
>    assigned by the ASP, and is used to correlate the response in a
>    REG RSP message with the original registration request.  The
>    Identifier value must remain unique until the REG RSP is
>    received.
>
>    The format of the Local-LK-Identifier field 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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Local-LK-Identifier value                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Signalling Data Terminal Identifier:
>
>    The Signalling Data Terminal Identifier parameter is mandatory,
>    and identifies the Signalling Data Terminal associated with the
>    SS7 link for which the ASP is registering.  The 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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Reserved             |        SDT Identifier         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The SDT Identifier is a 32-bit unsigned value which may only be
>    significant to 12 or 14 bits depending on the SS7 variant which
>    is supported by the MTP Level 3 at the ASP.  Insignificant SDTI
>    bits are coded 0.
>
>Signalling Data Link Identifier:
>
>    The Signalling Data Link Identifier parameter is mandatory, and
>    identifies the Siganlling Data Link Identifier associated with
>    the SS7 link for which the ASP is registering.  The 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 = ??            |         Length = 8            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Reserved             |        SDL Identifier         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The SDL Identifier is a 32-bit unsigned value which may only be
>    significant to 12 or 14 bits depending on the SS7 variant which
>    is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
>    bits are coded 0.
>
>x.x.x Registration Response (REG RSP)
>
>The REG RSP message is used as a response to the REG REQ message
>from a remote M2UA peer.  It contains indications of success/failure
>for registration requests and returns a unique Interface Identifier
>value for successful registration requests, to be used in subsequent
>M2UA Traffic Management protocol.
>
>The REG RSP message contains the following parameters:
>
>      Registration Results   Mandatory
>
>The format for the REG RSP message 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 = ??           |         Length = var.         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Registration Result 1                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    /                              ...                              /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Registration Result n                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Registration Results:
>
>    The Registration Results parameter contains one or more results,
>    each containing the registration status for a single Link Key in
>    the REG REQ message.  The number of results in a single REG RSP
>    message MAY match the number of Link Key parameters found in the
>    corresponding REG REQ message.  The format of each result 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-LK-Identifier value                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Registration Status                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Interface Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Local-LK-Identifier: 32-bit integer
>
>    The Local-LK-Identifier contains the same value as found in the
>    matching Link Key parameter found in the REG Req message.
>
>Registration Status: 32-bit integer
>
>    The Registration Result Status field indicates the success or the
>    reason for failure of a registration request.
>
>    Its values may be:
>
>         0           Successfully Registered
>         1           Error - Unknown
>         2           Error - Invalid SDLI
>         3           Error - Invalid SDTI
>         4           Error - Invalid Link Key
>         5           Error - Permission Denied
>         6           Error - Overlapping (Non-unique) Link Key
>         7           Error - Link Key not Provisioned
>         8           Error - Insufficient Resources
>
>Interface Identifier: 32-bit integer
>
>    The Interface Identifier field contains the Interface Identifier
>    for the associated Link Key if the registration is successful.
>    It is set to "0" if the registration was not successful.
>
>x.x.x De-Registration Request (DEREG REQ)
>
>The DEREG REQ message is sent by an ASP to indicate to a remote M2UA
>peer that it wishes to de-register a given Link Key.  Typically, an
>ASP would send this message to an SGP, and expects to receive a
>DEREG RSP in return with the associated Interface Identifier value.
>
>The DEREG REQ message contains the following parameters:
>
>      Interface Identifier  Mandatory
>
>The format for the DEREG REQ message 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 = ??           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    /                                                               /
>    \                    Interface Identifier                       \
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Interface Identifier: n X 32-bit integers
>
>    The Interface Identifier parameter contains (a list of) integer
>    indexing the Application Server traffic that the sending ASP is
>    currently registered to receive from the SG but now wishes to
>    deregister.
>
>x.x.x De-Registration Response (DEREG RSP)
>
>The DEREG RSP message is used as a response to the DEREG REQ message
>from a remote M2UA peer.
>
>The DEREG RSP message contains the following parameters:
>
>      De-registration Results    Mandatory
>
>The format for the DEREG RSP message 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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Interface Identifier                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     De-Registration Status                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Interface Identifier: 32-bit integer
>
>    The Interface Identifier field contains the Interface Identifier
>    value of the matching Link Key to deregister, as found in the
>    DEREG Req.
>
>De-Registration Status: 32-bit integer
>
>    The De-Registration Result Status field indicates the success or
>    the reason for failure of the de-registration.
>
>    Its values may be:
>         0           Successfully De-registered
>         1           Error - Unknown
>         2           Error - Invalid Interface Identifier
>         3           Error - Permission Denied
>         4           Error - Not Registered
>
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>x.x.x Link Key Management Procedures
>
>x.x.x.1 Registration
>
>An ASP MAY dynamically register with an SG as an ASP within an
>Application Server using the REG REQ message.  A Link Key parameter
>in the REG REQ specifies the parameters associated with the Link
>Key.
>
>The SG examines the contents of the received Link Key parameter and
>compares it with the currently provisioned Link Keys.  If the
>received Link Key matches an existing SG Link Key entry, and the ASP
>is not currently included in the list of ASPs for the related
>Application Server, the ASP MAY authorize the ASP to be added to the
>AS.  Or, if the Link Key does not currently exist and the received
>Link Key data is valid and unique, an SG supporting dynamic
>configuration MAY authorize the creation of a new Link Key and
>related Application Server and add the ASP to the new AS.  In either
>case, the SG returns a Registration Response message to the ASP,
>containing the same Local-LK-Identifier as provided in the initial
>request, and a Registration Result "Successfully Registered".  A
>unique method of Interface Identifier valud assignment at the SG/SGP
>is implementation dependent but must be guaranteed to be unique
>across all SGPs in an SG.
>
>If the SG determins that the received Link Key data is invalid, or
>contains invalid parameter values, the SG returns a Registration
>Response message to the ASP, containing a Registration Result "Error
>- Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI"
>as appropriate.
>
>If the SG determins that the Link Key parameter overlaps with an
>existing Link Key entry, the SG returns a Registration Response
>message to the ASP, with a Registration Status of "Error -
>Overlapping (Non-Unique) Link Key".  An incoming signalling message
>received at an SG cannot match against more than one Link Key.
>
>If the SG does not authorize the registration request, the SG
>returns a REG RSP message to the ASP containing the Registration
>Result "Error - Permission Denied".
>
>If an SG determines that a received Link Key does not currently
>exist and the SG does not support dynamic configuration, the SG
>returns a Registration Response message to the ASP, containing a
>Registration Result "Error - Link Key not Provisioned".
>
>If an SG determines that a received Link Key does not currently
>exist and the SG supports dynamic reconfiguration but does not have
>the capacity to add new Link Key and Application Server entries, the
>SG returns a Registration Response message to the ASP, containing a
>Registration Result "Error - Insufficient Resources".
>
>An ASP MAY register multiple Link Keys at once by including a number
>of Link Key parameters in a single REG REQ message.  The SG MAY
>response to each registration request in a single REG RSP message,
>indicating the success or failure result for each Link Key in a
>separate Registration Result parameter.  Alternatively the SG MAY
>response with multiple REG RSP messages, each with one or more
>Registration Result parameters.  The ASP uses the Local-LK-Identifier
>parameter to correlate the requests with the responses.
>
>Upon successful registration of an ASP in an AS, the SG can now send
>related messaging, if this did not previsouly start upon the ASP
>transitioning to "Inactive".
>
>x.x.x.2 Deregistration
>
>An ASP MAY dynamically deregister with an SG as an ASP within an
>Application Server using the DEREG REQ message.  A Interface
>Identifier parameter in the DEREG REQ specifies which Link Key to
>de-register.
>
>The SG examines the contents of the received Interface Identifier
>parameter and validates that the ASP is currently registered in the
>Application Server(s) related to the included Interface
>Identifier(s).  If validated, the ASP is de-registered as an ASP in
>the related Application Server.
>
>The deregistration procedure does not necessarily imply the deletion
>of Link Key and Application Server configuration data at the SG.
>Other ASPs may continue to be associated with the Application
>Server, in which case the Link Key data CANNOT be deleted.  If a
>Deregistration results in no more ASPs in an Application Server, an
>SG MAY delte the Link Key data.
>
>The SG acknowledges the de-registration requres by returning a DEREG
>RSP to the requesting ASP.  The result of the de-registration is
>found in the Deregistration Result paraemeter, indicating success or
>faliure with cause.
>
>An ASP MAY deregister multiple Interface Identifiers at once by
>including a number of Interface Identifiers in a single DEREG REQ
>message.  The SG MUST response to each deregistration request in a
>single DEREG RSP message, indicating the success or failure result
>for each Interface Identifier in a separate Deregistration Result
>parameter.
>
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
>-- 
>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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2UA 08: Retrieval Request
Date: Mon, 18 Jun 2001 09:00:17 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: chi02.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: inetgw.il.neustar.com [209.173.57.225]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Just a small clarification:

MTP does provide the ability to only retrieve the transmission buffer:

Q.704, 5.6.1 states:
"...Instead, it directly starts sending the signalling traffic not yet
transmitted
                       ^^^^^^^^^^^^^^^^^^^ on the unavailable link on the
alternative signalling link(s)"

Q.2240, 6.1.2, is even more explicit:

"For cases in which an FSNC value is not obtained from MTP-3, the RN
parameter can convey a value of "unknown", and SSCOP returns only those
message units that have not yet been transmitted."

Klaus

> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: June 18, 2001 8:01 AM
> To: sigtran
> Subject: Re: M2UA 08: Retrieval Request
> 
> 
> 
> 
> Brian,
> 
> This Status Req and Retrieval Req text is cleaned up per
> your recommendations.
> 
> Ken
> 
> At 09:21 PM 6/14/01 -0500, you wrote:
> >Section 3.3.1.8
> >
> >The changes which were made to retrieval request are not
> >consistent with the common descriptions of M2UA from Q.703
> >and Q.2140/Q.2110.  These specs do not provide a mechanism
> >for retrieving as described in ACTION_RTRV_MSGS and
> >ACTION_RTRV_TRANS.  Both Q.703 and Q.2140/2110 described
> >signalling links only support the retrieval of BOTH the
> >messages in the retransmit and transmit buffers.
> >
> >If CLEAR_RTB is added to the states (as per previous mail)
> >consistent with the flush_buffers primitive, these three
> >can be reduced to a set which is consistent with the cited
> >and referenced recommendations.
> >
> >Remove ACTION_DROP_MSGS and ACTION_RTRV_TRANS, describe
> >ACTION_RTRV_MSGS as retrieving both RTB and TB contents,
> >and add STATUS_CLEAR_RTB to the status messages.  This
> >will make M2UA consistent with Q.703/Q.2140/Q.2110 as
> >well as T1.111.3.
> >
> >-- 
> >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] 
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 18 Jun 2001 10:09:28 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: ASPM procedures
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Yes, this text needs to be changed.  How about:

"At the ASP, the M2UA layer will take action based on the appropriate MTP
specification.  The ASP may indicate to another ASP that it should become
active.  However, the ASP to ASP communication is out of the scope of this
document."

Ken

At 10:00 PM 6/14/01 -0500, you wrote:
>Section 4.3.2
>
>         "... Athe [sic] ASP, M2UA shall either cause
>         other ASPs to become active or send link-out-
>         of-service primitives to MTP3."
>
>Just how was M2UA at the ASP going to cause other ASPs
>to become active?  Also, what indications are sent to
>MTP3 is certainly up to the ASP implementor and does
>not impact interoperability with any SG implementation,
>per previous discussion pertaining to SG actions towards
>MTP2.
>
>-- 
>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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 16:23:28 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]>
Subject: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: penguin-ext.wise.edt.ericsson.se [194.237.142.110]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

There is something unclear in the 3.4.6 chapter (Destination Restricted -
DRST), see in caps:

------------------------------------------------------------------------
"The DRST message is optionally sent from the SG to all concerned ASPs 
to indicate that the SG has determined that one or more SS7 destinations are
now restricted, or in response to a DAUD message if 
appropriate. The M3UA at the ASP is expected to send traffic to the 
affected destination via an alternate SG of equal priority, but only if 
such an alternate route exists and is available. IF THE AFFECTED DESTINATION
IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP, TRAFFIC TO 
THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD BE
RESUMED.
THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE ASP TO
PROCESS. It is for use in the "STP" case described in Section 1.4.2."
------------------------------------------------------------------------

If the affected destinations (those restricted, I presumed) are considered
unavailable by the ASP, then traffic can't be resumed neither
through the SG initiating the DRST nor the alternate SG. Don't you think
in this particular case, the DRST msg should be ignored by the ASP?

Apart from that, this message can NOT be optional for the ASP to process,
at least the ASP should be able to read and discard it, don't you agree?
Otherwise, interoperability will be impossible.

Thanks
/M.Cruz

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 09:31:52 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: chi02.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.173.57.225]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria,

receiving a TFR for a prohibited destination implicitly cancels the
prohibited status. If a destination were still prohibited, no TFR message
would be sent for it. The analog applies to DRST messages.

Klaus

> -----Original Message-----
> From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> [mailto:[email-masked]]
> Sent: June 18, 2001 10:23 AM
> To: sigtran
> Subject: M3UA: DRST message
> 
> 
> 
> Hi all,
> 
> There is something unclear in the 3.4.6 chapter (Destination
> Restricted - DRST), see in caps:
> 
> --------------------------------------------------------------
> ----------
> "The DRST message is optionally sent from the SG to all concerned
> ASPs 
> to indicate that the SG has determined that one or more SS7 
> destinations are now restricted, or in response to a DAUD message
> if 
> appropriate. The M3UA at the ASP is expected to send traffic to
> the 
> affected destination via an alternate SG of equal priority, but
> only if 
> such an alternate route exists and is available. IF THE AFFECTED
> DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> TRAFFIC TO 
> THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> BE
> RESUMED.
> THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> ASP TO
> PROCESS. It is for use in the "STP" case described in Section
> 1.4.2."
> --------------------------------------------------------------
> ----------
> 
> If the affected destinations (those restricted, I presumed) are 
> considered unavailable by the ASP, then traffic can't be resumed
> neither
> through the SG initiating the DRST nor the alternate SG. Don't you
> think
> in this particular case, the DRST msg should be ignored by the
> ASP?
> 
> Apart from that, this message can NOT be optional for the ASP to
> process,
> at least the ASP should be able to read and discard it, don't you
> agree?
> Otherwise, interoperability will be impossible.
> 
> Thanks
> /M.Cruz
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 10:44:56 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: M3UA: DRST message</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Maria ...</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Maria_Cruz_Bartolome_Rodrigo +34913393208 [<A
HREF="mailto:[email-masked]">mailto:maria-cruz
[email-masked]</A>] </FONT> <BR><FONT
SIZE=2>Sent:&nbsp;&nbsp; Monday, June 18, 2001 10:23 AM</FONT> <BR><FONT
SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M3UA: DRST
message</FONT> </P>
<BR>

<P><FONT SIZE=2>Hi all,</FONT>
</P>

<P><FONT SIZE=2>There is something unclear in the 3.4.6 chapter
(Destination</FONT> <BR><FONT SIZE=2>Restricted - DRST), see in caps:</FONT>
</P>

<P><FONT
SIZE=2>---------------------------------------------------------------------
---</FONT> <BR><FONT SIZE=2>&quot;The DRST message is optionally sent from
the SG to all concerned</FONT> <BR><FONT SIZE=2>ASPs </FONT>
<BR><FONT SIZE=2>to indicate that the SG has determined that one or more SS7
</FONT> <BR><FONT SIZE=2>destinations are now restricted, or in response to
a DAUD message</FONT> <BR><FONT SIZE=2>if </FONT>
<BR><FONT SIZE=2>appropriate. The M3UA at the ASP is expected to send
traffic to</FONT> <BR><FONT SIZE=2>the </FONT>
<BR><FONT SIZE=2>affected destination via an alternate SG of equal priority,
but</FONT> <BR><FONT SIZE=2>only if </FONT>
<BR><FONT SIZE=2>such an alternate route exists and is available. IF THE
AFFECTED</FONT> <BR><FONT SIZE=2>DESTINATION IS CURRENTLY CONSIDERED
UNAVAILABLE BY THE ASP,</FONT> <BR><FONT SIZE=2>TRAFFIC TO </FONT>
<BR><FONT SIZE=2>THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST
SHOULD</FONT> <BR><FONT SIZE=2>BE</FONT>
<BR><FONT SIZE=2>RESUMED.</FONT>
<BR><FONT SIZE=2>THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL
FOR THE</FONT> <BR><FONT SIZE=2>ASP TO</FONT>
<BR><FONT SIZE=2>PROCESS. It is for use in the &quot;STP&quot; case
described in Section</FONT> <BR><FONT SIZE=2>1.4.2.&quot;</FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------------
---</FONT> </P>

<P><FONT SIZE=2>If the affected destinations (those restricted, I presumed)
are </FONT> <BR><FONT SIZE=2>considered unavailable by the ASP, then traffic
can't be resumed</FONT> <BR><FONT SIZE=2>neither</FONT>
<BR><FONT SIZE=2>through the SG initiating the DRST nor the alternate SG.
Don't you</FONT> <BR><FONT SIZE=2>think</FONT>
<BR><FONT SIZE=2>in this particular case, the DRST msg should be ignored by
the</FONT> <BR><FONT SIZE=2>ASP?</FONT>
</P>

<P><FONT SIZE=2>[Greg] Klaus answered this one better than I could.</FONT>
</P>

<P><FONT SIZE=2>Apart from that, this message can NOT be optional for the
ASP to</FONT> <BR><FONT SIZE=2>process,</FONT>
<BR><FONT SIZE=2>at least the ASP should be able to read and discard it,
don't you</FONT> <BR><FONT SIZE=2>agree?</FONT>
<BR><FONT SIZE=2>Otherwise, interoperability will be impossible.</FONT> </P>

<P><FONT SIZE=2>[Greg] I agree - this was not the intent of the current
wording. How about &quot; ... and optional for the ASP to act on.&nbsp;
?</FONT> </P>

<P><FONT SIZE=2>Cheers,</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Greg Sidebottom</FONT> </P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>/M.Cruz</FONT>
</P>
<BR>
<BR>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Mon, 18 Jun 2001 16:59:49 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]>
Subject: Re: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross-ext.wise.edt.ericsson.se [194.237.142.116]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 16:59:49 +0200
From: Maria_Cruz_Bartolome_Rodrigo +34913393208 
      <[email-masked]> 
Subject: Re: M3UA: DRST message
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Organization: EEM/TD/LNA
X-Mailer: Mozilla 4.73C-EEM/TD [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-SMTP-HELO: albatross-ext.wise.edt.ericsson.se
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.237.142.116]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:02:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Missing Primitives
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

RTB_Cleared appears in ANSI Figure 7/T1.111.3.

RTB_Cleared is a confirmation of the Clear_RTB request.

--Brian

Ken Morneault wrote:                       (Mon, 18 Jun 2001 08:51:11)
> 
> 
> Brian,
> 
> Per your previous suggestion, ACTION_DROP_MSGS was 
> removed and CLEAR_RTB added.  I've only looked at the
> ITU specs so far, but I cannot find the RB_CLEARED and
> RTB_CLEARED indications.  Can you provide a reference.
> Further, what does MTP3 do with these indications?
> 
> Regards,
> 
> Ken
> 

-- 
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]
Date: Mon, 18 Jun 2001 10:06:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: ASPM procedures
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Sounds fine!

Ken Morneault wrote:                     (Mon, 18 Jun 2001 10:09:28)
> 
> 
> Brian,
> 
> Yes, this text needs to be changed.  How about:
> 
> "At the ASP, the M2UA layer will take action based on the 
> appropriate MTP specification.  The ASP may indicate to 
> another ASP that it should become active.  However, the 
> ASP to ASP communication is out of the scope of this 
> document."
> 
> Ken
> 
> At 10:00 PM 6/14/01 -0500, you wrote:
> >Section 4.3.2
> >
> >         "... Athe [sic] ASP, M2UA shall either cause
> >         other ASPs to become active or send link-out-
> >         of-service primitives to MTP3."
> >
> >Just how was M2UA at the ASP going to cause other ASPs
> >to become active?  Also, what indications are sent to
> >MTP3 is certainly up to the ASP implementor and does
> >not impact interoperability with any SG implementation,
> >per previous discussion pertaining to SG actions towards
> >MTP2.
> >

-- 
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: "Adams, Richard Anthony (Richard)" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 16:21:16 +0100
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: ihemail2.firewall.lucent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ihemail2.lucent.com [192.11.222.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maria, Greg and Klaus,
The "restricted" procedure is a national option in SS7. So the SG should NOT
send DRST if the network doesn't support restriction. I would assume an ASP
receiving DRST in such a network would just (have) to discard it - although
it could use it as an indication that the destination is now available!  

But what the DRST indicates is, as Klaus pointed out,  that a previously
unavailable destination is now available (but restricted). 
With kind regards,
Richard A. Adams,
[email-masked], tel : +44 1666 83 2503 fax: + 44 1666 83 2712
Lucent Tech.,
Swindon Road,
Malmesbury,
Wiltshire SN16 9NA.

> ----------
> From: 	Maria_Cruz_Bartolome_Rodrigo
> +34913393208[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, June 18, 2001 3:59 PM
> To: 	sigtran
> Cc: 	[email-masked]
> Subject: 	Re: M3UA: DRST message
> 
> 
> Hi Greg and Klaus,
> 
> Right now I got the point, thanks for the fast answers.
> 
> However, that sentence may not be clear enough, what about:
> 
> ... If the affected destinations are ALREADY considered RESTRICTED
> by the ASP...
> 
> Cheers
> /MCruz
> 
> 
> 
> 
> 
> "Gradischnig, Klaus" wrote:
> > 
> > Maria,
> > 
> > receiving a TFR for a prohibited destination implicitly cancels the
> > prohibited status. If a destination were still prohibited, no TFR
> message
> > would be sent for it. The analog applies to DRST messages.
> > 
> > Klaus
> > 
> > > -----Original Message-----
> > > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > > [mailto:[email-masked]]
> > > Sent: June 18, 2001 10:23 AM
> > > To: sigtran
> > > Subject: M3UA: DRST message
> > >
> > >
> > >
> > > Hi all,
> > >
> > > There is something unclear in the 3.4.6 chapter (Destination
> > > Restricted - DRST), see in caps:
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > "The DRST message is optionally sent from the SG to all concerned
> > > ASPs
> > > to indicate that the SG has determined that one or more SS7
> > > destinations are now restricted, or in response to a DAUD message
> > > if
> > > appropriate. The M3UA at the ASP is expected to send traffic to
> > > the
> > > affected destination via an alternate SG of equal priority, but
> > > only if
> > > such an alternate route exists and is available. IF THE AFFECTED
> > > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > > TRAFFIC TO
> > > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > > BE
> > > RESUMED.
> > > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > > ASP TO
> > > PROCESS. It is for use in the "STP" case described in Section
> > > 1.4.2."
> > > --------------------------------------------------------------
> > > ----------
> > >
> > > If the affected destinations (those restricted, I presumed) are
> > > considered unavailable by the ASP, then traffic can't be resumed
> > > neither
> > > through the SG initiating the DRST nor the alternate SG. Don't you
> > > think
> > > in this particular case, the DRST msg should be ignored by the
> > > ASP?
> > >
> > > Apart from that, this message can NOT be optional for the ASP to
> > > process,
> > > at least the ASP should be able to read and discard it, don't you
> > > agree?
> > > Otherwise, interoperability will be impossible.
> > >
> > > Thanks
> > > /M.Cruz
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as:
> > > [email-masked]
> > > To unsubscribe send a blank email to
> > > [email-masked]
> > >
> > 
> > ---
> > You are currently subscribed to sigtran as:
> [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M3UA: DRST message
Date: Mon, 18 Jun 2001 11:33:49 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Maria,

No, for this case the ASP considers the destination as "unavailable" and
then receives a DRST from the SG.  If the affected destination were already
considered restricted then the ASP would not need to resume traffic as it
should already be using the restricted route.  So I think that the current
text is correct ... 

    "If The Affected Destination is currently considered unavailable by the
ASP, traffic to the affected destination through the SG(P) initiating the
DRST should be resumed.  This message is optional for the SG to send and
optional for the ASP to act on.  It is for use in the "STP" case described
in Section 1.4.2."

But this does lead me to a question. The "optional for the ASP to act on"
might be too weak, at least for the case of an unavailable destination.  I
think a robust ASP implementation should consider the DRST for a destination
currently considered unavailable as equivalent to an DAVA.  Would people be
willing to add a statement that "The ASP SHOULD consider a previously
unavailable destination as available".

Greg Sidebottom

 -----Original Message-----
From: 	Maria_Cruz_Bartolome_Rodrigo +34913393208
[mailto:[email-masked]] Sent:	Monday, June
18, 2001 11:00 AM
To:	sigtran
Cc:	[email-masked]
Subject:	Re: M3UA: DRST message

Hi Greg and Klaus,

Right now I got the point, thanks for the fast answers.

However, that sentence may not be clear enough, what about:

... If the affected destinations are ALREADY considered RESTRICTED by the
ASP...

Cheers
/MCruz

"Gradischnig, Klaus" wrote:
> 
> Maria,
> 
> receiving a TFR for a prohibited destination implicitly cancels the
> prohibited status. If a destination were still prohibited, no TFR message
> would be sent for it. The analog applies to DRST messages.
> 
> Klaus
> 
> > -----Original Message-----
> > From: Maria_Cruz_Bartolome_Rodrigo +34913393208
> > [mailto:[email-masked]]
> > Sent: June 18, 2001 10:23 AM
> > To: sigtran
> > Subject: M3UA: DRST message
> >
> >
> >
> > Hi all,
> >
> > There is something unclear in the 3.4.6 chapter (Destination
> > Restricted - DRST), see in caps:
> >
> > --------------------------------------------------------------
> > ----------
> > "The DRST message is optionally sent from the SG to all concerned
> > ASPs
> > to indicate that the SG has determined that one or more SS7
> > destinations are now restricted, or in response to a DAUD message
> > if
> > appropriate. The M3UA at the ASP is expected to send traffic to
> > the
> > affected destination via an alternate SG of equal priority, but
> > only if
> > such an alternate route exists and is available. IF THE AFFECTED
> > DESTINATION IS CURRENTLY CONSIDERED UNAVAILABLE BY THE ASP,
> > TRAFFIC TO
> > THE AFFECTED DESTINATION THROUGH THE SG INITIATING THE DRST SHOULD
> > BE
> > RESUMED.
> > THIS MESSAGE IS OPTIONAL FOR THE SG TO SEND AND OPTIONAL FOR THE
> > ASP TO
> > PROCESS. It is for use in the "STP" case described in Section
> > 1.4.2."
> > --------------------------------------------------------------
> > ----------
> >
> > If the affected destinations (those restricted, I presumed) are
> > considered unavailable by the ASP, then traffic can't be resumed
> > neither
> > through the SG initiating the DRST nor the alternate SG. Don't you
> > think
> > in this particular case, the DRST msg should be ignored by the
> > ASP?
> >
> > Apart from that, this message can NOT be optional for the ASP to
> > process,
> > at least the ASP should be able to read and discard it, don't you
> > agree?
> > Otherwise, interoperability will be impossible.
> >
> > Thanks
> > /M.Cruz
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
> > [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> >
> 
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:52:22 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Registration messages and procedures
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      KAA03085
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Unfortunately, this is not a function which is provided by element
management and which might require the exchange of PDUs between MTP3 peers
per Clause 12 of Q.704.  Some mechanism must be provided in M2UA to
accomodate this signalling function.  If you do no wish to reuse the
Registration function of M3UA for this purpose, new messages and new
procedures will be required.

--Brian

Ken Morneault wrote:                      (Mon, 18 Jun 2001 08:59:18)
> 
> 
> Brian,
> 
> I don't see a need for dynamic provisioning of this type
> for M2UA.  An network or element management system
> would suffice.
> 
> Regards,
> 
> Ken
> 
> At 04:27 PM 6/16/01 -0500, you wrote:
> >sigtran,
> >
> >I would like to propose the attached text to be included
> >in the M2UA specification.  The text is consistent (stolen)
> >from the M3UA specification and provides the ASP with the
> >ability to control the dynamic registration of Interface
> >Identifiers in support of the Automatic Allocation of
> >Signalling Data Terminals and Signalling Data Links as
> >provided for in the Q.704 and other specifications.
> >
> >--Brian
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >x.x.x Registration Request (REG REQ)
> >
> >The REG REQ message is sent by an ASP to indicate to a remote M2UA
> >peer that it wishes to register one or more given Link Keys with the
> >remote peer.  Typically, an ASP would send this message to an SGP,
> >and expectes to receive a REG RSP in return with an associated
> >Interface Identifier value.
> >
> >The REG REQ message contains the following parameters:
> >
> >      Link Key                Mandatory
> >
> >The format for the REG REQ message 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 = ??           |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                           Link Key 1                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                              ...                              /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = ??           |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                           Link Key n                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Link Key: fixed length
> >
> >    The Link Key parameter is mandatory.  The sender of this message
> >    expects the receiver of this message will create a Link Key entry
> >    and assign a unique Interface Identifier value to it, if the Link
> >    Key entry does not yet exist.
> >
> >    The Link Key parameter may be present multiple times in the same
> >    message.  This is used to allow the registration of multiple Link
> >    Keys in a single message.
> >
> >The format of the Link 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-LK-Identifier                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                 Signalling Data Terminal Identifier           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   Signalling Data Link Identifier             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Local-LK-Identifier: 32-bit integer
> >
> >    The mandatory Local-LK-Identifier field is used to uniquely
> >    identify the registration request.  The Identifier value is
> >    assigned by the ASP, and is used to correlate the response in a
> >    REG RSP message with the original registration request.  The
> >    Identifier value must remain unique until the REG RSP is
> >    received.
> >
> >    The format of the Local-LK-Identifier field 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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Local-LK-Identifier value                  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Signalling Data Terminal Identifier:
> >
> >    The Signalling Data Terminal Identifier parameter is mandatory,
> >    and identifies the Signalling Data Terminal associated with the
> >    SS7 link for which the ASP is registering.  The 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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Reserved             |        SDT Identifier         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    The SDT Identifier is a 32-bit unsigned value which may only be
> >    significant to 12 or 14 bits depending on the SS7 variant which
> >    is supported by the MTP Level 3 at the ASP.  Insignificant SDTI
> >    bits are coded 0.
> >
> >Signalling Data Link Identifier:
> >
> >    The Signalling Data Link Identifier parameter is mandatory, and
> >    identifies the Siganlling Data Link Identifier associated with
> >    the SS7 link for which the ASP is registering.  The 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 = ??            |         Length = 8            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Reserved             |        SDL Identifier         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    The SDL Identifier is a 32-bit unsigned value which may only be
> >    significant to 12 or 14 bits depending on the SS7 variant which
> >    is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
> >    bits are coded 0.
> >
> >x.x.x Registration Response (REG RSP)
> >
> >The REG RSP message is used as a response to the REG REQ message
> >from a remote M2UA peer.  It contains indications of success/failure
> >for registration requests and returns a unique Interface Identifier
> >value for successful registration requests, to be used in subsequent
> >M2UA Traffic Management protocol.
> >
> >The REG RSP message contains the following parameters:
> >
> >      Registration Results   Mandatory
> >
> >The format for the REG RSP message 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 = ??           |         Length = var.         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Registration Result 1                      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    /                              ...                              /
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                    Registration Result n                      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Registration Results:
> >
> >    The Registration Results parameter contains one or more results,
> >    each containing the registration status for a single Link Key in
> >    the REG REQ message.  The number of results in a single REG RSP
> >    message MAY match the number of Link Key parameters found in the
> >    corresponding REG REQ message.  The format of each result 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-LK-Identifier value                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      Registration Status                      |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      Interface Identifier                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Local-LK-Identifier: 32-bit integer
> >
> >    The Local-LK-Identifier contains the same value as found in the
> >    matching Link Key parameter found in the REG Req message.
> >
> >Registration Status: 32-bit integer
> >
> >    The Registration Result Status field indicates the success or the
> >    reason for failure of a registration request.
> >
> >    Its values may be:
> >
> >         0           Successfully Registered
> >         1           Error - Unknown
> >         2           Error - Invalid SDLI
> >         3           Error - Invalid SDTI
> >         4           Error - Invalid Link Key
> >         5           Error - Permission Denied
> >         6           Error - Overlapping (Non-unique) Link Key
> >         7           Error - Link Key not Provisioned
> >         8           Error - Insufficient Resources
> >
> >Interface Identifier: 32-bit integer
> >
> >    The Interface Identifier field contains the Interface Identifier
> >    for the associated Link Key if the registration is successful.
> >    It is set to "0" if the registration was not successful.
> >
> >x.x.x De-Registration Request (DEREG REQ)
> >
> >The DEREG REQ message is sent by an ASP to indicate to a remote M2UA
> >peer that it wishes to de-register a given Link Key.  Typically, an
> >ASP would send this message to an SGP, and expects to receive a
> >DEREG RSP in return with the associated Interface Identifier value.
> >
> >The DEREG REQ message contains the following parameters:
> >
> >      Interface Identifier  Mandatory
> >
> >The format for the DEREG REQ message 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 = ??           |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    /                                                               /
> >    \                    Interface Identifier                       \
> >    /                                                               /
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Interface Identifier: n X 32-bit integers
> >
> >    The Interface Identifier parameter contains (a list of) integer
> >    indexing the Application Server traffic that the sending ASP is
> >    currently registered to receive from the SG but now wishes to
> >    deregister.
> >
> >x.x.x De-Registration Response (DEREG RSP)
> >
> >The DEREG RSP message is used as a response to the DEREG REQ message
> >from a remote M2UA peer.
> >
> >The DEREG RSP message contains the following parameters:
> >
> >      De-registration Results    Mandatory
> >
> >The format for the DEREG RSP message 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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      Interface Identifier                     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     De-Registration Status                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >Interface Identifier: 32-bit integer
> >
> >    The Interface Identifier field contains the Interface Identifier
> >    value of the matching Link Key to deregister, as found in the
> >    DEREG Req.
> >
> >De-Registration Status: 32-bit integer
> >
> >    The De-Registration Result Status field indicates the success or
> >    the reason for failure of the de-registration.
> >
> >    Its values may be:
> >         0           Successfully De-registered
> >         1           Error - Unknown
> >         2           Error - Invalid Interface Identifier
> >         3           Error - Permission Denied
> >         4           Error - Not Registered
> >
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >x.x.x Link Key Management Procedures
> >
> >x.x.x.1 Registration
> >
> >An ASP MAY dynamically register with an SG as an ASP within an
> >Application Server using the REG REQ message.  A Link Key parameter
> >in the REG REQ specifies the parameters associated with the Link
> >Key.
> >
> >The SG examines the contents of the received Link Key parameter and
> >compares it with the currently provisioned Link Keys.  If the
> >received Link Key matches an existing SG Link Key entry, and the ASP
> >is not currently included in the list of ASPs for the related
> >Application Server, the ASP MAY authorize the ASP to be added to the
> >AS.  Or, if the Link Key does not currently exist and the received
> >Link Key data is valid and unique, an SG supporting dynamic
> >configuration MAY authorize the creation of a new Link Key and
> >related Application Server and add the ASP to the new AS.  In either
> >case, the SG returns a Registration Response message to the ASP,
> >containing the same Local-LK-Identifier as provided in the initial
> >request, and a Registration Result "Successfully Registered".  A
> >unique method of Interface Identifier valud assignment at the SG/SGP
> >is implementation dependent but must be guaranteed to be unique
> >across all SGPs in an SG.
> >
> >If the SG determins that the received Link Key data is invalid, or
> >contains invalid parameter values, the SG returns a Registration
> >Response message to the ASP, containing a Registration Result "Error
> >- Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI"
> >as appropriate.
> >
> >If the SG determins that the Link Key parameter overlaps with an
> >existing Link Key entry, the SG returns a Registration Response
> >message to the ASP, with a Registration Status of "Error -
> >Overlapping (Non-Unique) Link Key".  An incoming signalling message
> >received at an SG cannot match against more than one Link Key.
> >
> >If the SG does not authorize the registration request, the SG
> >returns a REG RSP message to the ASP containing the Registration
> >Result "Error - Permission Denied".
> >
> >If an SG determines that a received Link Key does not currently
> >exist and the SG does not support dynamic configuration, the SG
> >returns a Registration Response message to the ASP, containing a
> >Registration Result "Error - Link Key not Provisioned".
> >
> >If an SG determines that a received Link Key does not currently
> >exist and the SG supports dynamic reconfiguration but does not have
> >the capacity to add new Link Key and Application Server entries, the
> >SG returns a Registration Response message to the ASP, containing a
> >Registration Result "Error - Insufficient Resources".
> >
> >An ASP MAY register multiple Link Keys at once by including a number
> >of Link Key parameters in a single REG REQ message.  The SG MAY
> >response to each registration request in a single REG RSP message,
> >indicating the success or failure result for each Link Key in a
> >separate Registration Result parameter.  Alternatively the SG MAY
> >response with multiple REG RSP messages, each with one or more
> >Registration Result parameters.  The ASP uses the Local-LK-Identifier
> >parameter to correlate the requests with the responses.
> >
> >Upon successful registration of an ASP in an AS, the SG can now send
> >related messaging, if this did not previsouly start upon the ASP
> >transitioning to "Inactive".
> >
> >x.x.x.2 Deregistration
> >
> >An ASP MAY dynamically deregister with an SG as an ASP within an
> >Application Server using the DEREG REQ message.  A Interface
> >Identifier parameter in the DEREG REQ specifies which Link Key to
> >de-register.
> >
> >The SG examines the contents of the received Interface Identifier
> >parameter and validates that the ASP is currently registered in the
> >Application Server(s) related to the included Interface
> >Identifier(s).  If validated, the ASP is de-registered as an ASP in
> >the related Application Server.
> >
> >The deregistration procedure does not necessarily imply the deletion
> >of Link Key and Application Server configuration data at the SG.
> >Other ASPs may continue to be associated with the Application
> >Server, in which case the Link Key data CANNOT be deleted.  If a
> >Deregistration results in no more ASPs in an Application Server, an
> >SG MAY delte the Link Key data.
> >
> >The SG acknowledges the de-registration requres by returning a DEREG
> >RSP to the requesting ASP.  The result of the de-registration is
> >found in the Deregistration Result paraemeter, indicating success or
> >faliure with cause.
> >
> >An ASP MAY deregister multiple Interface Identifiers at once by
> >including a number of Interface Identifiers in a single DEREG REQ
> >message.  The SG MUST response to each deregistration request in a
> >single DEREG RSP message, indicating the success or failure result
> >for each Interface Identifier in a separate Deregistration Result
> >parameter.
> >
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> >-- 
> >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] 
> 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 18 Jun 2001 10:55:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: Retrieval Request
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.221]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Klaus,

Correct.  There are interface primitive and semantic differences between ITU
Q.703, ITU Q.2240, ANSI T1.111.3, and I presume some other variants.  Also,
there are semantic and primitive differences between Blue Book and Grey
Book.  How do you suggest that all these differences be accomodated without
M2UA needing to know the precise variant and version that it is connected
to?

--Brian

Gradischnig, Klaus wrote:                     (Mon, 18 Jun 2001 09:00:17)
> Just a small clarification:
> 
> MTP does provide the ability to only retrieve the transmission buffer:
> 
> Q.704, 5.6.1 states:
> "...Instead, it directly starts sending 
> the signalling traffic not yet transmitted
>                        ^^^^^^^^^^^^^^^^^^^                      
> on the unavailable link on the alternative signalling link(s)"
> 
> Q.2240, 6.1.2, is even more explicit:
> 
> "For cases in which an FSNC value is not obtained from MTP-3, the RN
> parameter can convey a value of "unknown", and SSCOP returns only those
> message units that have not yet been transmitted."
> 
> Klaus
> 
> > -----Original Message-----
> > From: Ken Morneault [mailto:[email-masked]]
> > Sent: June 18, 2001 8:01 AM
> > To: sigtran
> > Subject: Re: M2UA 08: Retrieval Request
> > 
> > 
> > 
> > 
> > Brian,
> > 
> > This Status Req and Retrieval Req text is cleaned up per
> > your recommendations.
> > 
> > Ken
> > 
> > At 09:21 PM 6/14/01 -0500, you wrote:
> > >Section 3.3.1.8
> > >
> > >The changes which were made to retrieval request are not
> > >consistent with the common descriptions of M2UA from Q.703
> > >and Q.2140/Q.2110.  These specs do not provide a mechanism
> > >for retrieving as described in ACTION_RTRV_MSGS and
> > >ACTION_RTRV_TRANS.  Both Q.703 and Q.2140/2110 described
> > >signalling links only support the retrieval of BOTH the
> > >messages in the retransmit and transmit buffers.
> > >
> > >If CLEAR_RTB is added to the states (as per previous mail)
> > >consistent with the flush_buffers primitive, these three
> > >can be reduced to a set which is consistent with the cited
> > >and referenced recommendations.
> > >
> > >Remove ACTION_DROP_MSGS and ACTION_RTRV_TRANS, describe
> > >ACTION_RTRV_MSGS as retrieving both RTB and TB contents,
> > >and add STATUS_CLEAR_RTB to the status messages.  This
> > >will make M2UA consistent with Q.703/Q.2140/Q.2110 as
> > >well as T1.111.3.
> > >
> > >-- 
> > >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] 
> > 
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: 
> > [email-masked]
> > To unsubscribe send a blank email to 
> > [email-masked]
> > 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 19 Jun 2001 01:07:28 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Status Confirm
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

What is the purpose of the Result field in the Status Confirm message?  I
can see what to do if the Result field is set to STATUS_SUCCESS.  However,
what possible response is there to STATUS_FAILURE?  It appears that the
Result field is not only unnecessary it is also confusing.

-- 
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]
Date: Tue, 19 Jun 2001 01:11:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: State Indication
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      BAA14223
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

It is necesary for the SG to be able to signal LPO to the AS.  This is
because the SG may temporarily lose contact with an MTP2 for only one IID of
an association.
To accomidate this I propose that you add:

        EVENT_LPO_ENTER     0x3     Link entered processor outage
        EVENT_LPO_EXIT      0x4     Link exited processor outage

To the events in Section 3.3.1.6 State Indication.

--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]
Date: Tue, 19 Jun 2001 01:17:19 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: Auditing of SS7 link state
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-221.dallas.net [209.44.42.221]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

In section 5.3.8 Auditing of SS7 link state, it would be good idea to have
the SG return the State Cfm (STATUS_AUDIT) after it has provided the
indications and confirmations which detail the state.  That way the ASP
knows when to expect no further state indications or confirmations.
Otherwise it may have to wait for a fairly long period on the possibility
of, say, a late arriving congestion or state indication.  The diagrams would
then look like:

Below is an example in which the SS7 link is out-of-service.

 MTP2           M2UA                              M2UA           MGMT
  SG             SG                               ASP             ASP

                 |<----State Req (STATUS_AUDIT)----|<----Audit-------

                                                                 MTP3
                                                                  ASP

                 |-----------Release Ind---------->|-Out of Serv Ind->

                                                                 MGMT
                                                                  ASP
                 |-----State Cfm (STATUS_AUDIT)--->|

Below is an example in which the SS7 link is in-service.

 MTP2           M2UA                              M2UA           MGMT
  SG             SG                               ASP             ASP

                 |<----State Req (STATUS_AUDIT)----|<----Audit-------

                                                                 MTP3
                                                                  ASP

                 |-----------Establish Cfm-------->|---In Serv Ind-->

                                                                 MGMT
                                                                  ASP
                 |-----State Cfm (STATUS_AUDIT)--->|

Below is an example in which the SS7 link is in-service, but congested.

 MTP2           M2UA                              M2UA           MGMT
  SG             SG                               ASP             ASP

                 |<----State Req (STATUS_AUDIT)----|<----Audit-------

                                                                 MTP3
                                                                  ASP

                 |-----------Establish Cfm-------->|---In Serv Ind-->

                 |----------Congestion Ind-------->|---Cong Ind----->

                                                                 MGMT
                                                                  ASP
                 |-----State Cfm (STATUS_AUDIT)--->|

Below is an example in which the SS7 link is in-service, but in Remote
Processor Outage.

 MTP2           M2UA                              M2UA           MGMT
  SG             SG                               ASP             ASP

                 |<----State Req (STATUS_AUDIT)----|<----Audit-------

                                                                 MTP3
                                                                  ASP

                 |-----------Establish Ind-------->|---In Serv Ind-->

                 |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter--->

                                                                 MGMT
                                                                  ASP
                 |-----State Cfm (STATUS_AUDIT)--->| -- 
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: shakila <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: MTP primitives
Date: Tue, 19 Jun 2001 12:09:05 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

What are the reference standards for message transfer primitives?
will these ITU standards Q.701-705 fit the purpose? are is there any other
standards for these primitives?

regards
shakila

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 19 Jun 2001 09:24:41 +0100
From: Joyce Archibald <[email-masked]>
Organization: Agilent Technologies UK Ltd
X-Mailer: Mozilla 4.76 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: SUA-06 & M2UA-08 Common Parameters
X-SMTP-HELO: msgbas1.cos.agilent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: msgbas1x.cos.agilent.com [192.6.9.33]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John & Ken,

The new drafts of SUA and M2UA both contain a list of common parameters
"used by all User Adaptation layers". Unfortunately the lists are different:

  Tag   M2UA            M3UA          SUA            IUA
  -----------------------------------------------------------------
  0x1   IntfaceId(Int)  NetworkApp    NetworkApp     IntfaceId(Int)
  0x2   IntfaceId(Rng)  Data          Unused         Unused
  0x3   IntfaceId(Txt)  Data (TTC)    Data           IntfaceId(Txt)
  0x4   Info String     Info String   Info String    Info String
  0x5   Unused          AffectDests   AffectPC       DLCI
  0x6   Unused          RoutgContxt   RoutgContxt    Unused
  0x7   Diag Info       Diag Info     Diag Info      Diag Info
  0x8   HeartbeatData   HeartbeatData HeartbeatData  IntfaceId(Rng)
  0x9   Unused          User/Cause    Unused         HeartbeatData 
  0xa   Reason          Reason        Reason         Reason
  0xb   Traffic Mode    Traffic Mode  Traffic Mode   Traffic Mode
  0xc   Error Code      Error Code    Error Code     Error Code
  0xd   StsType/Info    StsType/ID    StsType/ID     StsType/ID
  0xe   ASP Id          CongestInds   CongestLevel   Data

In section 3.3.2.5 of M2UA-08, tag 0x8 is used for Interface Id (Integer
Range) but I assume this is a typo.

There are plenty of tag values to chose from so it should be possible to
resolve the differences, bearing in mind that M3UA and IUA also use tags in
the range 0xf - 0x1a.

Regards,
Joyce

-- 
================================================================== Joyce
Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521 Agilent Technologies
UK Ltd  | Telnet:   313 2521 South Queensferry,           | Mailstop:
SQFRD3A EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA-06 & M2UA-08 Common Parameters
Date: Tue, 19 Jun 2001 13:05:25 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x3.nokia.com [131.228.20.26]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Joyce,

> The new drafts of SUA and M2UA both contain a list of common 
> parameters "used by all User Adaptation layers". Unfortunately the 
> lists are different:
> 
>   Tag   M2UA            M3UA          SUA            IUA
>   -----------------------------------------------------------------
>   0x1   IntfaceId(Int)  NetworkApp    NetworkApp     IntfaceId(Int)
>   0x2   IntfaceId(Rng)  Data          Unused         Unused
>   0x3   IntfaceId(Txt)  Data (TTC)    Data           IntfaceId(Txt)
>   0x4   Info String     Info String   Info String    Info String
>   0x5   Unused          AffectDests   AffectPC       DLCI
>   0x6   Unused          RoutgContxt   RoutgContxt    Unused
>   0x7   Diag Info       Diag Info     Diag Info      Diag Info
>   0x8   HeartbeatData   HeartbeatData HeartbeatData  IntfaceId(Rng)
>   0x9   Unused          User/Cause    Unused         HeartbeatData 
>   0xa   Reason          Reason        Reason         Reason
>   0xb   Traffic Mode    Traffic Mode  Traffic Mode   Traffic Mode
>   0xc   Error Code      Error Code    Error Code     Error Code
>   0xd   StsType/Info    StsType/ID    StsType/ID     StsType/ID
>   0xe   ASP Id          CongestInds   CongestLevel   Data

Thanks for writing this up.  This is a big help.  I agree with you that we
need to agree on this.  Since IUA is already an RFC, perhaps we need to work
around it.

Greg, Ken - what do you suggest?

br,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
X-Lotus-FromDomain: HTLUK
To: "sigtran" <[email-masked]>
Date: Tue, 19 Jun 2001 17:33:31 +0100
Subject: Mailing List Archives
X-SMTP-HELO: hagrid.orange.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtpout10.orange.co.uk [193.35.135.133]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

Are there any ftp or web-based archives of this mailing list?

The WG web page lists ftp://ftp.ietf.org/ietf-mail-archive/sigtran/ as the
archive, but most of the directories that are here are zero bytes in size
except February, March and April 2001.

The Nortel site at http://www17.nortelnetworks.com/archives/sigtran.html has
only got a few of the emails.

Amish

****************************************************************************
*** Important. This E-mail is intended for the above named person and may be
confidential and/or legally privileged. If this has come to you in error you
must take no action based on it, nor must you copy or show it to anyone;
please inform the sender immediately.
****************************************************************************
***

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 19 Jun 2001 14:23:37 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA 08: ASP Down (Ack)
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

What is the point of a "Reason" parameter in the ASPDN and ASPDN Ack
messages where there is only one valid value for the parameter?

-- 
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]
Date: Tue, 19 Jun 2001 14:34:47 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: MTP primitives
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

shakila,

For MTP Level 3 primitives at the MTP3 to MTP3-User boundary there are as
many descriptions as there are national variants which alter the
descriptions of Q.701 (and Q.711). There is T1.111.1 and T1.111.4 and T1.112
which describe them differently, and then there are ETSI, TTC, an other
national standards documents with their own variations of congestion states
or levels.  Nevertheless, Q.701 Clause 8 gives a good starting point.

shakila wrote:                                    (Tue, 19 Jun 2001
12:09:05)

> Brian,
> 
> What are the reference standards for message transfer primitives?
> will these ITU standards Q.701-705 fit the purpose? are is there any other
> standards for these primitives?
> 
> regards
> shakila

-- 
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]
Date: Tue, 19 Jun 2001 14:52:42 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SUA 06: AMF at ASP
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Section 1.5.2 says:

   There is, however, no SUA messaging to manage the status of an SGP.
   Whenever an SCTP association to an SGP exists, it is assumed to be
   available.  Also, every SGP of one SG communicating with one ASP
   regarding one AS provides identical SS7 connectivity to this ASP.

This same issue came up with M3UA.  SGP cannot be treated as providing
identical connectivity and the ASP must perform some algorithm in
consideration of the attributes of SGP, it only to some such thing as
load-share messages accross the SGP in an SG.  Because SGP are exactly that:
independent SG processes, they can suffer partial failures and it is
necessary for the ASP to take into consideration the partially functioning
state of an SGP when sending messages towards it.  A case in point would be
when an SGP can route messages to all SLS under normal operation, but when
partitioned from its SGP peers, it is only able to process several SLS and
the other SGP cannot process these SLS at all.  Failing the whole SG or
allowing arbitrary messages to be discarded or returned is unworkable.

On approach without adding SGP management would be to insist that an ASP
only routes messages to an SGP that it would receive from that SGP within
the Routing Context/Routing Key under which it is currently active and
receiving traffic.  The routing context itself, then, would be used by the
ASP to select the SGP.

-- 
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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 19 Jun 2001 20:00:16 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: Status Confirm
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I believe this was added due to some previous comments you made under the
title "Issue #9 - State".

----------- cut from that email ----------------------------------

 >
 > 3.3.1.4  State (Request, Confirm)
 >
 > The State Request message can be sent from a MGC to cause an action  > on
a particular SS7 link supported by the Signaling Gateway.  The  > gateway
sends a State Confirm to the MGC if the action has been success-  > fully
completed.  The State Confirm reflects that state value received  > in the
State Request message.
 >
 > Morneault, et al                                               [Page 13]
>
 > Internet Draft         SS7 MTP2 User Adaptation Layer           Nov 2000
>
 >
 >
 >     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  >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  >    |
State                             |  >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  >
 > The valid values for State are shown in the following table.
 >
 >          Define           Value        Description  >    STATUS_LPO_SET
0x0      Request local processor outage  >    STATUS_LPO_CLEAR        0x1
Request local processor outage  >
recovered  >    STATUS_EMER_SET         0x2      Request emergency alignment
>                                     procedure  >    STATUS_EMER_CLEAR
0x3      Request normal alignment (cancel  >
emergency) procedure  >    STATUS_FLUSH_BUFFERS    0x4      Flush transmit
and retransmit  >                                     buffers  >
STATUS_CONTINUE         0x5      Continue

What does the the SG return if it is not successfully completed due to some
internal failure?

In support of multiple ASPs it is necessary for the ASP which is newly
taking over the link to be able to request the current state of the link (to
audit its internal state variable) without setting anything.  How does the
SG do that?

------------- end of cut ----------------------------------

At 01:07 AM 6/19/01 -0500, you wrote:
>Ken,
>
>What is the purpose of the Result field in the Status Confirm
>message?  I can see what to do if the Result field is set to
>STATUS_SUCCESS.  However, what possible response is there to
>STATUS_FAILURE?  It appears that the Result field is not only
>unnecessary it is also confusing.
>
>-- 
>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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 19 Jun 2001 20:00:26 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: State Indication
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Sure, these indications were in the draft previously.

Ken

At 01:11 AM 6/19/01 -0500, you wrote:
>Ken,
>
>It is necesary for the SG to be able to signal LPO to
>the AS.  This is because the SG may temporarily lose
>contact with an MTP2 for only one IID of an association.
>To accomidate this I propose that you add:
>
>         EVENT_LPO_ENTER     0x3     Link entered processor outage
>         EVENT_LPO_EXIT      0x4     Link exited processor outage
>
>To the events in Section 3.3.1.6 State Indication.
>
>--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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 19 Jun 2001 20:00:31 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA 08: ASP Down (Ack)
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Note:  This request should be considered for all the UAs (M3UA, SUA, and
M2UA).

At 02:23 PM 6/19/01 -0500, you wrote:
>What is the point of a "Reason" parameter in the
>ASPDN and ASPDN Ack messages where there is only
>one valid value for the parameter?
>
>-- 
>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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 19 Jun 2001 19:34:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA 08: Status Confirm
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

Gee, to answer my own question, I was intending on having it return Status
Indication EVENT_LPO_ENTER in event of failure.
It is still useful to have a confirmation so that M2UA knows when its peer
has "gone away" without the SCTP association going down.  (It will also be
necessary to confirm DATA transfers for the same reason (and thus the
Correlation Id proposal).
Status Confirm without the Result parameter will suffice for this.

Ken Morneault wrote:                                   (Tue, 19 Jun 2001
20:00:16)
> 
> 
> Brian,
> 
> I believe this was added due to some previous comments you
> made under the title "Issue #9 - State".
> 
> 
> ----------- cut from that email ----------------------------------
> 
>  >
>  > 3.3.1.4  State (Request, Confirm)
>  >
>  > The State Request message can be sent from a MGC to cause an action
>  > on a particular SS7 link supported by the Signaling Gateway.  The
>  > gateway sends a State Confirm to the MGC if the action has been
success-
>  > fully completed.  The State Confirm reflects that state value received
>  > in the State Request message.
>  >
>  > Morneault, et al                                               [Page
13]
>  >
>  > Internet Draft         SS7 MTP2 User Adaptation Layer           Nov
2000
>  >
>  >
>  >
>  >     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
>  >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >    |                             State                             |
>  >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >
>  > The valid values for State are shown in the following table.
>  >
>  >          Define           Value        Description
>  >    STATUS_LPO_SET          0x0      Request local processor outage
>  >    STATUS_LPO_CLEAR        0x1      Request local processor outage
>  >                                     recovered
>  >    STATUS_EMER_SET         0x2      Request emergency alignment
>  >                                     procedure
>  >    STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
>  >                                     emergency) procedure
>  >    STATUS_FLUSH_BUFFERS    0x4      Flush transmit and retransmit
>  >                                     buffers
>  >    STATUS_CONTINUE         0x5      Continue
> 
> What does the the SG return if it is not successfully completed due to
> some internal failure?
> 
> In support of multiple ASPs it is necessary for the ASP which is newly
> taking over the link to be able to request the current state of the link
> (to audit its internal state variable) without setting anything.  How
> does the SG do that?
> 
> ------------- end of cut ----------------------------------
> 
> 
> At 01:07 AM 6/19/01 -0500, you wrote:
> >Ken,
> >
> >What is the purpose of the Result field in the Status Confirm
> >message?  I can see what to do if the Result field is set to
> >STATUS_SUCCESS.  However, what possible response is there to
> >STATUS_FAILURE?  It appears that the Result field is not only
> >unnecessary it is also confusing.
> >
> >-- 
> >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] 
> 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Max size of m3ua data
Date: Wed, 20 Jun 2001 09:07:28 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
   The m3ua drafts says that it can transport any size of signalling data. I
would like to know what would be max size the m3ua can receive from the ULP.
we feel even if it is ISUP it cannot be more than 1024 bytes.
  please let me know what can be max signalling data.
Thanks
Satish K

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 19 Jun 2001 23:51:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Max size of m3ua data
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

I believe that maximum size that M3UA can transfer is controlled by the
underlying MTP3 implementation.
If the M3UA is supporting IPSP to IPSP signalling, over SCTP, the maximum
size is limited only by the range of stream sequence numbers and path MTU in
SCTP.  If, however, M3UA is supporting signalling into a real SS7 network,
the M3UA user is limited by the maximum size of an MSU that the underlying
MTP can transfer.  This value is somewhere around 272 bytes for MSUs for low
speed links (max 254 for ISUP) and larger for Annex A links and MTP3b links.
The MTP3-user at M3UA must be congnisant of the maximum size supported by
the network underlying M3UA and need not be stippulated by M3UA directly.
ITU provides a suggested procedure for discovering the maximum size MSU that
can be transferred on a given route.

Satish K wrote:                                   (Wed, 20 Jun 2001
09:07:28)
> Hi,
>    The m3ua drafts says that it can transport any size of signalling data.
I
> would like to know what would be max size the m3ua can receive from the
ULP.
> we feel even if it is ISUP it cannot be more than 1024 bytes.
>   please let me know what can be max signalling data.
> Thanks
> Satish K

-- 
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: Satish K <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: sua primitives
Date: Wed, 20 Jun 2001 10:58:29 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

hello,
We have a doubt on SUA implementation.
Please refer to section 1.6 of SUA draft.

The upper layer boundary primitives (e.g N-Connect,N-Data etc) do they
correspond to which messages of SUA (e.g connection request ) ?

How to map these primitives to the SUA connection less and connection
oriented messages ?

When does these primitives are invoked.
Is this after the SUA SGP<->ASP connection is setup ? (ASPUP & ASP UP ACK)

If so is when should this SGP<->ASP connection setup should take place.
Are there primitives corresponding to this ?

Please explain us these things
regards
manjunath

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: shakila <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: MTP primitives format
Date: Wed, 20 Jun 2001 11:54:04 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

This is the format of MTP-TRANSFER primitive. The parameter tag value 28 is
reserved by IETF. Is this value = 23, which corresponds to Originating Point
code list? plz clarify.

    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 = 28           |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Originating Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Signalling Link Selection   |       Service Indicator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also
could anyone give me the format of other MTP primitives?? (STATUS, RESUME,
PAUSE)?

regards
shakila

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 20 Jun 2001 01:41:11 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: MTP primitives format
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

shakila,

This is what I proposed for the MTP-TRANSFER primitive (which is really a
DATA message in section 3.3.1).  The reason you don't see tag value 28 is
because this proposal has not been included in an M3UA draft.

Do you support this approach?

shakila wrote:                                     (Wed, 20 Jun 2001
11:54:04)
> Brian,
> 
> This is the format of MTP-TRANSFER primitive. The parameter tag value 28
is
> reserved by IETF. Is this value = 23, which corresponds to Originating
Point
> code list? plz clarify.
> 
>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |       Service Indicator       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Also could anyone give me the format of other MTP primitives?? (STATUS,
> RESUME, PAUSE)?
> 
> regards
> shakila

In the M3UA 06 draft:

MTP-TRANSFER is a DATA in section 3.3.1 MTP-STATUS (congestion) is a SCON in
section 3.4.4 MTP-STATUS (user part) is a DUPU in section 3.4.5 MTP-PAUSE is
a DUNA in section 3.4.1
MTP-RESUME is a DAVA in section 3.4.2

-- 
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]
Date: Wed, 20 Jun 2001 01:44:25 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: sua primitives
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-252.dallas.net [209.44.42.252]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Satish,

SUA, unlike M2UA and M3UA does not appear to be mapping the upper boundary
SCCP primitives to SUA peer-to-peer messages.
It comes closer to mapping SCCP peer-to-peer PDUs onto SUA peer-to-peer
messages.  As such, SUA attempts to "tunnel" the SCCP protocol over an SCTP
association, rather than exporting its upper primitive boundary.

Does that help?

Satish K wrote:                                     (Wed, 20 Jun 2001
10:58:29)
> hello,
> We have a doubt on SUA implementation.
> Please refer to section 1.6 of SUA draft.
> 
> The upper layer boundary primitives (e.g N-Connect,N-Data etc) do they
> correspond to which messages of SUA (e.g connection request ) ?
> 
> How to map these primitives to the SUA connection less and connection
> oriented messages ?
> 
> When does these primitives are invoked.
> Is this after the SUA SGP<->ASP connection is setup ? (ASPUP & ASP UP
> ACK)
> 
> If so is when should this SGP<->ASP connection setup should take place.
> Are there primitives corresponding to this ?
> 
> Please explain us these things
> regards
> manjunath
> 

-- 
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: Michael Tüxen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re(2): Max size of m3ua data
Date: Wed, 20 Jun 2001 09:07:13 +0200
X-Mailer: CTM PowerMail 3.0.9 carbon <http://www.ctmdev.com>
X-SMTP-HELO: ilsa.franken.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ilsa.franken.de [193.175.24.42]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear Brian,
see my question below.
Best regards
Michael

-- 
e-mail: [email-masked]

On Tue, Jun 19, 2001, Brian F. G. Bidulock <[email-masked]> wrote:

>Satish,
>
>I believe that maximum size that M3UA can transfer
>is controlled by the underlying MTP3 implementation.
>If the M3UA is supporting IPSP to IPSP signalling,
>over SCTP, the maximum size is limited only by the
>range of stream sequence numbers and path MTU in
>SCTP.
What is the relationship between the M3UA payload size and the stream
sequence numbers/PathMTU?
>If, however, M3UA is supporting signalling
>into a real SS7 network, the M3UA user is limited
>by the maximum size of an MSU that the underlying
>MTP can transfer.  This value is somewhere around
>272 bytes for MSUs for low speed links (max 254
>for ISUP) and larger for Annex A links and MTP3b
>links.  The MTP3-user at M3UA must be congnisant
>of the maximum size supported by the network
>underlying M3UA and need not be stippulated by
>M3UA directly.  ITU provides a suggested procedure
>for discovering the maximum size MSU that can be
>transferred on a given route.
>
>
>Satish K wrote:                                   (Wed, 20 Jun 2001
09:07:28)
>> Hi,
>>    The m3ua drafts says that it can transport any size of signalling
data. I
>> would like to know what would be max size the m3ua can receive from the
ULP.
>> we feel even if it is ISUP it cannot be more than 1024 bytes.
>>   please let me know what can be max signalling data.
>> Thanks
>> Satish K
>
>-- 
>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 leave-sigtran-
>[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: shakila <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: DRST message
Date: Wed, 20 Jun 2001 15:15:46 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

Thanks. In the DRST message, how do we know that the SS7 destination is
restricted? i.e., will the MTP-STATUS inform abt this using cause field?
kindly clarify

regards
shakila

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: shakila <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: RE: MTP primitives format
Date: Wed, 20 Jun 2001 15:25:07 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Brian. yes we found this approach good. when'll this be included in
the m3ua draft?

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Wednesday,
June 20, 2001 12:11 PM To: sigtran
Cc: [email-masked] Subject: Re: MTP primitives
format

shakila,

This is what I proposed for the MTP-TRANSFER primitive (which is really a
DATA message in section 3.3.1).  The reason you don't see tag value 28 is
because this proposal has not been included in an M3UA draft.

Do you support this approach?

shakila wrote:                                     (Wed, 20 Jun 2001
11:54:04)
> Brian,
>
> This is the format of MTP-TRANSFER primitive. The parameter tag value 28
is
> reserved by IETF. Is this value = 23, which corresponds to Originating
Point
> code list? plz clarify.
>
>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |       Service Indicator       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Also could anyone give me the format of other MTP primitives?? (STATUS,
> RESUME, PAUSE)?
>
> regards
> shakila

In the M3UA 06 draft:

MTP-TRANSFER is a DATA in section 3.3.1 MTP-STATUS (congestion) is a SCON in
section 3.4.4 MTP-STATUS (user part) is a DUPU in section 3.4.5 MTP-PAUSE is
a DUNA in section 3.4.1
MTP-RESUME is a DAVA in section 3.4.2

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Vinay Kashyap <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Hii
Date: Wed, 20 Jun 2001 15:50:11 +0530
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META
content="MSHTML 5.00.2314.1000" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /><o:p><PRE><FONT face="Times New
Roman" size=3>Hi All,</FONT></PRE><PRE><FONT face="Times New Roman" size=3>
I wanted 2 know the diff  between Configuration F &amp; Configuration
D.</FONT></PRE><PRE><FONT face="Times New Roman" size=3> Also Regarding  DPC
in Config F </FONT></PRE><PRE><FONT face="Times New Roman" size=3>can 3 diff
AS (AS1, AS2, AS3)have same DPC(DPC X)  as shown
below.</FONT></PRE><PRE><FONT face="Times New Roman" size=3>
Regards</FONT></PRE><PRE><FONT face="Times New Roman"
size=3>Vinay</FONT></PRE><PRE><FONT face="Times New Roman" size=3>Also could
anyone could help on the approach to Testing these M3UA &amp; SCTP
protocols.</FONT></PRE><PRE><FONT face="Times New Roman"
size=3>Regards</FONT></PRE><PRE><FONT face="Times New Roman"
size=3>Vinay</FONT></PRE><PRE>&nbsp;</PRE><PRE><SPAN style="FONT-FAMILY:
'Times New Roman'; FONT-SIZE: 11pt; mso-bidi-font-size: 10.0pt">1.4
Configuration D:<SPAN style="COLOR: red">
</SPAN><o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN: justify"><SPAN
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 11pt; mso-bidi-font-size:
10.0pt"><SPAN style="mso-tab-count:
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp; </SPAN>This configuration is used for all the procedures of
tests concerning two or more AS which are handling traffic for different
network appearance and different routing context. Configuration D is shown
in figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and AS3
is handling traffic for N/w appearance B. AS1 is handling traffic for
Routing Context P, AS2 is handling traffic for Routing Context Q and AS3 is
handling traffic for Routing Context R.<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS1 DPC<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>X<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>| <o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;</SPAN>-------------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| | ASP1<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"> | SG/IPSP<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>| Under
Test<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> | DPC Z<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>--------------<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;</SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| AS2 DPC Y<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;</SPAN>-------------
-------+<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP2<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS3
DPC T<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+-
----------------------|-<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP 3 |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Fig 4:
Configuration D<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'">&nbsp;</SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"></SPAN>&nbsp;</PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"></SPAN>&nbsp;</PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><PRE><SPAN style="FONT-FAMILY:
'Times New Roman'; FONT-SIZE: 11pt; mso-bidi-font-size: 10.0pt">1.6
Configuration F: <o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN:
justify"><SPAN style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 11pt;
mso-bidi-font-size: 10.0pt"><SPAN style="mso-tab-count:
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp; </SPAN>This configuration is used for all the procedures of
tests concerning AS serving different SIO. Configuration F is shown in
figure 6. AS1 is handling the traffic for routing context P, AS2 is handling
for routing<o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN: justify"><SPAN
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 11pt; mso-bidi-font-size:
10.0pt">context Q and AS3 for routing context R. All AS are handling traffic
for N/w appearance A. Point Code of SG/IPSP is Z. AS1 and AS2 are serving
the SIO ISUP but different CIC range and AS3 is serving the SIO
SCCP.<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>--------------<o:p></o:p></SPAN></PR
E><PRE><SPAN style="mso-bidi-font-family: 'Courier New'"><SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS1 DPC<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>X<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>| <o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;</SPAN>-------------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| | ASP1<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"> | SG/IPSP<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>| Under
Test<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> | DPC Z<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>--------------<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;</SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| AS2 DPC X<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;</SPAN>-------------
-------+<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP2<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; </SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS3
DPC X<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+-
----------------------|-<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP 3 |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>
|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Fig 6:
Configuration F<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'"><o:p></o:p></SPAN>&nbsp;</PRE></o:p></SPAN></PRE></FONT></DIV></BODY>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </html>

</x-html>
Date: Wed, 20 Jun 2001 08:02:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Re(2): Max size of m3ua data
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      IAA07020
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-245.dallas.net [209.44.42.245]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Michael,

I don't think that it really matters for the discussion.
It is the MTP3-User's responsibility to limit maximum SDU size.  There is
some large upper limit on the maximum number of DATA chunks which can be
reassembled depending on the implementation.  It would probably not be a
wise idea to send an SDU larger than 2^16 * path MTU.  For timely SS7
operation, it would be wise to send SDUs smaller than path MTU.

--Brian

Michael Tüxen wrote:                      (Wed, 20 Jun 2001 09:07:13)

> Dear Brian,
> see my question below.
> Best regards
> Michael
> 
> -- 
> e-mail: [email-masked]
> 
> On Tue, Jun 19, 2001, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> >Satish,
> >
> >I believe that maximum size that M3UA can transfer
> >is controlled by the underlying MTP3 implementation.
> >If the M3UA is supporting IPSP to IPSP signalling,
> >over SCTP, the maximum size is limited only by the
> >range of stream sequence numbers and path MTU in
> >SCTP.

> What is the relationship between the M3UA payload
> size and the stream sequence numbers/PathMTU?

[snip]

-- 
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]
Date: Wed, 20 Jun 2001 08:11:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: DRST message
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.245]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

shakila,

AFAIK the restricted status of a route is not communicated using the
MTP-STATUS primitive.  A configuration which provides multiple SG to an ASP
will have to be equipped with the "transfer function" at MTP Level 3 at the
SG, and it will be necessary to tap into the MTP Level 3 protocol somehow at
Level 3 to derive the fact that a destination is restricted at the SG (e.g.,
upon receipt of a TFR for the concerned destination).  This event can then
be used to send the DRST message.  Unfortunately, this means that one must
have some mechanism to derive this off of MTP Level 3 code in a non-standard
way, or have control of the MTP Level 3 code.  It may restrict your choice
of commercial 3rd-party MTP Level 3 stacks.

--Brian

shakila wrote:                                 (Wed, 20 Jun 2001 15:15:46)
> Brian,
> 
> Thanks. In the DRST message, how do we know that the SS7 destination is
> restricted? i.e., will the MTP-STATUS inform abt this using cause field?
> kindly clarify
> 
> regards
> shakila

-- 
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]
Date: Wed, 20 Jun 2001 08:12:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Hii
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-245.dallas.net [209.44.42.245]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Vinay,

You have already given a good description of the differences between the two
configurations.  What were you wanting to test?

--Brian

Vinay Kashyap wrote:                                        (Wed, 20 Jun
2001 15:50:11)
> 
> Hi All,
>         I wanted 2 know the diff  between Configuration F & Configuration
D.
>  Also Regarding  DPC in Config F 
> can 3 diff AS (AS1, AS2, AS3)have same DPC(DPC X)  as shown below.
>  Regards
> Vinay
> Also could  anyone could help on the approach to Testing these M3UA & SCTP
prot
> ocols.
> Regards
> Vinay
>  
> 1.4 Configuration D: 
>                This configuration is used for all the procedures of tests
conce
> rning two or more AS which are handling traffic for different network
appearanc
> e and different routing context. Configuration D is shown in figure 4.
AS1, AS2
>  are handling the traffic for N/w Appearance A and AS3 is handling traffic
for 
> N/w appearance B. AS1 is handling traffic for Routing Context P, AS2 is
handlin
> g traffic for Routing Context Q and AS3 is handling traffic for Routing
Context
>  R.
>  
>                                                 --------------
>                                                | AS1 DPC  X   | 
>   -------------                                |  -------     |
>  |             |-------------------------------| | ASP1  |    |
>  | SG/IPSP     |                               |  -------     |  
>  | Under Test  |                                --------------
>  | DPC Z       |                                --------------  
>  |             |-------------------------------| AS2 DPC Y    | 
>   ------------- -------+                       |   -------    |
>                        |                       |  | ASP2  |   | 
>                        |                       |   -------    | 
>                        |                        --------------
>                        |                        --------------  
>                        |                       | AS3 DPC T    | 
>                        +-----------------------|-  -------    | 
>                                                |  | ASP 3 |   |
>                                                |   -------    |
>                                                 --------------
>  
>                        Fig 4: Configuration D
>  
>  
>  
> 1.6 Configuration F: 
>                This configuration is used for all the procedures of tests
conce
> rning AS serving different SIO. Configuration F is shown in figure 6. AS1
is ha
> ndling the traffic for routing context P, AS2 is handling for routing
> context Q and AS3 for routing context R. All AS are handling traffic for
N/w ap
> pearance A. Point Code of SG/IPSP is Z. AS1 and AS2 are serving the SIO
ISUP bu
> t different CIC range and AS3 is serving the SIO SCCP.
>  
>                                                 --------------
>                                                | AS1 DPC  X   | 
>   -------------                                |  -------     |
>  |             |-------------------------------| | ASP1  |    |
>  | SG/IPSP     |                               |  -------     |  
>  | Under Test  |                                --------------
>  | DPC Z       |                                --------------  
>  |             |-------------------------------| AS2 DPC X    | 
>   ------------- -------+                       |   -------    |
>                        |                       |  | ASP2  |   | 
>                        |                       |   -------    | 
>                        |                        --------------
>                        |                        --------------  
>                        |                       | AS3 DPC X    | 
>                        +-----------------------|-  -------    | 
>                                                |  | ASP 3 |   |
>                                                |   -------    |
>                                                 --------------
>  
>                      Fig 6: Configuration F
>  
> 
>  
> 
>    ---
>    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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 20 Jun 2001 11:14:41 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: SUA-06 & M2UA-08 Common Parameters
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

John,

I agree that we should align with IUA.  M2UA overlaps (after a bit of
re-arranging) with the exception of ASP ID.  
We can number ASP ID after all of the M3UA/SUA common parameters.

Can you get with Greg to number the M3UA/SUA common parameters?

R-

Ken

At 01:05 PM 6/19/01 +0300, you wrote:
>Hi Joyce,
>
> > The new drafts of SUA and M2UA both contain a list of common 
> > parameters "used by all User Adaptation layers". Unfortunately the 
> > lists are different:
> > 
> >   Tag   M2UA            M3UA          SUA            IUA
> >   -----------------------------------------------------------------
> >   0x1   IntfaceId(Int)  NetworkApp    NetworkApp     IntfaceId(Int)
> >   0x2   IntfaceId(Rng)  Data          Unused         Unused
> >   0x3   IntfaceId(Txt)  Data (TTC)    Data           IntfaceId(Txt)
> >   0x4   Info String     Info String   Info String    Info String
> >   0x5   Unused          AffectDests   AffectPC       DLCI
> >   0x6   Unused          RoutgContxt   RoutgContxt    Unused
> >   0x7   Diag Info       Diag Info     Diag Info      Diag Info
> >   0x8   HeartbeatData   HeartbeatData HeartbeatData  IntfaceId(Rng)
> >   0x9   Unused          User/Cause    Unused         HeartbeatData 
> >   0xa   Reason          Reason        Reason         Reason
> >   0xb   Traffic Mode    Traffic Mode  Traffic Mode   Traffic Mode
> >   0xc   Error Code      Error Code    Error Code     Error Code
> >   0xd   StsType/Info    StsType/ID    StsType/ID     StsType/ID
> >   0xe   ASP Id          CongestInds   CongestLevel   Data
>
>Thanks for writing this up.  This is a big help.  I agree with you
>that we need to agree on this.  Since IUA is already an RFC, perhaps
>we need to work around it.
>
>Greg, Ken - what do you suggest?
>
>br,
>John
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Hii
Date: Thu, 21 Jun 2001 01:16:17 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:o
= "urn:schemas-microsoft-com:office:office"><HEAD> <META
http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4207.2601" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">Vinay

  Kashyap</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=[email-masked] 
  href="mailto:[email-masked]">sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, June 20, 2001 6:20 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Hii</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=Arial size=2><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><o:p><PRE><FONT face="Times New Roman" size=3>Hi
All,</FONT></PRE><PRE><FONT face="Times New Roman" size=3>        I wanted 2
know the diff  between Configuration F &amp; Configuration
D.<BR></FONT></PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman" size=3>[Greg]
You defined the differences - it's not clear what you are asking
here.</FONT></PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman"
size=3>&nbsp;</PRE></FONT><PRE><FONT face="Times New Roman" size=3> Also
Regarding  DPC in Config F </FONT></PRE><PRE><FONT face="Times New Roman"
size=3>can 3 diff AS (AS1, AS2, AS3)have same DPC(DPC X)  as shown
below.</FONT></PRE><PRE><FONT face="Times New Roman" size=3>
Regards</FONT></PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman" size=3>[Greg]
Yes.</FONT></PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman"
size=3></FONT>&nbsp;</PRE><PRE><FONT face="Times New Roman"
size=3>Vinay</FONT></PRE><PRE><FONT face="Times New Roman" size=3>Also could
anyone could help on the approach to Testing these M3UA &amp; SCTP
protocols.</FONT></PRE><PRE><FONT face="Times New Roman"
size=3>Regards</FONT></PRE><PRE><FONT face="Times New Roman"
size=3>Vinay</FONT></PRE><PRE>&nbsp;</PRE><PRE><SPAN style="FONT-SIZE: 11pt;
FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt">1.4
Configuration D:<SPAN style="COLOR: red">
</SPAN><o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN: justify"><SPAN
style="FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size:
10.0pt"><SPAN style="mso-tab-count:
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp; </SPAN>This configuration is used for all the procedures of
tests concerning two or more AS which are handling traffic for different
network appearance and different routing context. Configuration D is shown
in figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and AS3
is handling traffic for N/w appearance B. AS1 is handling traffic for
Routing Context P, AS2 is handling traffic for Routing Context Q and AS3 is
handling traffic for Routing Context R.<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS1 DPC<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>X<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>| <o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;</SPAN>-------------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| | ASP1<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"> | SG/IPSP<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>| Under
Test<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> | DPC Z<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>--------------<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;</SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| AS2 DPC Y<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;</SPAN>-------------
-------+<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP2<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS3
DPC T<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+-
----------------------|-<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP 3 |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Fig 4:
Configuration D<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'">&nbsp;</SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"></SPAN>&nbsp;</PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"></SPAN>&nbsp;</PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><PRE><SPAN style="FONT-SIZE:
11pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt">1.6
Configuration F: <o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN:
justify"><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman';
mso-bidi-font-size: 10.0pt"><SPAN style="mso-tab-count:
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp; </SPAN>This configuration is used for all the procedures of
tests concerning AS serving different SIO. Configuration F is shown in
figure 6. AS1 is handling the traffic for routing context P, AS2 is handling
for routing<o:p></o:p></SPAN></PRE><PRE style="TEXT-ALIGN: justify"><SPAN
style="FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size:
10.0pt">context Q and AS3 for routing context R. All AS are handling traffic
for N/w appearance A. Point Code of SG/IPSP is Z. AS1 and AS2 are serving
the SIO ISUP but different CIC range and AS3 is serving the SIO
SCCP.<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>--------------<o:p></o:p></SPAN></PR
E><PRE><SPAN style="mso-bidi-font-family: 'Courier New'"><SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS1 DPC<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>X<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>| <o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;</SPAN>-------------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>-------<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| | ASP1<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"> | SG/IPSP<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>| Under
Test<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"> | DPC Z<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>--------------<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;</SPAN>|<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
; </SPAN>|-------------------------------| AS2 DPC X<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;</SPAN>-------------
-------+<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP2<SPAN style="mso-spacerun:
yes">&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; </SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN><o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<
SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>| AS3
DPC X<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+-
----------------------|-<SPAN style="mso-spacerun: yes">&nbsp;
</SPAN>-------<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|
<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family: 'Courier
New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN
style="mso-spacerun: yes">&nbsp; </SPAN>| ASP 3 |<SPAN style="mso-spacerun:
yes">&nbsp;&nbsp; </SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>
|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>-------<SPAN
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
</SPAN>|<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</SPAN>--------------<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE><PRE><SPAN style="mso-bidi-font-family:
'Courier New'"><SPAN style="mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Fig 6:
Configuration F<o:p></o:p></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'">&nbsp;<o:p></o:p></SPAN></PRE></SPAN></PRE><PRE><SPAN
style="mso-bidi-font-family: 'Courier
New'"><o:p></o:p></SPAN>&nbsp;</PRE></o:p></SPAN></PRE></FONT></DIV>---<BR>Y
ou 
  are currently subscribed to sigtran as: [email-masked]<BR>To
unsubscribe 
  send a blank email to [email-masked]
</BLOCKQUOTE>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: Re: MTP primitives format
Date: Thu, 21 Jun 2001 03:41:45 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Shakila,

Can you describe why you feel Brian's format proposal  for the Data message
is better than the current description in M3UA Section 3.3.1.   I'll go back
to Brian's e-mail (June 4th - "Packing of Data protocols") and take another
look but from my perspective I don't see any advantage to changing the
format at this time.  I haven't seen any support for the proposed changes on
the list so I'll ask others to take a look as well.

Cheers,

   Greg

----- Original Message -----
From: "shakila" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "bidulock" <[email-masked]>
Sent: Wednesday, June 20, 2001 5:55 AM
Subject: RE: MTP primitives format

> Thanks Brian. yes we found this approach good. when'll this be included in
> the m3ua draft?
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 12:11 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: MTP primitives format
>
>
> shakila,
>
> This is what I proposed for the MTP-TRANSFER primitive (which is
> really a DATA message in section 3.3.1).  The reason you don't
> see tag value 28 is because this proposal has not been included
> in an M3UA draft.
>
> Do you support this approach?
>
> shakila wrote:                                     (Wed, 20 Jun 2001
> 11:54:04)
> > Brian,
> >
> > This is the format of MTP-TRANSFER primitive. The parameter tag value 28
> is
> > reserved by IETF. Is this value = 23, which corresponds to Originating
> Point
> > code list? plz clarify.
> >
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |       Service Indicator       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Also could anyone give me the format of other MTP primitives?? (STATUS,
> > RESUME, PAUSE)?
> >
> > regards
> > shakila
>
> In the M3UA 06 draft:
>
> MTP-TRANSFER is a DATA in section 3.3.1
> MTP-STATUS (congestion) is a SCON in section 3.4.4
> MTP-STATUS (user part) is a DUPU in section 3.4.5
> MTP-PAUSE is a DUNA in section 3.4.1
> MTP-RESUME is a DAVA in section 3.4.2
>
> --
> 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]
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Date: Thu, 21 Jun 2001 03:42:09 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Brian,

Some responses (finally!) below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Monday, June 04, 2001 3:08 PM
Subject: M3UA: Packing of DATA Payloads

Greg,

I see a number of difficulties in the packing and unpacking, and filtering
of DATA Payload information.  Perhaps not suprisingly, the MTP primitive
MTP-TRANSFER does not contain the MTP Routing Label in the data payload.
The MTP RL is the MTP Level 3 Header (much like an IP header) and is not
part of the payload transferred to an from the MTP-User.

[Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
contain the OPC, DPC, SLS and SIO.  The Routing Label format was used for
the Protocol Data parameter in the Data message so that these fields are not
re-encoded across the SG.

The MTP-TRANSFER primitive is defined in Q.701 as having the following
parameters:

        OPC (see 2.2/Q.704)
        DPC (see 2.2/Q.704)
        SLS (see 2.2/Q.704)
        SIO (see 14.2/Q.704)
        User data (see 2.3.8/Q.703)

You will find the same list of parameters in Table 9/T1.112.1.

In neither list is the NI (Network Indicator) or MP (Message Priority)
listed.  This is, IMHO, because the assignment of these values is to be
peformed by MTP and is not at the discretion of the MTP-User.

[Greg] No, the NI and MP (national use) are shown as part of the SIO
Subservice Field in the relevant MTP3 recommendations (Q.704 Section 14.2 or
national equivalent).  Q.701 Table 1 (and your list above) lists the SIO as
a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
details.  So IMO the SIO Subservice Field is included in the MTP-TRANSFER
and therfore the NI and MP (national variants) are there.   I'm not sure how
all SS7 vendors implemented the MTP-TRANSFER primitive as it is not visible,
but I've always assumed that the MTP3-User assigns the Message priority.
The NI could be picked up without the MTP3-User assigning it but I'm not
sure that it really matters.

In comparing this primitive to the Payload Data Message (DATA) in Section
3.3.1 and bearing in mind the statements of Section 4.1.1 with regards to
MTP-Transfer, and considering IPSP operation, I have the following problems:

When M3UA receives an MTP-TRANSFER primitive from the NIF or MTP-User, M3UA
is required to pack a routing label into the Payload of a DATA message.
Because the MTP-TRANSFER primitive does not contain NI or MP parameters,
M3UA will have to generate them.

[Greg] I don't agree - see above.  IMO the NI and MP are in the MTP-TRANSFER
primitive.

Also, M3UA will have to choose some variant for the packing of the DATA
Payload.  The receiving M3UA will have to unpack the same data to be able to
generate an MTP-TRANSFER primitive to its MTP-User.

[Greg] The M3UA at the SG doesn't really have to do any choosing of
variants.  The format of the incoming SIO/Routing Label/User Data is already
packed according to the MTP3 variant and is not changed.  The M3UA at the
receiver knows the variant used and the expectations of the format for the
upper layer primitive to the MTP3-User instance.

This seems ridiculous, particularly in the IPSP case, where the packing and
unpacking is rather arbitrary.  It makes far more sense to pass the OPC,
DPC, SLS and SIO as separate parameters of the DATA message and leave the
User data from the MTP-TRANSFER primitive as the Payload Data.

[Greg] The IPSP case is a little more arbitrary, as you say, but was left
consistent with the SG/ASP case.

You will note that MP is *not* part of the MTP-TRANSFER primitive and there
is no need to distinguish between ITU (w/o MP), ANSI, and TTC approaches in
the Payload Data when the proper parameters are added to the message.  It is
the responsibility of MTP Level 3 to determine the Message Priority of a
MTP-User message and not the responsibility of the MTP-User.  The same is
true for NI and it no longer becomes necessary to include a Network
Appearance parameter at all.  (More on Network Appearance later...)

[Greg] I guess we don't agree - IMO the Message priority assignment is done
by the MTP3-User (TTC might be an exception though).

The format of the routing label, by the way, can be dependent upon SIO, and
in some networks it is.  For example, one SIO value can be assigned for
National ISUP (where the routing label is formatted using, say 24-bit point
code) and another assigned for International ISUP (where the routing label
is formatted using 14-bit point code).  See Q.704 (07/96) Section 2.2.1,
last paragraph on Page 4.

[Greg]  That is fine.  The current approach can handle this as the SIO and
Routing Label formats are not changed.

Treating the OPC, DPC, SLS and SIO as separate from the message is no
different than placing the Affected PC in a parameter for the MTP-PAUSE,
MTP-RESUME, and MTP-STATUS primitives.  The point codes should be split out
with TLV parameters similar to those used to represent point codes in the
DUNA and DAVA messages.  SLS and SIO will require their own parameters.
Because these parameters are mandatory parameters of the MTP-TRANSFER
primitive, it may be useful to group them and place them in a single TLV as
follows:

[Greg]  Brian, this approach was considered early and had some proponents.
But a choice was made for the current method.  The same appoach wasn't used
for MTP-PAUSE/RESUME/STATUS because these were generated internal to the SG
by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the SS7
network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It may look
oddto some people but I think it works.

    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 = 28           |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Originating Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Signalling Link Selection   |       Service Indicator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where now the Protocol Data would only contain MTP-User data.

Note that I have removed the "Network Appearance" parameter.  This is
because it is useless.  The Network Appearance parameter is based on the
premise that it somehow defines the point code format used.
This is not the case, as the Service Indicator Octet (and NI) must also be
taken into consideration when determining the point code format.

[Greg] The Network Appearance indicates the SS7 network partition (SG
links/linksets/routes/routesets) for the messages to be sent/received at the
SG.  It is certainly not useless.  Within a network partition, only one
point code format would be used.

By the same token, Network Appearance is useless in DUNA and DAVA messages.
There is no network indicator provided in MTP-PAUSE and MTP-RESUME
primitives.

[Greg] The alternative was to provide a Point Code Format field/parameter
and have entries for every PC permutation.  As you say the Network
Appearance is not passed up in MTP-PAUSE and RESUME primitives - it is used
in the M3UA to pass these primitives to the correct MTP3-User instances at
the ASPs.  The Network Appearance was already used to direct the
MTP-TRANSFER primitives to the correct instance so it was re-used instead.

On the other hand, for Q.701 7.2.6 operation with indication of SIF
permitted in TFP/TFA messages, the Affected PC parameters of DUNA and DAVA
need to be expanded to include the SIF bits present in these indications.

[Greg]  This section is talking about Red Book to Blue Book link
interworking.  Unless anyone is building an SG with links into a Red Book
MTP network (62-octet SIF maximum) I think we can ignore this.

Cheers,

   Greg Sidebottom

Actually, Network Appearance should be struck from the whole document.

--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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA-06 & M2UA-08 Common Parameters
Date: Thu, 21 Jun 2001 03:48:41 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi John,

I'll give you a call tomorrow to settle up these assignments!  Drop me an
e-mail (to [email-masked] ) to arrange a time.

Cheers,

   Greg

----- Original Message -----
From: "Ken Morneault" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, June 20, 2001 11:14 AM
Subject: RE: SUA-06 & M2UA-08 Common Parameters

>
>
> John,
>
> I agree that we should align with IUA.  M2UA overlaps (after
> a bit of re-arranging) with the exception of ASP ID.
> We can number ASP ID after all of the M3UA/SUA common
> parameters.
>
> Can you get with Greg to number the M3UA/SUA common
> parameters?
>
> R-
>
> Ken
>
> At 01:05 PM 6/19/01 +0300, you wrote:
> >Hi Joyce,
> >
> > > The new drafts of SUA and M2UA both contain a list of common
> > > parameters "used by all User Adaptation layers". Unfortunately the
> > > lists are different:
> > >
> > >   Tag   M2UA            M3UA          SUA            IUA
> > >   -----------------------------------------------------------------
> > >   0x1   IntfaceId(Int)  NetworkApp    NetworkApp     IntfaceId(Int)
> > >   0x2   IntfaceId(Rng)  Data          Unused         Unused
> > >   0x3   IntfaceId(Txt)  Data (TTC)    Data           IntfaceId(Txt)
> > >   0x4   Info String     Info String   Info String    Info String
> > >   0x5   Unused          AffectDests   AffectPC       DLCI
> > >   0x6   Unused          RoutgContxt   RoutgContxt    Unused
> > >   0x7   Diag Info       Diag Info     Diag Info      Diag Info
> > >   0x8   HeartbeatData   HeartbeatData HeartbeatData  IntfaceId(Rng)
> > >   0x9   Unused          User/Cause    Unused         HeartbeatData
> > >   0xa   Reason          Reason        Reason         Reason
> > >   0xb   Traffic Mode    Traffic Mode  Traffic Mode   Traffic Mode
> > >   0xc   Error Code      Error Code    Error Code     Error Code
> > >   0xd   StsType/Info    StsType/ID    StsType/ID     StsType/ID
> > >   0xe   ASP Id          CongestInds   CongestLevel   Data
> >
> >Thanks for writing this up.  This is a big help.  I agree with you
> >that we need to agree on this.  Since IUA is already an RFC, perhaps
> >we need to work around it.
> >
> >Greg, Ken - what do you suggest?
> >
> >br,
> >John
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
[email-masked]
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: DRST message
Date: Thu, 21 Jun 2001 03:57:49 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.90]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

One tiny clarification below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc:
<[email-masked]> Sent: Wednesday, June 20, 2001
9:11 AM
Subject: Re: DRST message

> shakila,
>
> AFAIK the restricted status of a route is not communicated using
> the MTP-STATUS primitive.  A configuration which provides multiple
> SG to an ASP will have to be equipped with the "transfer function"
> at MTP Level 3 at the SG, and it will be necessary to tap into the
> MTP Level 3 protocol somehow at Level 3 to derive the fact that
> a destination is restricted at the SG (e.g., upon receipt of a TFR
> for the concerned destination).

[Greg] The example wouldn't be reception of a TFR but rather a TFP or
linkset failure that results in the normal (highest priority / lowest cost)
route to a destination becoming unavailable.

Cheers,

  Greg Sidebottom

This event can then be used to send
> the DRST message.  Unfortunately, this means that one must have
> some mechanism to derive this off of MTP Level 3 code in a non-standard
> way, or have control of the MTP Level 3 code.  It may restrict your
> choice of commercial 3rd-party MTP Level 3 stacks.
>
> --Brian
>
> shakila wrote:                                 (Wed, 20 Jun 2001 15:15:46)
> > Brian,
> >
> > Thanks. In the DRST message, how do we know that the SS7 destination is
> > restricted? i.e., will the MTP-STATUS inform abt this using cause field?
> > kindly clarify
> >
> > regards
> > shakila
>
> --
> 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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: ASP Down (Ack)
Date: Thu, 21 Jun 2001 04:17:46 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings,

Well there are three reasons in the M3UA:

         0       Unspecified
         1       User Unavailable
         2       Management Blocking

Although, calling "unspecified" a reason is stretching it  2;^)     

Cheers,

   Greg

----- Original Message ----- 
From: "Ken Morneault" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, June 19, 2001 8:00 PM
Subject: Re: M2UA 08: ASP Down (Ack)

> 
> 
> Note:  This request should be considered for all the UAs (M3UA, SUA,
> and M2UA).
> 
> At 02:23 PM 6/19/01 -0500, you wrote:
> >What is the point of a "Reason" parameter in the
> >ASPDN and ASPDN Ack messages where there is only
> >one valid value for the parameter?
> >
> >-- 
> >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]
Date: Thu, 21 Jun 2001 03:41:08 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      DAA29847
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Please see comments below....

Greg Sidebottom wrote:                          (Thu, 21 Jun 2001 03:42:09)
> Thanks Brian,
> 
> Some responses (finally!) below ...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, June 04, 2001 3:08 PM
> Subject: M3UA: Packing of DATA Payloads
> 
> 
> Greg,
> 
> I see a number of difficulties in the packing and unpacking,
> and filtering of DATA Payload information.  Perhaps not
> suprisingly, the MTP primitive MTP-TRANSFER does not contain
> the MTP Routing Label in the data payload.  The MTP RL is
> the MTP Level 3 Header (much like an IP header) and is not
> part of the payload transferred to an from the MTP-User.
> 
> [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> contain the OPC, DPC, SLS and SIO.  The Routing Label format was used for
> the Protocol Data parameter in the Data message so that these fields are
not
> re-encoded across the SG.

Ah, but they will be.  You see the SG MTP3 must unpack the routing label to
determine whether the MSU is a management message.  By the time the MSU gets
to an MTP3-User, the routing label has likely been removed and placed into
an internal representation.  To put it back into the M3UA message would
require an MTP3 routing label encoder.  If you look at M3UA in a simple case
where it is just an MTP3-User, this is normally the case.  The MTP3-User
does not have (nor want) direct access to the L3 protocol header.

> 
> 
> 
> The MTP-TRANSFER primitive is defined in Q.701 as having the
> following parameters:
> 
>         OPC (see 2.2/Q.704)
>         DPC (see 2.2/Q.704)
>         SLS (see 2.2/Q.704)
>         SIO (see 14.2/Q.704)
>         User data (see 2.3.8/Q.703)
> 
> You will find the same list of parameters in Table 9/T1.112.1.
> 
> In neither list is the NI (Network Indicator) or MP (Message
> Priority) listed.  This is, IMHO, because the assignment of
> these values is to be peformed by MTP and is not at the discretion
> of the MTP-User.
> 
> [Greg] No, the NI and MP (national use) are shown as part of the SIO
> Subservice Field in the relevant MTP3 recommendations (Q.704 Section 14.2
or
> national equivalent).  Q.701 Table 1 (and your list above) lists the SIO
as
> a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
> details.  So IMO the SIO Subservice Field is included in the MTP-TRANSFER
> and therfore the NI and MP (national variants) are there.   I'm not sure
how
> all SS7 vendors implemented the MTP-TRANSFER primitive as it is not
visible,
> but I've always assumed that the MTP3-User assigns the Message priority.
> The NI could be picked up without the MTP3-User assigning it but I'm not
> sure that it really matters.

In further discussion on SUA, it appears that MP must be assigned by SCCP in
some cases (MTP3 is not expected to have knowledge of SCCP users) so it
should be part of the structure in some form.  I would suggest unpacking it.
NI is clearly part of the MTP-SAPID and does not need to be transferred.
> 
> 
> 
> In comparing this primitive to the Payload Data Message (DATA)
> in Section 3.3.1 and bearing in mind the statements of Section
> 4.1.1 with regards to MTP-Transfer, and considering IPSP operation,
> I have the following problems:
> 
> When M3UA receives an MTP-TRANSFER primitive from the NIF or
> MTP-User, M3UA is required to pack a routing label into the Payload
> of a DATA message.  Because the MTP-TRANSFER primitive does not
> contain NI or MP parameters, M3UA will have to generate them.
> 
> [Greg] I don't agree - see above.  IMO the NI and MP are in the
MTP-TRANSFER
> primitive.

See Al's discussion on SUA thread.

> 
> 
> Also, M3UA will have to choose some variant for the packing of
> the DATA Payload.  The receiving M3UA will have to unpack the
> same data to be able to generate an MTP-TRANSFER primitive to
> its MTP-User.
> 
> [Greg] The M3UA at the SG doesn't really have to do any choosing of
> variants.  The format of the incoming SIO/Routing Label/User Data is
already
> packed according to the MTP3 variant and is not changed.  The M3UA at the
> receiver knows the variant used and the expectations of the format for the
> upper layer primitive to the MTP3-User instance.

With the data already unpacked from the MTP3 RL, the M3UA at the ASP need
not know the RL structure to provide the MTP-TRANSFER primitive to its
users.  Less chance for error, less parsing/building effort.

> 
> 
> 
> This seems ridiculous, particularly in the IPSP case, where the
> packing and unpacking is rather arbitrary.  It makes far more sense
> to pass the OPC, DPC, SLS and SIO as separate parameters of the
> DATA message and leave the User data from the MTP-TRANSFER primitive
> as the Payload Data.
> 
> [Greg] The IPSP case is a little more arbitrary, as you say, but was left
> consistent with the SG/ASP case.
> 
> 
> You will note that MP is *not* part of the MTP-TRANSFER primitive
> and there is no need to distinguish between ITU (w/o MP), ANSI,
> and TTC approaches in the Payload Data when the proper parameters
> are added to the message.  It is the responsibility of MTP Level 3
> to determine the Message Priority of a MTP-User message and not
> the responsibility of the MTP-User.  The same is true for NI and
> it no longer becomes necessary to include a Network Appearance
> parameter at all.  (More on Network Appearance later...)
> 
> [Greg] I guess we don't agree - IMO the Message priority assignment is
done
> by the MTP3-User (TTC might be an exception though).

Again, from SUA thread, SCCP must assign MP.  I don't care if it is added in
the structure.  Just don't leave it in the routing label, and no need for
differences for TTC.

> 
> 
> The format of the routing label, by the way, can be dependent
> upon SIO, and in some networks it is.  For example, one SIO
> value can be assigned for National ISUP (where the routing
> label is formatted using, say 24-bit point code) and another
> assigned for International ISUP (where the routing label is
> formatted using 14-bit point code).  See Q.704 (07/96) Section
> 2.2.1, last paragraph on Page 4.
> 
> [Greg]  That is fine.  The current approach can handle this as the SIO and
> Routing Label formats are not changed.

But forces the work on the ASP when the SG MTP3 is already fitted with
routing label parser/generators.

> 
> 
> Treating the OPC, DPC, SLS and SIO as separate from the message
> is no different than placing the Affected PC in a parameter for
> the MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives.  The point
> codes should be split out with TLV parameters similar to those
> used to represent point codes in the DUNA and DAVA messages.  SLS
> and SIO will require their own parameters.  Because these
> parameters are mandatory parameters of the MTP-TRANSFER primitive,
> it may be useful to group them and place them in a single TLV
> as follows:
> 
> [Greg]  Brian, this approach was considered early and had some proponents.
> But a choice was made for the current method.  The same appoach wasn't
used
> for MTP-PAUSE/RESUME/STATUS because these were generated internal to the
SG
> by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the SS7
> network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It may look
> oddto some people but I think it works.

What is the difference from extracting the PC from a TFP and putting it into
a DUNA an extracting a PC from a routing label and putting it in a DATA
message?  Sorry, but both are generated internal to the SG.

I think this should be re-examined.  I surely didn't hear any objections to
this proposal.  Are there any objections out there?

> 
> 
> 
>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |       Service Indicator       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where now the Protocol Data would only contain MTP-User data.
> 
> 
> Note that I have removed the "Network Appearance" parameter.  This
> is because it is useless.  The Network Appearance parameter is based
> on the premise that it somehow defines the point code format used.
> This is not the case, as the Service Indicator Octet (and NI) must
> also be taken into consideration when determining the point code
> format.
> 
> [Greg] The Network Appearance indicates the SS7 network partition (SG
> links/linksets/routes/routesets) for the messages to be sent/received at
the
> SG.  It is certainly not useless.  Within a network partition, only one
> point code format would be used.

But, an ASP cannot span multiple SPMCs, so the routing context defines the
network appearance and the network appearance is redundant.

> 
> 
> By the same token, Network Appearance is useless in DUNA and DAVA
> messages.  There is no network indicator provided in MTP-PAUSE
> and MTP-RESUME primitives.
> 
> [Greg] The alternative was to provide a Point Code Format field/parameter
> and have entries for every PC permutation.  As you say the Network
> Appearance is not passed up in MTP-PAUSE and RESUME primitives - it is
used
> in the M3UA to pass these primitives to the correct MTP3-User instances at
> the ASPs.  The Network Appearance was already used to direct the
> MTP-TRANSFER primitives to the correct instance so it was re-used instead.

Again, the ASP knows the point code format from the routing context (because
it cannot span multiple SPMCs).  The network appearance is redundant.

> 
> 
> On the other hand, for Q.701 7.2.6 operation with indication of
> SIF permitted in TFP/TFA messages, the Affected PC parameters of
> DUNA and DAVA need to be expanded to include the SIF bits present
> in these indications.
> 
> [Greg]  This section is talking about Red Book to Blue Book link
> interworking.  Unless anyone is building an SG with links into a Red Book
> MTP network (62-octet SIF maximum) I think we can ignore this.
> 
> Cheers,
> 
>    Greg Sidebottom
> 
> 
> Actually, Network Appearance should be struck from the whole
> document.
> 
> --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]

-- 
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]
Date: Thu, 21 Jun 2001 03:54:53 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: DRST message
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Receipt of a TFR can also trigger transfer restricted procedures (Q.704
13.4.3).  I was actually describing M3UA's diagram with SGs with no C-links,
where the only reason for sending DRST must be the receipt of a TFR or
congestion on an alternative link set.  If you want to use the example where
C-links (lower priority route) are causing the restricted condition at the
SG, I suggest we draw C-links on the M3UA STP-SG diagram.  Otherwise, we
should use the non-C-link cases which are receipt of a TFR on the only (or
all) routes to the affected destination, or imminent congestion on an
alternate link set.

--Brian

Greg Sidebottom wrote:                    (Thu, 21 Jun 2001 03:57:49)
> Hi Brian,
> 
> One tiny clarification below ...
> 
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 20, 2001 9:11 AM
> Subject: Re: DRST message
> 
> 
> > shakila,
> >
> > AFAIK the restricted status of a route is not communicated using
> > the MTP-STATUS primitive.  A configuration which provides multiple
> > SG to an ASP will have to be equipped with the "transfer function"
> > at MTP Level 3 at the SG, and it will be necessary to tap into the
> > MTP Level 3 protocol somehow at Level 3 to derive the fact that
> > a destination is restricted at the SG (e.g., upon receipt of a TFR
> > for the concerned destination).
> 
> [Greg] The example wouldn't be reception of a TFR but rather a TFP or
> linkset failure that results in the normal (highest priority / lowest
cost)
> route to a destination becoming unavailable.

No.  My example was reception of a TFR ala Q.704 13.4.3 with no C-links (and
no D-links for that matter).

> 
> Cheers,
> 
>   Greg Sidebottom
> 
> 
> 
> This event can then be used to send
> > the DRST message.  Unfortunately, this means that one must have
> > some mechanism to derive this off of MTP Level 3 code in a non-standard
> > way, or have control of the MTP Level 3 code.  It may restrict your
> > choice of commercial 3rd-party MTP Level 3 stacks.
> >
> > --Brian
> >
> > shakila wrote:                                 (Wed, 20 Jun 2001
15:15:46)
> > > Brian,
> > >
> > > Thanks. In the DRST message, how do we know that the SS7 destination
is
> > > restricted? i.e., will the MTP-STATUS inform abt this using cause
field?
> > > kindly clarify
> > >
> > > regards
> > > shakila
> >
> > --
> > 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]

-- 
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]
Date: Thu, 21 Jun 2001 03:57:03 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA 08: ASP Down (Ack)
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

What does "User Unavailable" mean?

--Brian

Greg Sidebottom wrote:                                       (Thu, 21 Jun
2001 04:17:46)
> Greetings,
> 
> Well there are three reasons in the M3UA:
> 
>          0       Unspecified
>          1       User Unavailable
>          2       Management Blocking
> 
> Although, calling "unspecified" a reason is stretching it  2;^)     
> 
> Cheers,
> 
>    Greg
> 
> ----- Original Message ----- 
> From: "Ken Morneault" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Tuesday, June 19, 2001 8:00 PM
> Subject: Re: M2UA 08: ASP Down (Ack)
> 
> 
> > 
> > 
> > Note:  This request should be considered for all the UAs (M3UA, SUA,
> > and M2UA).
> > 
> > At 02:23 PM 6/19/01 -0500, you wrote:
> > >What is the point of a "Reason" parameter in the
> > >ASPDN and ASPDN Ack messages where there is only
> > >one valid value for the parameter?
> > >
> > >-- 
> > >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]

-- 
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]
Date: Thu, 21 Jun 2001 10:39:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Greg Sidebottom wrote:                         (Thu, 21 Jun 2001 03:42:09)
> 
> [Greg]  Brian, this approach was considered early and had some proponents.
> But a choice was made for the current method.

I don't see on the mailing list where this was considered at all.
Are you talking about pre-June-1999 pre-ITUN discussions?  Would it be
possible to reference a thread or minutes where this was discussed?

-- 
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: DRST message
Date: Thu, 21 Jun 2001 12:37:14 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

Sure, but this is an optional action at an STP which I assume is pretty rare
in national SS7 networks (received TFR on normal route, no alternative
routes, STP MAY send additional TFRs.

Fair enough though, I do see your point for M3UA - if there is no "C-link"
(or equivalent SGP-SGP communication) then an SG vendor could use this
clause to generate DRSTs.  I have always assumed that there is a "C-link" or
equivalent beween the SG(P)s.   I have added connectivity between the two
SGs ("C-link" or inter-SGP communication) based on your previous comments.

Thanks,

   Greg Sidebottom

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, June 21, 2001 4:54 AM
Subject: Re: DRST message

> Greg,
>
> Receipt of a TFR can also trigger transfer restricted procedures
> (Q.704 13.4.3).  I was actually describing M3UA's diagram with SGs
> with no C-links, where the only reason for sending DRST must be the
> receipt of a TFR or congestion on an alternative link set.  If you
> want to use the example where C-links (lower priority route) are
> causing the restricted condition at the SG, I suggest we draw
> C-links on the M3UA STP-SG diagram.  Otherwise, we should use the
> non-C-link cases which are receipt of a TFR on the only (or all)
> routes to the affected destination, or imminent congestion on an
> alternate link set.
>
> --Brian
>
> Greg Sidebottom wrote:                    (Thu, 21 Jun 2001 03:57:49)
> > Hi Brian,
> >
> > One tiny clarification below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, June 20, 2001 9:11 AM
> > Subject: Re: DRST message
> >
> >
> > > shakila,
> > >
> > > AFAIK the restricted status of a route is not communicated using
> > > the MTP-STATUS primitive.  A configuration which provides multiple
> > > SG to an ASP will have to be equipped with the "transfer function"
> > > at MTP Level 3 at the SG, and it will be necessary to tap into the
> > > MTP Level 3 protocol somehow at Level 3 to derive the fact that
> > > a destination is restricted at the SG (e.g., upon receipt of a TFR
> > > for the concerned destination).
> >
> > [Greg] The example wouldn't be reception of a TFR but rather a TFP or
> > linkset failure that results in the normal (highest priority / lowest
cost)
> > route to a destination becoming unavailable.
>
> No.  My example was reception of a TFR ala Q.704 13.4.3 with no
> C-links (and no D-links for that matter).
>
> >
> > Cheers,
> >
> >   Greg Sidebottom
> >
> >
> >
> > This event can then be used to send
> > > the DRST message.  Unfortunately, this means that one must have
> > > some mechanism to derive this off of MTP Level 3 code in a
non-standard
> > > way, or have control of the MTP Level 3 code.  It may restrict your
> > > choice of commercial 3rd-party MTP Level 3 stacks.
> > >
> > > --Brian
> > >
> > > shakila wrote:                                 (Wed, 20 Jun 2001
15:15:46)
> > > > Brian,
> > > >
> > > > Thanks. In the DRST message, how do we know that the SS7 destination
is
> > > > restricted? i.e., will the MTP-STATUS inform abt this using cause
field?
> > > > kindly clarify
> > > >
> > > > regards
> > > > shakila
> > >
> > > --
> > > 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]
>
> --
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Date: Thu, 21 Jun 2001 13:28:58 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Brian,

Responses below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Thursday, June 21, 2001 4:41 AM
Subject: Re: Packing of DATA Payloads

Greg,

Please see comments below....

Greg Sidebottom wrote:                          (Thu, 21 Jun 2001 03:42:09)
> Thanks Brian,
>
> Some responses (finally!) below ...
>
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Monday, June 04, 2001 3:08 PM
> Subject: M3UA: Packing of DATA Payloads
>
>
> Greg,
>
> I see a number of difficulties in the packing and unpacking,
> and filtering of DATA Payload information.  Perhaps not
> suprisingly, the MTP primitive MTP-TRANSFER does not contain
> the MTP Routing Label in the data payload.  The MTP RL is
> the MTP Level 3 Header (much like an IP header) and is not
> part of the payload transferred to an from the MTP-User.
>
> [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> contain the OPC, DPC, SLS and SIO.  The Routing Label format was used for
> the Protocol Data parameter in the Data message so that these fields are
not
> re-encoded across the SG.

Ah, but they will be.  You see the SG MTP3 must unpack the routing label to
determine whether the MSU is a management message.  By the time the MSU gets
to an MTP3-User, the routing label has likely been removed and placed into
an internal representation.  To put it back into the M3UA message would
require an MTP3 routing label encoder.  If you look at M3UA in a simple case
where it is just an MTP3-User, this is normally the case.  The MTP3-User
does not have (nor want) direct access to the L3 protocol header.

[Greg2] I really cannot say whether all MTP3 implementations separate the
routing label or not, or put it back in or not.  I don't really want to get
into how implementations will unpack SS7 message parts into internal
representations and and re-pack information into M3UA DATA messages.  I'm
sure that there are lots of possibilities.  Separating out the Routing
Label, placing into an internal representation and then re-packing using an
MTP3 Routing Label encoder is one method I guess.

>
>
>
> The MTP-TRANSFER primitive is defined in Q.701 as having the
> following parameters:
>
>         OPC (see 2.2/Q.704)
>         DPC (see 2.2/Q.704)
>         SLS (see 2.2/Q.704)
>         SIO (see 14.2/Q.704)
>         User data (see 2.3.8/Q.703)
>
> You will find the same list of parameters in Table 9/T1.112.1.
>
> In neither list is the NI (Network Indicator) or MP (Message
> Priority) listed.  This is, IMHO, because the assignment of
> these values is to be peformed by MTP and is not at the discretion
> of the MTP-User.
>
> [Greg] No, the NI and MP (national use) are shown as part of the SIO
> Subservice Field in the relevant MTP3 recommendations (Q.704 Section 14.2
or
> national equivalent).  Q.701 Table 1 (and your list above) lists the SIO
as
> a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
> details.  So IMO the SIO Subservice Field is included in the MTP-TRANSFER
> and therfore the NI and MP (national variants) are there.   I'm not sure
how
> all SS7 vendors implemented the MTP-TRANSFER primitive as it is not
visible,
> but I've always assumed that the MTP3-User assigns the Message priority.
> The NI could be picked up without the MTP3-User assigning it but I'm not
> sure that it really matters.

In further discussion on SUA, it appears that MP must be assigned by SCCP in
some cases (MTP3 is not expected to have knowledge of SCCP users) so it
should be part of the structure in some form.  I would suggest unpacking it.
NI is clearly part of the MTP-SAPID and does not need to be transferred.

[Greg2] Sorry, I must of missed this SUA thread - I'll look it up.  As for
the NI, I agree it can be picked up based on the MTP-SAPID.   In an SS7 node
this is not an issue.  In the M3UA where the MTP3-Users are remote I think
it has to be transfered - see NA response below ...

>
>
>
> In comparing this primitive to the Payload Data Message (DATA)
> in Section 3.3.1 and bearing in mind the statements of Section
> 4.1.1 with regards to MTP-Transfer, and considering IPSP operation,
> I have the following problems:
>
> When M3UA receives an MTP-TRANSFER primitive from the NIF or
> MTP-User, M3UA is required to pack a routing label into the Payload
> of a DATA message.  Because the MTP-TRANSFER primitive does not
> contain NI or MP parameters, M3UA will have to generate them.
>
> [Greg] I don't agree - see above.  IMO the NI and MP are in the
MTP-TRANSFER
> primitive.

See Al's discussion on SUA thread.

>
>
> Also, M3UA will have to choose some variant for the packing of
> the DATA Payload.  The receiving M3UA will have to unpack the
> same data to be able to generate an MTP-TRANSFER primitive to
> its MTP-User.
>
> [Greg] The M3UA at the SG doesn't really have to do any choosing of
> variants.  The format of the incoming SIO/Routing Label/User Data is
already
> packed according to the MTP3 variant and is not changed.  The M3UA at the
> receiver knows the variant used and the expectations of the format for the
> upper layer primitive to the MTP3-User instance.

With the data already unpacked from the MTP3 RL, the M3UA at the ASP need
not know the RL structure to provide the MTP-TRANSFER primitive to its
users.  Less chance for error, less parsing/building effort.

[Greg2] Might make things easier at the ASP but introduces complexity at the
SG as it is in effect "normalizing" the MTP3 variations of SIO/RL
structure/semantics into the new DATA parameters.  I may be dense but don't
see the net gain.  Other opinions?

>
>
>
> This seems ridiculous, particularly in the IPSP case, where the
> packing and unpacking is rather arbitrary.  It makes far more sense
> to pass the OPC, DPC, SLS and SIO as separate parameters of the
> DATA message and leave the User data from the MTP-TRANSFER primitive
> as the Payload Data.
>
> [Greg] The IPSP case is a little more arbitrary, as you say, but was left
> consistent with the SG/ASP case.
>
>
> You will note that MP is *not* part of the MTP-TRANSFER primitive
> and there is no need to distinguish between ITU (w/o MP), ANSI,
> and TTC approaches in the Payload Data when the proper parameters
> are added to the message.  It is the responsibility of MTP Level 3
> to determine the Message Priority of a MTP-User message and not
> the responsibility of the MTP-User.  The same is true for NI and
> it no longer becomes necessary to include a Network Appearance
> parameter at all.  (More on Network Appearance later...)
>
> [Greg] I guess we don't agree - IMO the Message priority assignment is
done
> by the MTP3-User (TTC might be an exception though).

Again, from SUA thread, SCCP must assign MP.  I don't care if it is added in
the structure.  Just don't leave it in the routing label, and no need for
differences for TTC.

>
>
> The format of the routing label, by the way, can be dependent
> upon SIO, and in some networks it is.  For example, one SIO
> value can be assigned for National ISUP (where the routing
> label is formatted using, say 24-bit point code) and another
> assigned for International ISUP (where the routing label is
> formatted using 14-bit point code).  See Q.704 (07/96) Section
> 2.2.1, last paragraph on Page 4.
>
> [Greg]  That is fine.  The current approach can handle this as the SIO and
> Routing Label formats are not changed.

But forces the work on the ASP when the SG MTP3 is already fitted with
routing label parser/generators.

>
>
> Treating the OPC, DPC, SLS and SIO as separate from the message
> is no different than placing the Affected PC in a parameter for
> the MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives.  The point
> codes should be split out with TLV parameters similar to those
> used to represent point codes in the DUNA and DAVA messages.  SLS
> and SIO will require their own parameters.  Because these
> parameters are mandatory parameters of the MTP-TRANSFER primitive,
> it may be useful to group them and place them in a single TLV
> as follows:
>
> [Greg]  Brian, this approach was considered early and had some proponents.
> But a choice was made for the current method.  The same appoach wasn't
used
> for MTP-PAUSE/RESUME/STATUS because these were generated internal to the
SG
> by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the SS7
> network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It may look
> oddto some people but I think it works.

What is the difference from extracting the PC from a TFP and putting it into
a DUNA an extracting a PC from a routing label and putting it in a DATA
message?  Sorry, but both are generated internal to the SG.

[Greg2]  IMO the PC is not extracted from an incoming TFP and put into a
DUNA.  Incoming TFPs are consumed by the MTP3.

I think this should be re-examined.  I surely didn't hear any objections to
this proposal.  Are there any objections out there?

[Greg2] Sure, lets hear from some others - is there support for the change?

>
>
>
>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |       Service Indicator       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Where now the Protocol Data would only contain MTP-User data.
>
>
> Note that I have removed the "Network Appearance" parameter.  This
> is because it is useless.  The Network Appearance parameter is based
> on the premise that it somehow defines the point code format used.
> This is not the case, as the Service Indicator Octet (and NI) must
> also be taken into consideration when determining the point code
> format.
>
> [Greg] The Network Appearance indicates the SS7 network partition (SG
> links/linksets/routes/routesets) for the messages to be sent/received at
the
> SG.  It is certainly not useless.  Within a network partition, only one
> point code format would be used.

But, an ASP cannot span multiple SPMCs, so the routing context defines the
network appearance and the network appearance is redundant.

[Greg2] An AS cannot span multiple SPMCs.  An ASP can register to receive
traffic for multiple Application Servers (with different DPC/OPCs/NIs).  Are
you saying we need to include the Routing Context instead?  Can you fill
this point out a bit - I don't see it yet.

Thanks,

   Greg

>
>
> By the same token, Network Appearance is useless in DUNA and DAVA
> messages.  There is no network indicator provided in MTP-PAUSE
> and MTP-RESUME primitives.
>
> [Greg] The alternative was to provide a Point Code Format field/parameter
> and have entries for every PC permutation.  As you say the Network
> Appearance is not passed up in MTP-PAUSE and RESUME primitives - it is
used
> in the M3UA to pass these primitives to the correct MTP3-User instances at

> the ASPs.  The Network Appearance was already used to direct the
> MTP-TRANSFER primitives to the correct instance so it was re-used instead.

Again, the ASP knows the point code format from the routing context (because
it cannot span multiple SPMCs).  The network appearance is redundant.

>
>
> On the other hand, for Q.701 7.2.6 operation with indication of
> SIF permitted in TFP/TFA messages, the Affected PC parameters of
> DUNA and DAVA need to be expanded to include the SIF bits present
> in these indications.
>
> [Greg]  This section is talking about Red Book to Blue Book link
> interworking.  Unless anyone is building an SG with links into a Red Book
> MTP network (62-octet SIF maximum) I think we can ignore this.
>
> Cheers,
>
>    Greg Sidebottom
>
>
> Actually, Network Appearance should be struck from the whole
> document.
>
> --Brian
>
> --

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 21 Jun 2001 14:22:13 -0500
To: "sigtran" <[email-masked]>
From: Al Varney <[email-masked]>
Subject: Re: Packing of DATA Payloads
Cc: [email-masked]
X-SMTP-HELO: auemail2.firewall.lucent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: auemail2.lucent.com [192.11.223.163]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Just a couple of minor comments.

At 03:41 6/21/2001 -0500, Brian F. G. Bidulock wrote:
>Greg Sidebottom wrote:                          (Thu, 21 Jun 2001 03:42:09)
>
> > I see a number of difficulties in the packing and unpacking,
> > and filtering of DATA Payload information.  Perhaps not
> > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > the MTP Routing Label in the data payload.  The MTP RL is
> > the MTP Level 3 Header (much like an IP header) and is not
> > part of the payload transferred to an from the MTP-User.

    The RL may not be part of the "user data" payload, but those fields ARE
communicated to MTP-Users via MTP-TRANSFER.  The various parameters of
MTP-TRANSFER could be in a single packed data structure (as in M3UA today)
or in an un-packed structure (the M3UA format you're advocating).

> > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> > contain the OPC, DPC, SLS and SIO.  The Routing Label format was used
for
> > the Protocol Data parameter in the Data message so that these fields 
> are not
> > re-encoded across the SG.
>
>Ah, but they will be.  You see the SG MTP3 must unpack the routing
>label to determine whether the MSU is a management message.

    "Unpack?" -- hmmm, I'd claim the SG must "examine" part of the RL.  For
incoming-from-SS7-network messages, the SG has to verify the NI/DPC fields
and (for messages where the NI/DPC identifies a local PC) internally handle
SI = 0, 1 or 2 messages, as well as SCCP SNM (SSN=0 and 1), and maybe the
SCCP based OA&M stuff(MRVT/SRVT/etc.).  But it makes sense to distribute
them (to other internal processes) just as ISUP and SCCP user messages are
distributed.  (That allows an SG to internally host some applications -- the
selection of an appropriate "SCTP association" might just pick an internal
process for some messages.)  Only when routing keys are used must the SG
look beyond SI+DPC for distribution.

> > In neither list is the NI (Network Indicator) or MP (Message
> > Priority) listed.  This is, IMHO, because the assignment of
> > these values is to be peformed by MTP and is not at the discretion
> > of the MTP-User.
> >
> > [Greg] No, the NI and MP (national use) are shown as part of the SIO
> > Subservice Field in the relevant MTP3 recommendations (Q.704 Section 
> 14.2 or
> > national equivalent).

    In ANSI networks, ISUP must assign message priorities, both to achieve
the 80%/20% IAM priority 0 scheme (for normal callers) and to offer higher
message priority to GETS/HPCC callers.  One could argue that MTP-Users don't
need to RECEIVE the MP, but they need about everything else on both send and
receive.

>Again, from SUA thread, SCCP must assign MP.  I don't care if it
>is added in the structure.  Just don't leave it in the routing
>label, and no need for differences for TTC.

    That's a reasonable argument for your approach.  Unfortunately:

> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |       Service Indicator       |

    you don't have NI or MP in separate fields here either.  Why not just
change Service Indicator to an 8-bit SIO (with NI and MP for non-TTC apps)
and use some of the remaining 8 bits for TTC needs (and spare bits).  I
think I advocated that approach last year in the TTC discussion.

> >  I think this should be re-examined.  I surely didn't hear any
>objections to this proposal.  Are there any objections out there?

    Not objecting -- just trying to fill in a few holes.  Either method
works.

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Thu, 21 Jun 2001 14:47:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Comments inline...

Greg Sidebottom wrote:                   (Thu, 21 Jun 2001 13:28:58)
> > >
> > > Greg,
> > >
> > > I see a number of difficulties in the packing and unpacking,
> > > and filtering of DATA Payload information.  Perhaps not
> > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > the MTP Routing Label in the data payload.  The MTP RL is the
> > > MTP Level 3 Header (much like an IP header) and is not part of
> > > the payload transferred to an from the MTP-User.
> > >
> > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER
> > > primitive contain the OPC, DPC, SLS and SIO.  The Routing
> > > Label format was used for the Protocol Data parameter in the
> > > Data message so that these fields are not re-encoded across
> > > the SG.
> > 
> > Ah, but they will be.  You see the SG MTP3 must unpack the
> > routing label to determine whether the MSU is a management
> > message.  By the time the MSU gets to an MTP3-User, the routing
> > label has likely been removed and placed into an internal
> > representation.  To put it back into the M3UA message would
> > require an MTP3 routing label encoder.  If you look at M3UA in a
> > simple case where it is just an MTP3-User, this is normally the
> > case.  The MTP3-User does not have (nor want) direct access to
> > the L3 protocol header.
> 
> [Greg2] I really cannot say whether all MTP3 implementations
> separate the routing label or not, or put it back in or not.  I
> don't really want to get into how implementations will unpack
> SS7 message parts into internal representations and and re-pack
> information into M3UA DATA messages.  I'm sure that there are
> lots of possibilities.  Separating out the Routing Label,
> placing into an internal representation and then re-packing
> using an MTP3 Routing Label encoder is one method I guess.

I think it is fair to say that all SG implmentations must understand each RL
format and need to unpack it for comparison against routing keys to
determine to which ASP the message is bound.  This is a normal function of
MTP Level 3.  I agree that the spec should not restrict itself to one
implementation, but it is difficult to see which implementations it supports
without discussing them.
Implementation experience is quite helpful to the process I believe.

MTP3 Routing Labels are packed in quite an unnatural format for a
little-endian machine.  Even a big-endian machine requires shifting and
masking to extract the components of the label for comparison.  An MTP3
implementation must index routing tables on the basis of these components,
and it is hard to believe that M3UA in any form is suitable for simplified
protocol conversion devices.  (The M3UA spec sees fit from previous
discussion to warn against stateless protocol conversion approaches.)

I don't think that is is a massive leap in Engineering logic or experience,
or practice to say that the MTP3 at the SG will unpack the label to peform
its functions.

> > > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > > following parameters:
> > >
> > >         OPC (see 2.2/Q.704)
> > >         DPC (see 2.2/Q.704)
> > >         SLS (see 2.2/Q.704)
> > >         SIO (see 14.2/Q.704)
> > >         User data (see 2.3.8/Q.703)
> > >
> > > You will find the same list of parameters in Table 9/T1.112.1.
> > >
> > > In neither list is the NI (Network Indicator) or MP (Message
> > > Priority) listed.  This is, IMHO, because the assignment of
> > > these values is to be peformed by MTP and is not at the
> > > discretion of the MTP-User.
> > >
> > > [Greg] No, the NI and MP (national use) are shown as part of
> > > the SIO Subservice Field in the relevant MTP3 recommendations
> > > (Q.704 Section 14.2 or national equivalent).  Q.701 Table 1
> > > (and your list above) lists the SIO as a parameter of the
> > > MTP-TRANSFER and refers to Q.704 Section 14.2 for details.  So
> > > IMO the SIO Subservice Field is included in the MTP-TRANSFER
> > > and therfore the NI and MP (national variants) are there.
> > > I'm not sure how all SS7 vendors implemented the MTP-TRANSFER
> > > primitive as it is not visible, but I've always assumed that
> > > the MTP3-User assigns the Message priority.  The NI could be
> > > picked up without the MTP3-User assigning it but I'm not sure
> > > that it really matters.
> > 
> > In further discussion on SUA, it appears that MP must be
> > assigned by SCCP in some cases (MTP3 is not expected to have
> > knowledge of SCCP users) so it should be part of the structure
> > in some form.  I would suggest unpacking it.  NI is clearly part
> > of the MTP-SAPID and does not need to be transferred.
> 
> [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.
> As for the NI, I agree it can be picked up based on the MTP-SAPID.
> In an SS7 node this is not an issue.  In the M3UA where the
> MTP3-Users are remote I think it has to be transfered - see NA
> response below ...

Network indicator has become link specific due to point-code exhausting in
some administrations.  The NI does not necessarily identify the format of a
point code.  The NI coupled with the link on which the message is received
or sent does.  Although I agree that it might be advantageous to some
network configurations to transfer the NI bits to the MTP3-User, their
interpretation must be in light of local network configuration and
administration practices.  That is why it is better to distinguish on
MTP-SAPID.
The MTP-SAPID is embodied in the Routing Context (a handle to the binding of
ASP to MTP-SAPID).

> 
> > > In comparing this primitive to the Payload Data Message (DATA)
> > > in Section 3.3.1 and bearing in mind the statements of Section
> > > 4.1.1 with regards to MTP-Transfer, and considering IPSP
> > > operation, I have the following problems:
> > >
> > > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > > MTP-User, M3UA is required to pack a routing label into the
> > > Payload of a DATA message.  Because the MTP-TRANSFER primitive
> > > does not contain NI or MP parameters, M3UA will have to
> > > generate them.
> > >
> > > [Greg] I don't agree - see above.  IMO the NI and MP are in
> > > the MTP-TRANSFER primitive.
> > 
> > See Al's discussion on SUA thread.
> > 
> > > Also, M3UA will have to choose some variant for the packing of
> > > the DATA Payload.  The receiving M3UA will have to unpack the
> > > same data to be able to generate an MTP-TRANSFER primitive to
> > > its MTP-User.
> > >
> > > [Greg] The M3UA at the SG doesn't really have to do any
> > > choosing of variants.  The format of the incoming SIO/Routing
> > > Label/User Data is already packed according to the MTP3
> > > variant and is not changed.  The M3UA at the receiver knows
> > > the variant used and the expectations of the format for the
> > > upper layer primitive to the MTP3-User instance.
> > 
> > With the data already unpacked from the MTP3 RL, the M3UA at the
> > ASP need not know the RL structure to provide the MTP-TRANSFER
> > primitive to its users.  Less chance for error, less
> > parsing/building effort.
> 
> [Greg2] Might make things easier at the ASP but introduces
> complexity at the SG as it is in effect "normalizing" the MTP3
> variations of SIO/RL structure/semantics into the new DATA
> parameters.  I may be dense but don't see the net gain.  Other
> opinions?

Normalizing the MTP3 interface is the current job of MTP Level 3 protocol
stacks which provide support for multiple point code formats and protocol
variants.  Normalizing the representation of parameters in the MTP-TRANSFER
is fascile, and a necessary part of a multiple variant implementation.

The net gain is that implementors of SGs will be able to integrate 3rd party
MTP Level 3 stacks which have already been homogomized and conformance
tested, plus implementors of ASPs will not need to understand the bit
packing of routing labels.  If the ASP is kept above the MTP3 to MTP3-User
boundary, conformance testing at Level 3 will not be necessary.  If the MTP3
functions become partitioned across SG and ASP (and encoding and decoding
MTP3 headers is one of those functions), then each permutation of SG/ASP
combination will need be conformance tested.  Half the reason for using
something like M3UA is so that a conforming SG can for the most part take
the SS7 MTP compliance worries away from an application on an ASP.

> 
> > > This seems ridiculous, particularly in the IPSP case, where
> > > the packing and unpacking is rather arbitrary.  It makes far
> > > more sense to pass the OPC, DPC, SLS and SIO as separate
> > > parameters of the DATA message and leave the User data from
> > > the MTP-TRANSFER primitive as the Payload Data.
> > >
> > > [Greg] The IPSP case is a little more arbitrary, as you say,
> > > but was left consistent with the SG/ASP case.
> > >
> > >
> > > You will note that MP is *not* part of the MTP-TRANSFER
> > > primitive and there is no need to distinguish between ITU (w/o
> > > MP), ANSI, and TTC approaches in the Payload Data when the
> > > proper parameters are added to the message.  It is the
> > > responsibility of MTP Level 3 to determine the Message
> > > Priority of a MTP-User message and not the responsibility of
> > > the MTP-User.  The same is true for NI and it no longer
> > > becomes necessary to include a Network Appearance parameter at
> > > all.  (More on Network Appearance later...)
> > >
> > > [Greg] I guess we don't agree - IMO the Message priority
> > > assignment is done by the MTP3-User (TTC might be an exception
> > > though).
> > 
> > Again, from SUA thread, SCCP must assign MP.  I don't care if it
> > is added in the structure.  Just don't leave it in the routing
> > label, and no need for differences for TTC.
> > 
> > > The format of the routing label, by the way, can be dependent
> > > upon SIO, and in some networks it is.  For example, one SIO
> > > value can be assigned for National ISUP (where the routing
> > > label is formatted using, say 24-bit point code) and another
> > > assigned for International ISUP (where the routing label is
> > > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > > 2.2.1, last paragraph on Page 4.
> > >
> > > [Greg]  That is fine.  The current approach can handle this as
> > > the SIO and Routing Label formats are not changed.
> > 
> > But forces the work on the ASP when the SG MTP3 is already
> > fitted with routing label parser/generators.
> > 
> > > Treating the OPC, DPC, SLS and SIO as separate from the
> > > message is no different than placing the Affected PC in a
> > > parameter for the MTP-PAUSE, MTP-RESUME, and MTP-STATUS
> > > primitives.  The point codes should be split out with TLV
> > > parameters similar to those used to represent point codes in
> > > the DUNA and DAVA messages.  SLS and SIO will require their
> > > own parameters.  Because these parameters are mandatory
> > > parameters of the MTP-TRANSFER primitive, it may be useful to
> > > group them and place them in a single TLV as follows:
> > >
> > > [Greg]  Brian, this approach was considered early and had some
> > > proponents.  But a choice was made for the current method.
> > > The same appoach wasn't used for MTP-PAUSE/RESUME/STATUS
> > > because these were generated internal to the SG by MTP3, as
> > > opposed to MTP-TRANSFER which came in to the SG from the SS7
> > > network already encoded (i.e., MTP3 SIO, Routing Label, ...).
> > > It may look oddto some people but I think it works.
> > 
> > What is the difference from extracting the PC from a TFP and
> > putting it into a DUNA an extracting a PC from a routing label
> > and putting it in a DATA message?  Sorry, but both are generated
> > internal to the SG.
> 
> [Greg2]  IMO the PC is not extracted from an incoming TFP and
> put into a DUNA.  Incoming TFPs are consumed by the MTP3.

Well, it is clear to me that the MTP3 RL is the first thing consumed by the
MTP3, headers need to be decoded before (or as) state machines are run.

> 
> > I think this should be re-examined.  I surely didn't hear any
> > objections to this proposal.  Are there any objections out there?
> 
> [Greg2] Sure, lets hear from some others - is there support for
> the change?
> 
> > >     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 = 28           |          Length = 24          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Originating Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Destination Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Signalling Link Selection   |       Service Indicator       |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |            Tag = 3            |             Length            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    \                                                               \
> > >    /                        Protocol Data                          /
> > >    \                                                               \
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > Where now the Protocol Data would only contain MTP-User data.
> > >
> > > Note that I have removed the "Network Appearance" parameter.
> > > This is because it is useless.  The Network Appearance
> > > parameter is based on the premise that it somehow defines the
> > > point code format used.  This is not the case, as the Service
> > > Indicator Octet (and NI) must also be taken into consideration
> > > when determining the point code format.
> > >
> > > [Greg] The Network Appearance indicates the SS7 network
> > > partition (SG links/linksets/routes/routesets) for the
> > > messages to be sent/received at the SG.  It is certainly not
> > > useless.  Within a network partition, only one point code
> > > format would be used.
> > 
> > But, an ASP cannot span multiple SPMCs, so the routing context
> > defines the network appearance and the network appearance is
> > redundant.
> 
> [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to
> receive traffic for multiple Application Servers (with different
> DPC/OPCs/NIs).  Are you saying we need to include the Routing
> Context instead?  Can you fill this point out a bit - I don't see
> it yet.

Yes.  I believe the Routing Context should be included with each message
just as is the IID in M2UA.  I also believe that it should be included in
other M3UA messages such as DUNA, DAVA, etc.  In consideration of gateway
screening at an SG, a TFA does not translate to a DAVA for all routing
contexts.  It should only send a DAVA to routing contexts to which the SG
offers a route to the affected destination.  This is the way STP's operate
today.  A switch in New Brunswick is not notified of the availability or
prohibition or restriction of a switch in Sacrameto to which it has no
trunks and no other need for a signalling route.  To do otherwise is to
broadcast the unavailability of point codes internal to a network operator's
network to the entire world (just about).
The unavailability of point codes is confidential information to the network
operator which they do not want to broadcast to interconnecting networks in
most circumstances.

With this change, it will become possible under M3UA to have AS which are
treated with different routing policies under gateway screening at the SG.

> > > By the same token, Network Appearance is useless in DUNA and
> > > DAVA messages.  There is no network indicator provided in
> > > MTP-PAUSE and MTP-RESUME primitives.
> > >
> > > [Greg] The alternative was to provide a Point Code Format
> > > field/parameter and have entries for every PC permutation.  As
> > > you say the Network Appearance is not passed up in MTP-PAUSE
> > > and RESUME primitives - it is used in the M3UA to pass these
> > > primitives to the correct MTP3-User instances at the ASPs.
> > > The Network Appearance was already used to direct the
> > > MTP-TRANSFER primitives to the correct instance so it was
> > > re-used instead.
> > 
> > Again, the ASP knows the point code format from the routing
> > context (because it cannot span multiple SPMCs).  The network
> > appearance is redundant.
> > 
> > > On the other hand, for Q.701 7.2.6 operation with indication
> > > of SIF permitted in TFP/TFA messages, the Affected PC
> > > parameters of DUNA and DAVA need to be expanded to include the
> > > SIF bits present in these indications.
> > >
> > > [Greg]  This section is talking about Red Book to Blue Book
> > > link interworking.  Unless anyone is building an SG with links
> > > into a Red Book MTP network (62-octet SIF maximum) I think we
> > > can ignore this.
> > >
> > > Cheers,
> > >
> > >    Greg Sidebottom
> > >
> > >
> > > Actually, Network Appearance should be struck from the whole
> > > document.

I would be very interested to hear other opinions, but in today's economy,
don't hold your breath! ;)

-- 
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]
Date: Thu, 21 Jun 2001 14:53:52 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Al,

Al Varney wrote:                                  (Thu, 21 Jun 2001
14:22:13)
> Just a couple of minor comments.
> 
> At 03:41 6/21/2001 -0500, Brian F. G. Bidulock wrote:
> >Greg Sidebottom wrote:                          (Thu, 21 Jun 2001
03:42:09)
> >
> > > I see a number of difficulties in the packing and unpacking,
> > > and filtering of DATA Payload information.  Perhaps not
> > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > the MTP Routing Label in the data payload.  The MTP RL is
> > > the MTP Level 3 Header (much like an IP header) and is not
> > > part of the payload transferred to an from the MTP-User.
> 
>     The RL may not be part of the "user data" payload, but those fields
ARE 
> communicated to MTP-Users via MTP-TRANSFER.  The various parameters of 
> MTP-TRANSFER could be in a single packed data structure (as in M3UA today)

> or in an un-packed structure (the M3UA format you're advocating).
> 
> > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> > > contain the OPC, DPC, SLS and SIO.  The Routing Label format was used
for
> > > the Protocol Data parameter in the Data message so that these fields
are not
> > > re-encoded across the SG.
> >
> >Ah, but they will be.  You see the SG MTP3 must unpack the routing
> >label to determine whether the MSU is a management message.
> 
>     "Unpack?" -- hmmm, I'd claim the SG must "examine" part of the RL.
For 
> incoming-from-SS7-network messages, the SG has to verify the NI/DPC fields

> and (for messages where the NI/DPC identifies a local PC) internally
handle 
> SI = 0, 1 or 2 messages, as well as SCCP SNM (SSN=0 and 1), and maybe the 
> SCCP based OA&M stuff(MRVT/SRVT/etc.).  But it makes sense to distribute 
> them (to other internal processes) just as ISUP and SCCP user messages are

> distributed.  (That allows an SG to internally host some applications -- 
> the selection of an appropriate "SCTP association" might just pick an 
> internal process for some messages.)  Only when routing keys are used must

> the SG look beyond SI+DPC for distribution.

But, Al, M3UA advocates the allocation of routing keys in both the
circumstance of static or dynamic allocation of routing contexts.
Also, you have not considering gateway screening, which must examine a lot
more at an earlier stage...

> 
> > > In neither list is the NI (Network Indicator) or MP (Message
> > > Priority) listed.  This is, IMHO, because the assignment of
> > > these values is to be peformed by MTP and is not at the discretion
> > > of the MTP-User.
> > >
> > > [Greg] No, the NI and MP (national use) are shown as part of the SIO
> > > Subservice Field in the relevant MTP3 recommendations (Q.704 Section
14.2 or
> > > national equivalent).
> 
>     In ANSI networks, ISUP must assign message priorities, both to achieve

> the 80%/20% IAM priority 0 scheme (for normal callers) and to offer higher

> message priority to GETS/HPCC callers.  One could argue that MTP-Users 
> don't need to RECEIVE the MP, but they need about everything else on both 
> send and receive.
> 
> >Again, from SUA thread, SCCP must assign MP.  I don't care if it
> >is added in the structure.  Just don't leave it in the routing
> >label, and no need for differences for TTC.
> 
>     That's a reasonable argument for your approach.  Unfortunately:
> 
> > >     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 = 28           |          Length = 24          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Originating Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Destination Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Signalling Link Selection   |       Service Indicator       |
> 
>     you don't have NI or MP in separate fields here either.  Why not just 
> change Service Indicator to an 8-bit SIO (with NI and MP for non-TTC apps)

> and use some of the remaining 8 bits for TTC needs (and spare bits).  I 
> think I advocated that approach last year in the TTC discussion.

Sounds reasonable.  Another possibility would be to unpack NI and MP fields
and avoid worrying about TTC differences altogether.

> 
> > >  I think this should be re-examined.  I surely didn't hear any
> >objections to this proposal.  Are there any objections out there?
> 
>     Not objecting -- just trying to fill in a few holes.  Either method
works.

Your comments are always welcomed. :)

-- 
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: shakila <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: bidulock <[email-masked]>
Subject: RE: MTP primitives format
Date: Sat, 2 Jun 2001 15:28:42 +0530
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

 MTP-TRANSFER is a DATA in section 3.3.1  MTP-STATUS (congestion) is a SCON
in section 3.4.4  MTP-STATUS (user part) is a DUPU in section 3.4.5
MTP-PAUSE is a DUNA in section 3.4.1
 MTP-RESUME is a DAVA in section 3.4.2

does these primitive formats also include the common headers? The affected
DPC parameter has 8 bit mask value included with that. do u agree to this?

regards
shakila

----- Original Message -----
From: "shakila" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: "bidulock" <[email-masked]>
Sent: Wednesday, June 20, 2001 5:55 AM
Subject: RE: MTP primitives format

> Thanks Brian. yes we found this approach good. when'll this be included in
> the m3ua draft?
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 12:11 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: MTP primitives format
>
>
> shakila,
>
> This is what I proposed for the MTP-TRANSFER primitive (which is
> really a DATA message in section 3.3.1).  The reason you don't
> see tag value 28 is because this proposal has not been included
> in an M3UA draft.
>
> Do you support this approach?
>
> shakila wrote:                                     (Wed, 20 Jun 2001
> 11:54:04)
> > Brian,
> >
> > This is the format of MTP-TRANSFER primitive. The parameter tag value 28
> is
> > reserved by IETF. Is this value = 23, which corresponds to Originating
> Point
> > code list? plz clarify.
> >
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |       Service Indicator       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > Also could anyone give me the format of other MTP primitives?? (STATUS,
> > RESUME, PAUSE)?
> >
> > regards
> > shakila
>
> In the M3UA 06 draft:
>
> MTP-TRANSFER is a DATA in section 3.3.1
> MTP-STATUS (congestion) is a SCON in section 3.4.4
> MTP-STATUS (user part) is a DUPU in section 3.4.5
> MTP-PAUSE is a DUNA in section 3.4.1
> MTP-RESUME is a DAVA in section 3.4.2
>
> --
> 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]
>
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Schwarzbauer Hanns Juergen <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Packing of DATA Payloads
Date: Fri, 22 Jun 2001 09:10:27 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: beamer.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

after snipping away the majority of text, see my comment below

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Thursday, June 21, 2001 9:54 PM
> To:	sigtran
> Subject:	Re: Packing of DATA Payloads
	[HJS]  ----------SNIP 
> >     "Unpack?" -- hmmm, I'd claim the SG must "examine" part of the RL.
For 
> > incoming-from-SS7-network messages, the SG has to verify the NI/DPC
fields 
> > and (for messages where the NI/DPC identifies a local PC) internally
handle 
> > SI = 0, 1 or 2 messages, as well as SCCP SNM (SSN=0 and 1), and maybe
the 
> > SCCP based OA&M stuff(MRVT/SRVT/etc.).  But it makes sense to distribute

> > them (to other internal processes) just as ISUP and SCCP user messages
are 
> > distributed.  (That allows an SG to internally host some applications --

> > the selection of an appropriate "SCTP association" might just pick an 
> > internal process for some messages.)  Only when routing keys are used
must 
> > the SG look beyond SI+DPC for distribution.
> 
> But, Al, M3UA advocates the allocation of routing keys in both the
> circumstance of static or dynamic allocation of routing contexts.
> Also, you have not considering gateway screening, which must examine
> a lot more at an earlier stage...
> 
	[HJS]  I hope I didn't miss some discussion the last weeks, but from
my understanding GATEWAY SCREENING has to do nothing at all with m3ua
protocol. It's an additional functionality of the SG that's right, but the
userparts don't know about it. I admit not knowing all about the screening
requirements set up in Telcordia's GR documents, but  [HJS]  there is no
neet at all to have this mentionned in m3ua.

	regards

	HannsJuergen 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: jndinesh <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: PROTOCOL NUMBER OF SCTP (STREAM CONTROL TRANSPORT PROTOCOL)
Date: Fri, 22 Jun 2001 20:29:06 +0800
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: smtp.convergsoft.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [203.197.163.45]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear Sir/Madam.

I have found that protocol number of SCTP is 132 from some sites. for ex
http://www.isi.edu/in-notes/iana/assignments/protocol-numbers but i didn't
found it mentioned anywhere in RFC 2960(which is for SCTP).
I have tried my best to find the same in ietf site www.ietf.com. But i could
know that rfc 1700 is the latest. In rfc 1700 nothing is mentioned about
SCTP. Can i know is the above information is true. or the RFC number where
it is mentioned???

Regards
Dinesh

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 22 Jun 2001 08:39:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hanns Juergen,

Let me build on that.

So why mention "STPs" and "transfer functions"?  These are also just
additional functions of the SG that user parts don't know about.  Why
mention "TFCs" and "TFAs" and "TFPs" which are just additional messages that
the SG generates that user parts don't know about?

--Brian

Schwarzbauer Hanns Juergen wrote:                    (Fri, 22 Jun 2001
09:10:27)
> Brian,
> 
> after snipping away the majority of text, see my comment below
> 
> > -----Original Message-----
> > From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> > Sent:	Thursday, June 21, 2001 9:54 PM
> > To:	sigtran
> > Subject:	Re: Packing of DATA Payloads
> 	[HJS]  ----------SNIP 
> > >     "Unpack?" -- hmmm, I'd claim the SG must "examine" part of the RL.
For 
> > > incoming-from-SS7-network messages, the SG has to verify the NI/DPC
fields 
> > > and (for messages where the NI/DPC identifies a local PC) internally
handle 
> > > SI = 0, 1 or 2 messages, as well as SCCP SNM (SSN=0 and 1), and maybe
the 
> > > SCCP based OA&M stuff(MRVT/SRVT/etc.).  But it makes sense to
distribute 
> > > them (to other internal processes) just as ISUP and SCCP user messages
are 
> > > distributed.  (That allows an SG to internally host some applications
-- 
> > > the selection of an appropriate "SCTP association" might just pick an 
> > > internal process for some messages.)  Only when routing keys are used
must 
> > > the SG look beyond SI+DPC for distribution.
> > 
> > But, Al, M3UA advocates the allocation of routing keys in both the
> > circumstance of static or dynamic allocation of routing contexts.
> > Also, you have not considering gateway screening, which must examine
> > a lot more at an earlier stage...
> > 
> 	[HJS]  I hope I didn't miss some discussion the last weeks, but from
my
> 	understanding GATEWAY SCREENING has to do nothing at all with m3ua
> 	protocol. It's an additional functionality of the SG that's right,
but
> 	the userparts don't know about it. I admit not knowing all about the
> 	screening requirements set up in Telcordia's GR documents, but
[HJS]
> 	there is no neet at all to have this mentionned in m3ua.
> 
> 	regards
> 
> 	HannsJuergen 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 22 Jun 2001 09:17:33 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: MTP primitives format
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

shakila,

The DATA, SCON, DUPU, DUNA and DAVA M3UA emssages include the common header.
The primitives from MTP3 to MTP3-Users do not require any of the information
from the common header.

The Mask included in DUNA and DAVA messages has rather marginal utility.  It
is unlikely that anything but an SG with the STP function would use a mask
other than 0.  IMO its only use is distinguishing between an
MTP-PAUSE/RESUME which applies to a single signalling point and one which
applies to a cluster.
Since most ASPs will likely be signalling end points, it is quite unlikely
that the cluster form would ever be sent to the ASP.  SEPs are not normally
cluster routed.  Because SEPs do not offer routing at all, I don't see a
situation where an ASP would send these messages to an SG at all (far less
with a non-zero mask).

It seems a bit of a convenience in that the ASP does not need to know the
exact format of the point code to apply the mask for cluster signals, but, I
don't know when it would ever get the mask anyway.  It is definitely not
needed in the DATA message.

--Brian

shakila wrote:                                            (Sat, 02 Jun 2001
15:28:42)
> Brian,
> 
>  MTP-TRANSFER is a DATA in section 3.3.1
>  MTP-STATUS (congestion) is a SCON in section 3.4.4
>  MTP-STATUS (user part) is a DUPU in section 3.4.5
>  MTP-PAUSE is a DUNA in section 3.4.1
>  MTP-RESUME is a DAVA in section 3.4.2
> 
> does these primitive formats also include the common headers? The affected
> DPC parameter has 8 bit mask value included with that. do u agree to this?
> 
> regards
> shakila
> 

-- 
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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Fri, 22 Jun 2001 17:14:33 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mailhost2.atea.be [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: SUA5: SG Relay Problems</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>See comments below.</FONT> </P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: vrijdag 15 juni 2001 18:46</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: SUA5: SG Relay Problems</FONT> </P>
<BR>

<P><FONT SIZE=2>Verwimp,</FONT>
</P>

<P><FONT SIZE=2>Please see comments below...</FONT> </P>

<P><FONT SIZE=2>Verwimp Gery
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp; (Fri, 15 Jun 2001 16:27:43)</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hi John, Brian,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The type of linkset between SS7 STP and SG
would have no further</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
consequences for the SCCP/SUA functions on the SG I think, but I
could</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; be missing something
(unless you want to support traffic mix</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; procedures, no, even that would be terminated
at the SG).</FONT> </P>

<P><FONT SIZE=2>Oh, boy.&nbsp; Here we go again.&nbsp; See the current
thread on M3UA</FONT> <BR><FONT SIZE=2>about STP vs SEP SGs.</FONT> </P>

<P><FONT SIZE=2>[GV] : The point is we're &quot;one layer up&quot;, and ask
the question whether the use of DUNA, DAVA, SCON and DAUD messages in SUA is
affected by this. I hope the interworking of SCCP and SUA management section
already describes in an adequate way what the concept is.</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Let's see :</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - the SS7 procedures terminate at the SG. In
this respect the ASPs</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; have to
be viewed as SCCP-users, who might receive (if they are</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; interested, that is) status notifications.
These are made via the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; DUNA,
DAVA and SCON messages, who might contain an affected point code</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; (point code status management) or an
affected point code + SSN</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
(subsystem management). The ASP receiving such messages MUST take</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; appropriate action and
stop/resume/reduce traffic towards the affected</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; destination (PC and/or SSN) or reroute via
another SG. This is indeed</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; a
minimum requirement for an SUA-end-node !</FONT> </P>

<P><FONT SIZE=2>Although it might appear from the specifications that
TFP/TFA</FONT> <BR><FONT SIZE=2>is broadcast to the world and that SSA/SSP
is also broadcast</FONT> <BR><FONT SIZE=2>to the world, in practice STPs are
provisioned in such as fashion</FONT> <BR><FONT SIZE=2>that they only
provide TFP/TFA to signalling points to which they</FONT> <BR><FONT
SIZE=2>offer a route to the affected destination.&nbsp; Also, SSA/SSP is
only</FONT> <BR><FONT SIZE=2>sent to concerned point codes which consist of
point codes to</FONT> <BR><FONT SIZE=2>which the STP offers translations
services resolving to the PC/SSN</FONT> <BR><FONT SIZE=2>of the subsystem in
question.&nbsp; These are not &quot;discovery&quot; protocols.</FONT> </P>

<P><FONT SIZE=2>[GV] : It is not meant as a &quot;discovery&quot; protocol
in SUA as well; the term &quot;concerned&quot; is crucial here.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; But, as you might know, when routing is on GT
and GT translation is</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
performed on the SG, it's the SG who has to take these actions (the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; ASP has then no idea of affected
point codes). This is also a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
restriction in SCCP management ...</FONT> </P>

<P><FONT SIZE=2>Which direction are you talking about?&nbsp; Translation
towards or</FONT> <BR><FONT SIZE=2>away from the ASP?&nbsp; It
matters.</FONT> </P>

<P><FONT SIZE=2>[GV] :</FONT>
</P>

<P><FONT SIZE=2>Towards ASP : the concept is either you</FONT> <BR><FONT
SIZE=2>- use direct routing (DPC + SSN) : the SCCP-user is considered as
being there on the SG itself (DPC = SG) from SS7 point of view, also if it
is in fact located on an AS (several ASPs), so it affects SG administration
and management procedures;</FONT></P>

<P><FONT SIZE=2>- use GT routing : the SCCP-user doesn't need to be
considered by the SG as &quot;local&quot; (but still could be). We consider
an enhanced GTT (=&gt; AMF) which results in an AS destination rather than a
SS7 destination.</FONT></P>

<P><FONT SIZE=2>Away from ASP (via SG to SS7) : you have the same
possibilities</FONT> <BR><FONT SIZE=2>- use direct routing : possibly the
DPC+SSN is taken from a previously received message. Either ASP or SG (if
ASP isn't concerned) could do the status check;</FONT></P>

<P><FONT SIZE=2>- use GT routing : results in an SS7 destination this
time.</FONT> </P>

<P><FONT SIZE=2>When GT routing is used throughout and translation is done
on the SG, neither SEP nor ASP can take action even if they would know each
other's status. They'll only take action on the SG's status.</FONT></P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Following this reasoning, the SG should always
be considered as SEP</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; from SS7
point of view, even if it is able to perform GTT. In case of</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; SUA, there's no MTP transfer
possible towards the IP-domain anyway. It</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; is an end node.</FONT> </P>

<P><FONT SIZE=2>I believe that would be too restrictive and
completely</FONT> <BR><FONT SIZE=2>rules out a group of intereresting
applications of SUA.</FONT> </P>

<P><FONT SIZE=2>[GV] : Agreed. Withdraw that.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - of course, the SG could act as SS7 STP as
well : combined STP/SG</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
(combined STP/SEP). This configuration might occur in ITU-networks,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; but in ANSI these are always
strictly separated functions. ITU doesn't</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; know about linkset types, for ANSI such
configurations would give</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
headaches and a lot of trouble :-(( Perhaps we should add some text
to</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; clarify this : instead of
STP we should use the term SRP (Signalling</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Relay Point) to avoid confusion with the
&quot;loaded&quot; STP term.</FONT> </P>

<P><FONT SIZE=2>Combined SSP/STPs have been used in ANSI networks.&nbsp;
ANSI make</FONT> <BR><FONT SIZE=2>no restrictions on the combination or
separation of functions</FONT> <BR><FONT SIZE=2>in the network above or
beyond those of ITU.&nbsp; ANSI does not</FONT> <BR><FONT SIZE=2>define link
set types either.&nbsp; It is a common practice to refer</FONT> <BR><FONT
SIZE=2>to the functional set of messages which must be supported by</FONT>
<BR><FONT SIZE=2>a linkset within a reference network architecture.</FONT>
</P>

<P><FONT SIZE=2>[GV] : GR-246-CORE does ?</FONT> </P>

<P><FONT SIZE=2>Because a SRP must be able to relay on the equivalent of
PC/SSN</FONT> <BR><FONT SIZE=2>(which is an SCCP SAP Id) it must also be
able to transfer to</FONT> <BR><FONT SIZE=2>a PC other than its own which,
by definition means that it has</FONT> <BR><FONT SIZE=2>the transfer
function and is an STP.&nbsp; Also, to perform the</FONT> <BR><FONT
SIZE=2>relay function requires that the relay point be equipped with</FONT>
<BR><FONT SIZE=2>an MTP transfer function to permit both coupled and
decoupled</FONT> <BR><FONT SIZE=2>operation in connection oriented and
connectionless classes.</FONT> </P>

<P><FONT SIZE=2>[GV] : The suggestion is then to also enable AMF for SS7
point codes ?</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - I haven't seen anything like a C-link
between a mated pair of SGs,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
not even in M3UA ?</FONT> </P>

<P><FONT SIZE=2>It is an oversight in their diagram which I have brought
to</FONT> <BR><FONT SIZE=2>Greg's attention.</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Brian : for SLS selection :</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - SUA at the ASP selects an appropriate SCTP
stream ID (possibly based</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; on
information given by the SUA-user),</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; - the SG (let's say the NIF) maps the received
stream ID onto an SLS.</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; To
assure an even distribution other information can be taken into</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; account as well : network
appearance, DPC, ... whatever does not</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; compromise in-sequence-delivery.</FONT> </P>

<P><FONT SIZE=2>And must also know the availability of routes at MTP3 via
each</FONT> <BR><FONT SIZE=2>SG to be able to determine where to send the
message.&nbsp; The SLS</FONT> <BR><FONT SIZE=2>value itself (and the rules
for generating it) also determine</FONT> <BR><FONT SIZE=2>the SG which must
be used for routing.&nbsp; It cannot be constrained</FONT> <BR><FONT
SIZE=2>in class 0 an 2 operation to the SG through which the initial</FONT>
<BR><FONT SIZE=2>transaction or CR came.</FONT> </P>

<P><FONT SIZE=2>[GV] : For connections, we need however coupling of
connection sections in the SG if the CR crosses the SS7 - IP boundary.
Unless you want to extend the MTP network into the IP network (and go ahead
with point codes).</FONT></P>

<P><FONT SIZE=2>The current position is to keep a clean separation at the
SG. The ASP and SUA management should be sufficient.</FONT> </P>

<P><FONT SIZE=2>br,</FONT>
</P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
From: [email-masked]
Subject: Re: Packing of DATA Payloads
To: "sigtran" <[email-masked]>
Date: Fri, 22 Jun 2001 11:42:12 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 06/22/2001 11:42:13 AM
X-SMTP-HELO: dnsmx2pya.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnsmx2pya.telcordia.com [128.96.20.32]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Folks,

I apologize for not following this conversation, but mention of the word
screening reminded me of a new function in ANSI MTP3 that may need to be
considered for possible implication on the SG.  In the 2000 version of ANSI
MTP3, new procedures were added to the message discrimination function for
STPs to examine the OPC of received messages and comparing it with its own
point code and the point code of its mate (see T1.111.4 Section 2.4).  This
functionality was added to the MTP for security reasons (e.g.,  to prevent
nodes or networks interconnected to the STP from mimicking the STP).  So if
the SG is supporting MTP3 according to the 2000 ANSI specification
(specifically supporting the procedures in T1.111.4 Section 2.4 ) would
there be any implication on the SS7 and IP interworking?

Regards
Ray

"Brian F. G. Bidulock" <[email-masked]> on 06/22/2001 09:39:34 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Ray P.
Singh/Telcordia)
Subject:  Re: Packing of DATA Payloads

Hanns Juergen,

Let me build on that.

So why mention "STPs" and "transfer functions"?  These are also just
additional functions of the SG that user parts don't know about.  Why
mention "TFCs" and "TFAs" and "TFPs" which are just additional messages that
the SG generates that user parts don't know about?

--Brian

Schwarzbauer Hanns Juergen wrote:                    (Fri, 22 Jun 2001
09:10:27)
> Brian,
>
> after snipping away the majority of text, see my comment below
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [SMTP:[email-masked]]
> > Sent: Thursday, June 21, 2001 9:54 PM
> > To:   sigtran
> > Subject:   Re: Packing of DATA Payloads
>    [HJS]  ----------SNIP
> > >     "Unpack?" -- hmmm, I'd claim the SG must "examine" part of the RL.
For
> > > incoming-from-SS7-network messages, the SG has to verify the NI/DPC
fields
> > > and (for messages where the NI/DPC identifies a local PC) internally
handle
> > > SI = 0, 1 or 2 messages, as well as SCCP SNM (SSN=0 and 1), and maybe
the
> > > SCCP based OA&M stuff(MRVT/SRVT/etc.).  But it makes sense to
distribute
> > > them (to other internal processes) just as ISUP and SCCP user messages
are
> > > distributed.  (That allows an SG to internally host some applications
--
> > > the selection of an appropriate "SCTP association" might just pick an
> > > internal process for some messages.)  Only when routing keys are used
must
> > > the SG look beyond SI+DPC for distribution.
> >
> > But, Al, M3UA advocates the allocation of routing keys in both the
> > circumstance of static or dynamic allocation of routing contexts.
> > Also, you have not considering gateway screening, which must examine
> > a lot more at an earlier stage...
> >
>    [HJS]  I hope I didn't miss some discussion the last weeks, but from my
>    understanding GATEWAY SCREENING has to do nothing at all with m3ua
>    protocol. It's an additional functionality of the SG that's right, but
>    the userparts don't know about it. I admit not knowing all about the
>    screening requirements set up in Telcordia's GR documents, but  [HJS]
>    there is no neet at all to have this mentionned in m3ua.
>
>    regards
>
>    HannsJuergen
>
>
> ---
> 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/

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Herve Pellan <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA: IPSP - IPSP configuration
Date: Fri, 22 Jun 2001 17:52:27 +0200
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: bbnrel4.net.external.hp.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: bbnrel4.hp.com [155.208.254.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,
it is unclear to me whether M3UA procedures described in section 5.0 applies
to the EP-EP model in both directions or if the configuration is dissymetric
? In other words, does one of the End Point plays exclusively the role of
the SG or does each of the EP plays at some point in time the role of a SG ?
For example, are ASP-Up messages sent in each direction ?
Can someone clarify ?
Thanks,
Herve Pellan

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Fri, 22 Jun 2001 09:45:37 -0700
To: "sigtran" <[email-masked]>
From: Lyndon Ong <[email-masked]>
Subject: Re: PROTOCOL NUMBER OF SCTP (STREAM CONTROL TRANSPORT PROTOCOL)
X-SMTP-HELO: avocet.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [207.217.121.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-flowed>Dinesh,

132 is the correct number.  The most up-to-date listing can be found at
IANA's website (www.iana.org) under Protocol Number Assignment Services.
RFC1700 is out of date, as the website notes.

Cheers,

L. Ong

At 08:29 PM 6/22/2001 +0800, you wrote:
>Dear Sir/Madam.
>
>I have found that protocol number of SCTP is 132 from some sites. for ex
>http://www.isi.edu/in-notes/iana/assignments/protocol-numbers
>but i didn't found it mentioned anywhere in RFC 2960(which is for SCTP).
>I have tried my best to find the same in ietf site www.ietf.com. But i
could
>know that rfc 1700 is the latest. In rfc 1700 nothing is mentioned about
>SCTP. Can i know is the above information is true. or the RFC number where
>it is mentioned???
>
>Regards
>Dinesh
>
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Fri, 22 Jun 2001 13:09:37 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ray,

I don't think that will cause any problems for M3UA.  We were actually just
discussing some of the things that the SG must do anyway.  I was saying that
the RL will be unpacked by MTP3, Al, I believe, was saying that the RL
contents just need to be "examined".  The difference between unpacking and
examining is probably just a philosophical difference on many processors.

--Brian

[email-masked] wrote:                                (Fri, 22 Jun 2001
11:42:12)
> 
> Folks,
> 
> I apologize for not following this conversation, but mention of the word
> screening reminded me of a new function in ANSI MTP3 that may need to be
> considered for possible implication on the SG.  In the 2000 version of
ANSI
> MTP3, new procedures were added to the message discrimination function for
> STPs to examine the OPC of received messages and comparing it with its own
> point code and the point code of its mate (see T1.111.4 Section 2.4).
This
> functionality was added to the MTP for security reasons (e.g.,  to prevent
> nodes or networks interconnected to the STP from mimicking the STP).  So
if
> the SG is supporting MTP3 according to the 2000 ANSI specification
> (specifically supporting the procedures in T1.111.4 Section 2.4 ) would
> there be any implication on the SS7 and IP interworking?
> 
> Regards
> Ray
> 

-- 
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]
Date: Fri, 22 Jun 2001 14:10:32 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-42-216.dallas.net [209.44.42.216]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

Please see additional discussion below...

Verwimp Gery wrote:                     (Fri, 22 Jun 2001 17:14:33)

[snip snipage]
>    
> > >
> > > But, as you might know, when routing is on GT and GT
> > > translation is performed on the SG, it's the SG who has to
> > > take these actions (the ASP has then no idea of affected point
> > > codes). This is also a restriction in SCCP management ...
> >    
> > Which direction are you talking about?  Translation towards or
> > away from the ASP?  It matters.
> >    
> [GV] :
>    
> Towards ASP : the concept is either you
> - use direct routing (DPC + SSN) : the SCCP-user is considered as
> being there on the SG itself (DPC = SG) from SS7 point of view,
> also if it is in fact located on an AS (several ASPs), so it
> affects SG administration and management procedures;

There's the rub: you can't have two SG's acting as STPs with the same point
code (your "DPC = SG" above).  Your only option to keep the SCCP users
"local" is to have them running as mated subsystems.
In that case the SUA messages whould model the N-Primitives rather than the
SCCP messages and significant reworking of SUA is required.

>    
> - use GT routing : the SCCP-user doesn't need to be considered by
> the SG as "local" (but still could be). We consider an enhanced
> GTT (=> AMF) which results in an AS destination rather than a SS7
> destination.

Possible, but unlikely for PSTN.  It is more likely that final GTT has
already been performed.  I don't think anyone is going to want to
administrate 10-digit GTT for LNP in their SGs when the STPs are already
equipped to handle this.  Nevertheless, where you have multiple SGs acting
as STPs, you cannot couple at the SG for class 0 and 2 operation.  The
necessity to support the above for subsequent messages is the greater issue.

>    
> Away from ASP (via SG to SS7) : you have the same possibilities
> - use direct routing : possibly the DPC+SSN is taken from a
> previously received message. Either ASP or SG (if ASP isn't
> concerned) could do the status check;

For class 0 and class 2 operation, the SG which is chosen in the multiple
SG-STP arrangement must be based on proper SLS selection for proper SS7
loadsharing over the STP sides of the SG-STP.  To properly perform this
loadsharing which is required within the SS7 network, the ASP must know the
state of routesets on each SG.  This includes not just subsystem
availability, but point code availability, congestions, and restriction.

>    
> - use GT routing : results in an SS7 destination this time.

Again, it is unlikely that the GTT will be performed at the SG.  It will
likely be peformed by a primary STP in the SS7 network.
Nevertheless, this is not the problematic case. (The one above is.)

>    
> When GT routing is used throughout and translation is done on the
> SG, neither SEP nor ASP can take action even if they would know
> each other's status. They'll only take action on the SG's status.

Well, you see, routing is never done on DPC+SSN.  It is done on DPC at the
MTP3 level.  It is only once the message reaches the destination that the
SCCP subsystem at the desination is invoked.

For the SCCP to send a message using MTP3 services, it must be cognisant of
the status of the DPC based on MTP-STATUS, MTP-RESUME and MTP-PAUSE
primitives (not to mention restart).  In the case where the ASP is selecting
from one of two SG-STP, it is performing an MTP3 routing function.  Either
SUA at the ASP must performs MTP3 routing, or it must no connect to multiple
SGs in a "non-local" MTP-User fashion.

How the ASP and SG are seen by the network (as implied by what type of
signalling links they are connected with) is rather germaine to this
discussion.

If it is the intention of SUA to only support subsystems which are
considered "local" to the SG, then there is no need for coupling, no need
for GTT or AMF at the SG, and SUA should be modeled after the N-Primitives
at the SCCP-to-User interface rather than SCCP peer-to-peer messages.

Also, because only N-Primitives are supported, an ISO NSP would suffice.

[snip]
> > > - of course, the SG could act as SS7 STP as well : combined
> > > STP/SG (combined STP/SEP). This configuration might occur in
> > > ITU-networks, but in ANSI these are always strictly separated
> > > functions. ITU doesn't know about linkset types, for ANSI such
> > > configurations would give headaches and a lot of trouble:-((
> > > Perhaps we should add some text to clarify this : instead of
> > > STP we should use the term SRP (Signalling Relay Point) to
> > > avoid confusion with the "loaded" STP term.
> >    
> > Combined SSP/STPs have been used in ANSI networks.  ANSI make no
> > restrictions on the combination or separation of functions in
> > the network above or beyond those of ITU.  ANSI does not define
> > link set types either.  It is a common practice to refer to the
> > functional set of messages which must be supported by a linkset
> > within a reference network architecture.
>    
> [GV] : GR-246-CORE does ?

Many ASNI networks choose not to completely adopt Telcordia generic
requirements.

> > Because a SRP must be able to relay on the equivalent of PC/SSN
> > (which is an SCCP SAP Id) it must also be able to transfer to a
> > PC other than its own which, by definition means that it has the
> > transfer function and is an STP.  Also, to perform the relay
> > function requires that the relay point be equipped with an MTP
> > transfer function to permit both coupled and decoupled operation
> > in connection oriented and connectionless classes.
> >    
> [GV] : The suggestion is then to also enable AMF for SS7 point
> codes ?
>    
Well, although it might be obvious (but not mentioned in SUA at all) that
MTP-PAUSE/RESUME primitives at the SG from MTP3 must be communicated to the
ASP with N-PCSTATE primitives (I presume in DUNA and DAVA although they are
only listed as being used for the equivalent of SSP and SSA management
messages); when multiple SG's are involved which contain the transfer
function, the SG must also make known the situation regarding route
restriction in network which support transfer restricted procedures.  There
is no SUA messaging for this, and it is "layer down".

> > >
> > > - I haven't seen anything like a C-link between a mated pair
> > > of SGs, not even in M3UA ?
> >    
> > It is an oversight in their diagram which I have brought to
> > Greg's attention.
> >    
Greg tells me that C-links are being added to the diagram.

> > >
> > > Brian : for SLS selection :
> > >
> > > - SUA at the ASP selects an appropriate SCTP stream ID
> > > (possibly based on information given by the SUA-user), - the
> > > SG (let's say the NIF) maps the received stream ID onto an
> > > SLS.  To assure an even distribution other information can be
> > > taken into account as well : network appearance, DPC, ...
> > > whatever does not compromise in-sequence-delivery.
> >    
> > And must also know the availability of routes at MTP3 via each
> > SG to be able to determine where to send the message.  The SLS
> > value itself (and the rules for generating it) also determine
> > the SG which must be used for routing.  It cannot be constrained
> > in class 0 an 2 operation to the SG through which the initial
> > transaction or CR came.
> >    
> [GV] : For connections, we need however coupling of connection
> sections in the SG if the CR crosses the SS7 - IP boundary.
> Unless you want to extend the MTP network into the IP network (and
> go ahead with point codes).

You cannot get away with multiple SG's connected to the SS7 network with
B/D-links and supporting the transfer function (implicit in the link type)
and perform coupling at a single SG for protocol classes 0 and 2!  Also, you
cannot get coupling unless you also do SCCP translation and routing at the
SG.

>    
> The current position is to keep a clean separation at the SG.
> The ASP and SUA management should be sufficient.
>    

This is sufficient to rule out final GTT occuring in the SS7 network and
protocol class 0 and 2 operation.  If the SUA stops here, SUA has been
scoped down to supporting SCCP connectionless class 1 and SCCP
connection-oriented class 3 only with a requirement for performing SCCP
translation at the SG, and no support for multiple SGs (multiple SGs must
have the same point code and are therefore really SGPs).  The SG must be
precluded from acting as an STP in the SS7 network and can only be allowed
to support local SCCP users.

I think that would be far too restrictive an application of SUA, so the
protocol elements must be put in place to permit the interworking of SUA at
MTP Level 3 in the SG.  Otherwise, M3UA will be the only UA which is capable
of fully supporting SCCP.

I am rather disappointed and concerned that SUA-06 does not address any of
these relay problems, yet adds an AMF function which is of little practical
use.

-- 
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: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA06: Flow control
Date: Sat, 23 Jun 2001 19:42:28 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hebe.or.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: jffdns02.or.intel.com [134.134.248.4]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,
 
I have a query on Section 1.4.5 Flow control which says -

 "Local Management at an ASP may wish to stop traffic across an SCTP
association in order to temporarily remove the association from service or
to perform testing and maintenance activity.  The function could optionally
be used to control the start of traffic on to a newly available SCTP
association."
 
 - My understanding of the above text is: ASP will remain in its current 
   state but is locally inhibited for outgoing traffic. 
   How the incoming traffic is to be handled at ASP in this case?
 
Regards
Nitin

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA06: DRST message.
Date: Sat, 23 Jun 2001 19:48:31 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rumor.cps.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: rumor.cps.intel.com [192.102.198.242]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,
 
 I have few queries/comments on DRST message of M3UA draft 06:

1. Section 3.4.6 
  "The M3UA at the ASP is expected to send traffic to the affected
destination via an alternate SG 
     of equal priority, but only if such an alternate route exists and is
available", 
  
 -  Does this mean M3UA at ASP need to maintain the priority of the route
among the SGs, 
    if yes, on what basis?

2. Section 1.3.2.4
  "Providing an indication to MTP3-Users at an ASP that the routes to a 
   remote MTP3-User peer in the SS7 network are restricted"

-  What possible use an MTP3-User can make out from knowing that the
destination is 
   restricted? I think this text is not required in the draft.

3. Greg, When can we expect M3UA draft 07?

Regards
Nitin.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Kevin Stephen <[email-masked]>
Subject: Get Cash Fast!
To: "sigtran" <[email-masked]>
Date: Sun, 24 Jun 2001 01:26:05 -0700
X-Mailer: diffondi V4,0,1,0 (W95/NT) (Build: Feb 20 2001)
X-SMTP-HELO: mail01.refl.com.hk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [210.177.172.193]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

We will help you get the mortgage loan you want!

Whether a new home loan is what you seek or to refinance your current home
loan at a lower interest rate, we can help!

Mortgage rates haven't been this low in the last 12 months, take action now!

Refinance your home with us and include all of those pesky credit card bills
or use the extra cash for that pool you've always wanted...

Where others say NO, we say YES!!!
Even if you have been turned down elsewhere, we can help!

Easy terms!  Our mortgage referral service combines the highest quality
loans with the most economical rates and the easiest qualifications!

Take just 2 minutes to complete the following form.
There is no obligation, all information is kept strictly confidential, and
you must be at least 18 years of age.  
Service is available within the United States only.
This service is fast and free.  

Free information request form:
PLEASE VISIT
www.webbprofit.com

**************************************************************** Since you
have received this message you have either responded to one of our offers in
the past or your address has been registered with us.  If you wish to be
removed please reply to: mailto:[email-masked]?subject=remove
****************************************************************

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gerstenfeld, Yisrael" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SIGTRAN Implementers list?
Date: Mon, 25 Jun 2001 15:45:11 +0300
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: ismailout.icomverse.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.118.48.253]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Can anyone tell me whether a SIGTRAN implementers list exists? I'm looking
for information about real world SIGTRAN deployments - which protocol
options have proven to be successful, which have been problematic, etc.
Also, I'd like to get a feel of what considerations are involved in choosing
a specific protocol for a proposed deployment, as a function of network
characteristics, application characteristics, or whatever.

Regards,

Jeff Gerstenfeld
Systems Engineer, Signaling Group
Comverse
Tel:  +972-3-645-2460
      +972-58-54-2460
Fax: +972-3-645-8915
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Mon, 25 Jun 2001 15:02:48 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades6.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [194.78.143.126]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: SUA5: SG Relay Problems</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Brian,</FONT>
</P>

<P><FONT SIZE=2>A few comments :</FONT> </P>

<P><FONT SIZE=2>1. Mapping of SUA primitives</FONT> </P>

<P><FONT SIZE=2>Some of them can be seen as SUA peer-to-peer messages
exclusively (ASP management messages), others as either N_primitives or
peer-to-peer, depending on the SS7 interworking scenario :</FONT></P>

<P><FONT SIZE=2>=&gt; N_primitives : SCCP-user local to SG (route on
DPC+SSN, final GTT has occurred previously)</FONT> <BR><FONT SIZE=2>=&gt;
peer-to-peer : SG as STP (route on GT, (possibly final) GTT occurs in
SG)</FONT> <BR><FONT SIZE=2>=&gt; peer-to-peer : the all-IP case.</FONT>
</P>

<P><FONT SIZE=2>2. Now to the restrictions you seem to see, comments below
!</FONT> </P>

<P><FONT SIZE=2>____________________________</FONT> </P>

<P><FONT SIZE=2>Gery Verwimp</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS ATEA</FONT> <BR><FONT SIZE=2>&gt; ICN D CS
D5</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tel. : +32 14 25 3424</FONT> <BR><FONT SIZE=2>Fax :
+32 14 25 3212</FONT> <BR><FONT SIZE=2><A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>____________________________________</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: vrijdag 22 juni 2001 21:11</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: Re: SUA5: SG Relay Problems</FONT> </P>
<BR>

<P><FONT SIZE=2>Verwimp,</FONT>
</P>

<P><FONT SIZE=2>Please see additional discussion below...</FONT> </P>

<P><FONT SIZE=2>Verwimp Gery
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Fri, 22 Jun 2001
17:14:33)</FONT> </P>

<P><FONT SIZE=2>[snip snipage]</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt;
&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; But, as you might know, when routing is on
GT and GT</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt; translation is performed on
the SG, it's the SG who has to</FONT> <BR><FONT SIZE=2>&gt; &gt; &gt; take
these actions (the ASP has then no idea of affected point</FONT> <BR><FONT
SIZE=2>&gt; &gt; &gt; codes). This is also a restriction in SCCP management
...</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt; &gt; Which direction are you talking about?&nbsp; Translation
towards or</FONT> <BR><FONT SIZE=2>&gt; &gt; away from the ASP?&nbsp; It
matters.</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; [GV] :</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
Towards ASP : the concept is either you</FONT> <BR><FONT SIZE=2>&gt; - use
direct routing (DPC + SSN) : the SCCP-user is considered as</FONT> <BR><FONT
SIZE=2>&gt; being there on the SG itself (DPC = SG) from SS7 point of
view,</FONT> <BR><FONT SIZE=2>&gt; also if it is in fact located on an AS
(several ASPs), so it</FONT> <BR><FONT SIZE=2>&gt; affects SG administration
and management procedures;</FONT> </P>

<P><FONT SIZE=2>There's the rub: you can't have two SG's acting as STPs with
the</FONT> <BR><FONT SIZE=2>same point code (your &quot;DPC = SG&quot;
above).&nbsp; Your only option to keep</FONT> <BR><FONT SIZE=2>the SCCP
users &quot;local&quot; is to have them running as mated subsystems.</FONT>
<BR><FONT SIZE=2>In that case the SUA messages whould model the N-Primitives
rather</FONT> <BR><FONT SIZE=2>than the SCCP messages and significant
reworking of SUA is required.</FONT> </P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>[GV2] : You can't have it bothways. Either you are the
&quot;end-system&quot;, possibly selected from a mated subsystem pair during
the final GTT in the previous STP. From the moment the SG is selected, ALL
messages concerning the same TCAP transaction or SCCP connection will go
to/via this SG. That's the whole point, when routing on DPC+SSN in the SS7
network, you route towards an SG, NOT to an ASP/AS via different possible
SGs. If you like to see it otherwise, you use M3UA. It is not the intention
to copy MTP3/M3UA functionality in SUA ... that would be re-inventing the
wheel :-o True, the SG is single point of failure for the active
transactions/connections passed to him, but there's no difference with
current SS7 standings (if the entire end-system fails, sorry, but your
active TCAP transactions and SCCP connections are lost as well
then).</FONT></P>

<P><FONT SIZE=2>Or either you are an SCCP-relay point (SG as STP, and GTT
occurs at the SG !!!). Connectionless traffic can continue using either SG
from the mated pair, but :</FONT></P>

<P><FONT SIZE=2>- the same ASP should be selected for messages belonging to
the same TCAP transaction (this is a can of worms we haven't dug into yet;
the best way would be to give each ASP a unique E.164 number, which can be
returned to the originating SEP)</FONT></P>

<P><FONT SIZE=2>- the in-sequence-delivery feature will lead to routing the
messages via the same SG under normal conditions</FONT> <BR><FONT SIZE=2>-
for connection-oriented, see further.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FON
T> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; - use
GT routing : the SCCP-user doesn't need to be considered by</FONT> <BR><FONT
SIZE=2>&gt; the SG as &quot;local&quot; (but still could be). We consider an
enhanced</FONT> <BR><FONT SIZE=2>&gt; GTT (=&gt; AMF) which results in an AS
destination rather than a SS7</FONT> <BR><FONT SIZE=2>&gt;
destination.</FONT> </P>

<P><FONT SIZE=2>Possible, but unlikely for PSTN.&nbsp; It is more likely
that final GTT</FONT> <BR><FONT SIZE=2>has already been performed.&nbsp; I
don't think anyone is going to want</FONT> <BR><FONT SIZE=2>to administrate
10-digit GTT for LNP in their SGs when the STPs are</FONT> <BR><FONT
SIZE=2>already equipped to handle this.&nbsp; Nevertheless, where you
have</FONT> <BR><FONT SIZE=2>multiple SGs acting as STPs, you cannot couple
at the SG for class 0</FONT> <BR><FONT SIZE=2>and 2 operation.&nbsp; The
necessity to support the above for subsequent</FONT> <BR><FONT
SIZE=2>messages is the greater issue.</FONT> </P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FON
T> <BR><FONT SIZE=2>[GV2] : There's a mixup in your argument here. First of
all, if you want an integrated STP/SG/LNP : no problem ! Second, the
LNP-access by SCCP (SRF method) in an STP yields a routing number, to be
considered as the new GT. There's no link between doing LNP and having a
final GTT as well in the same STP ...</FONT></P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<
/FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; Away
from ASP (via SG to SS7) : you have the same possibilities</FONT> <BR><FONT
SIZE=2>&gt; - use direct routing : possibly the DPC+SSN is taken from
a</FONT> <BR><FONT SIZE=2>&gt; previously received message. Either ASP or SG
(if ASP isn't</FONT> <BR><FONT SIZE=2>&gt; concerned) could do the status
check;</FONT> </P>

<P><FONT SIZE=2>For class 0 and class 2 operation, the SG which is chosen in
the</FONT> <BR><FONT SIZE=2>multiple SG-STP arrangement must be based on
proper SLS selection</FONT> <BR><FONT SIZE=2>for proper SS7 loadsharing over
the STP sides of the SG-STP.&nbsp; To</FONT> <BR><FONT SIZE=2>properly
perform this loadsharing which is required within the SS7</FONT> <BR><FONT
SIZE=2>network, the ASP must know the state of routesets on each SG.&nbsp;
This</FONT> <BR><FONT SIZE=2>includes not just subsystem availability, but
point code</FONT> <BR><FONT SIZE=2>availability, congestions, and
restriction.</FONT> </P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;&gt;</FONT> <BR><FONT SIZE=2>[GV2] : Yes, and this is done at the SG. The
ASP gets informed of subsystem/pointcode availability and congestion, via
the SSNM messages, as modelled by the N_State primitives.</FONT></P>

<P><FONT SIZE=2>At the ASP, the SG can be modelled as a group of SGP's,
which service the interworking with SS7 for a certain SS7 routing key. It
actually doesn't even matter whether the SGPs belong to the same or a
different &quot;host&quot;, SGPs are considered &quot;hosts&quot; on their
own. It is between these SGPs the ASP has to choose, for a certain RK, using
ASP and SUA management procedures to keep it's statuses up to date and
keeping in mind the in-sequence-delivery requirement. The ASP does not
select an SLS straight ahead (not part of SUA messages) !!!</FONT></P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; - use
GT routing : results in an SS7 destination this time.</FONT> </P>

<P><FONT SIZE=2>Again, it is unlikely that the GTT will be performed at the
SG.&nbsp; It</FONT> <BR><FONT SIZE=2>will likely be peformed by a primary
STP in the SS7 network.</FONT> <BR><FONT SIZE=2>Nevertheless, this is not
the problematic case. (The one above is.)</FONT> </P>

<P><FONT SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>[GV2] : The degree of unlikeliness is subject to debate. In
next generation GSM networks (UMTS), there is nothing but GTT, especially at
the SG (core network, roaming-SG between NGN based on IP and traditional
PLMN). And in ITU-T networks, when you cross a border, you have to use
GTT.</FONT></P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; When GT
routing is used throughout and translation is done on the</FONT> <BR><FONT
SIZE=2>&gt; SG, neither SEP nor ASP can take action even if they would
know</FONT> <BR><FONT SIZE=2>&gt; each other's status. They'll only take
action on the SG's status.</FONT> </P>

<P><FONT SIZE=2>Well, you see, routing is never done on DPC+SSN.&nbsp; It is
done on DPC</FONT> <BR><FONT SIZE=2>at the MTP3 level.&nbsp; It is only once
the message reaches the</FONT> <BR><FONT SIZE=2>destination that the SCCP
subsystem at the desination is invoked.</FONT> </P>

<P><FONT SIZE=2>For the SCCP to send a message using MTP3 services, it must
be</FONT> <BR><FONT SIZE=2>cognisant of the status of the DPC based on
MTP-STATUS, MTP-RESUME</FONT> <BR><FONT SIZE=2>and MTP-PAUSE primitives (not
to mention restart).&nbsp; In the case</FONT> <BR><FONT SIZE=2>where the ASP
is selecting from one of two SG-STP, it is performing</FONT> <BR><FONT
SIZE=2>an MTP3 routing function.&nbsp; Either SUA at the ASP must performs
MTP3</FONT> <BR><FONT SIZE=2>routing, or it must no connect to multiple SGs
in a &quot;non-local&quot;</FONT> <BR><FONT SIZE=2>MTP-User fashion.</FONT>
</P>

<P><FONT SIZE=2>How the ASP and SG are seen by the network (as implied by
what type</FONT> <BR><FONT SIZE=2>of signalling links they are connected
with) is rather germaine to</FONT> <BR><FONT SIZE=2>this discussion.</FONT>
</P>

<P><FONT SIZE=2>If it is the intention of SUA to only support subsystems
which are</FONT> <BR><FONT SIZE=2>considered &quot;local&quot; to the SG,
then there is no need for coupling, no</FONT> <BR><FONT SIZE=2>need for GTT
or AMF at the SG, and SUA should be modeled after the</FONT> <BR><FONT
SIZE=2>N-Primitives at the SCCP-to-User interface rather than SCCP</FONT>
<BR><FONT SIZE=2>peer-to-peer messages.</FONT> </P>

<P><FONT SIZE=2>Also, because only N-Primitives are supported, an ISO NSP
would</FONT> <BR><FONT SIZE=2>suffice.</FONT>
</P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>[GV2] : I guess you're in love with MTP3 routing ;-) No,
seriously, the SG is what it is : a gateway between 2 worlds. MTP3 stops
there, the message is handed over to SCCP, and via interworking, passed to
SUA.</FONT></P>

<P><FONT SIZE=2>There is need for GTT/AMF in SCCP/SUA, as there is need for
coupling of connection sections (as a network border is crossed). ISO NSP is
a model, not a working protocol ...</FONT></P>

<P><FONT SIZE=2>Besides I'm a little bit confused about which scenario
you're having trouble with : is it the DPC+SSN (&quot;local to SG&quot;) or
GTT case ? You're argument seems to be &quot;well, GTT is not going to be
used, so let's skip GTT/AMF in the SG etc.&quot; and finally you end up with
an unusable SUA because it doesn't support MTP3 routing features
??</FONT></P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>You cannot get away with multiple SG's connected to the SS7
network</FONT> <BR><FONT SIZE=2>with B/D-links and supporting the transfer
function (implicit in the</FONT> <BR><FONT SIZE=2>link type) and perform
coupling at a single SG for protocol classes</FONT> <BR><FONT SIZE=2>0 and
2!&nbsp; Also, you cannot get coupling unless you also do SCCP</FONT>
<BR><FONT SIZE=2>translation and routing at the SG.</FONT> </P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;</FONT> <BR><FONT SIZE=2>[GV2] : see comments above.</FONT> <BR><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; The
current position is to keep a clean separation at the SG.</FONT> <BR><FONT
SIZE=2>&gt; The ASP and SUA management should be sufficient.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>This is sufficient to rule out final GTT occuring in the SS7
network</FONT> <BR><FONT SIZE=2>and protocol class 0 and 2 operation.&nbsp;
If the SUA stops here, SUA</FONT> <BR><FONT SIZE=2>has been scoped down to
supporting SCCP connectionless class 1 and</FONT> <BR><FONT SIZE=2>SCCP
connection-oriented class 3 only with a requirement for</FONT> <BR><FONT
SIZE=2>performing SCCP translation at the SG, and no support for
multiple</FONT> <BR><FONT SIZE=2>SGs (multiple SGs must have the same point
code and are therefore</FONT> <BR><FONT SIZE=2>really SGPs).&nbsp; The SG
must be precluded from acting as an STP in the</FONT> <BR><FONT SIZE=2>SS7
network and can only be allowed to support local SCCP users.</FONT> </P>

<P><FONT SIZE=2>I think that would be far too restrictive an application of
SUA, so</FONT> <BR><FONT SIZE=2>the protocol elements must be put in place
to permit the</FONT> <BR><FONT SIZE=2>interworking of SUA at MTP Level 3 in
the SG.&nbsp; Otherwise, M3UA will</FONT> <BR><FONT SIZE=2>be the only UA
which is capable of fully supporting SCCP.</FONT> </P>

<P><FONT SIZE=2>I am rather disappointed and concerned that SUA-06 does not
address</FONT> <BR><FONT SIZE=2>any of these relay problems, yet adds an AMF
function which is of</FONT> <BR><FONT SIZE=2>little practical use.</FONT>
</P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;&gt;</FONT> <BR><FONT SIZE=2>[GV2] : Although the SUA-06 text might not
be &quot;a-point&quot; yet, some final remarks :</FONT> </P>

<P><FONT SIZE=2>- the SG is part of the SS7 network. Final or non-final GTT
can occur at the SG, or might have occurred in the previous STP. In the
latter case, the SG is the end-node.</FONT></P>

<P><FONT SIZE=2>- I fail to see the limitations. The SG must support not
only GTT, but accounting, screening etc.etc. Since we're talking about SCCP
messages, and these functions are performed on SCCP parameters, it's handled
at the SCCP layer (not the MTP3, this one has already done it's job and
handed the message to SCCP, NOT to SUA ...</FONT></P>

<P><FONT
SIZE=2>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&
gt;&gt;</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/"
TARGET="_blank">http://www.openss7.org/</A></FONT> </P>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>To unsubscribe send a
blank email to [email-masked]</FONT> </P>

---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY>
</HTML>

</x-html>
Date: Mon, 25 Jun 2001 00:56:59 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Flow control
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: falcon.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: falcon.mail.pas.earthlink.net [207.217.120.74]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin,

I would think that because "Management Blocking" is one of the reasons for
the ASPDN message in 3.5.3 that the ASP would not necessarily remain in its
current state.

--Brian

Tomar, Nitin wrote:                             (Sat, 23 Jun 2001 19:42:28)
> Hi All,
>  
> I have a query on Section 1.4.5 Flow control which says -
> 
>  "Local Management at an ASP may wish to stop traffic across an SCTP
> association in order to temporarily remove the association from service or
> to perform testing and maintenance activity.  The function could
optionally
> be used to control the start of traffic on to a newly available SCTP
> association."
>  
>  - My understanding of the above text is: ASP will remain in its current 
>    state but is locally inhibited for outgoing traffic. 
>    How the incoming traffic is to be handled at ASP in this case?
>  
> Regards
> Nitin
> 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 25 Jun 2001 01:14:27 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: DRST message.
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: scaup.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: scaup.mail.pas.earthlink.net [207.217.121.49]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Nitin,

Tomar, Nitin wrote:                    (Sat, 23 Jun 2001 19:48:31)
> Hi All,
>  
>  I have few queries/comments on DRST message of M3UA draft 06:
> 
> 1. Section 3.4.6 
>   "The M3UA at the ASP is expected to send traffic to the affected
> destination via an alternate SG 
>      of equal priority, but only if such an alternate route exists and is
> available", 
>   
>  -  Does this mean M3UA at ASP need to maintain the priority of the route
> among the SGs, 
>     if yes, on what basis?

MTP Level 3 normally maintains the priority of various routes via available
linksets on a static configuration basis.  That is, each route within a
route set is assigned a priority at configuration time.  I would expect that
the M3UA at the ASP faced with multiple routes within a routeset would need
each route to be provisioned also with a static priority within the route
set.

Short answer: the ASP knows the priority based on local configuration data
at the ASP.

> 
> 2. Section 1.3.2.4
>   "Providing an indication to MTP3-Users at an ASP that the routes to a 
>    remote MTP3-User peer in the SS7 network are restricted"
> 
> -  What possible use an MTP3-User can make out from knowing that the
> destination is 
>    restricted? I think this text is not required in the draft.

This text appears to have been added between M3UA-05 and M3UA-06.
I don't know why it was put into M3UA-06; however, I completely agree that
it is not required.  There is no mechanism for M3UA to inform an MTP3-User
of restriction, and the MTP3-User is not equipped to deal with it.  It
appears to be a case of someone just assuming that restriction was similar
to prohibition and congestion.
I agree: the text should be removed.
> 
> 3. Greg, When can we expect M3UA draft 07?
> 

I too am interested in the answer to this question.

-- 
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]
Date: Mon, 25 Jun 2001 11:38:28 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: albatross.prod.itd.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: albatross.mail.pas.earthlink.net [207.217.120.120]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

Your are still missing the point.  The SGs must be viewed from the SS7
network as either SPs (with different point codes) or STPs (with different
point codes).  The constraint in SUA that all transactions and connections
must be "coupled" rules out the SS7 network viewing the SGs as STPs.  This
leaves you will two choices:

1)  Use only a single SG with no STP function (and no
    GTT towards the ASP as far as the SS7 network is
    concerned).

2)  Use multiple SGs, but each has its own point code, does
    not perform a relay function, and has no GTT as far as
    the SS7 network is concerned towards the ASP, and can
    only be replicated susbstems as far as the SS7 network
    is concerned.

This is a very limited scenario.  I believe that SUA should permit a wider
range of solutions at the SG than merely making SGs act as SEPs.

Also, this restricted arrangement is far from seamless.

--Brian

Verwimp Gery wrote:                            (Mon, 25 Jun 2001 15:02:48)
> 
>    Brian,
> 
>    A few comments :
> 
>    1. Mapping of SUA primitives
> 
>    Some of them can be seen as SUA peer-to-peer messages exclusively (ASP
>    management messages), others as either N_primitives or peer-to-peer,
>    depending on the SS7 interworking scenario :
> 
>    => N_primitives : SCCP-user local to SG (route on DPC+SSN, final GTT
>    has occurred previously)
>    => peer-to-peer : SG as STP (route on GT, (possibly final) GTT occurs
>    in SG)
>    => peer-to-peer : the all-IP case.
> 
>    2. Now to the restrictions you seem to see, comments below !
> 
>    ____________________________
> 
>    Gery Verwimp
>    > SIEMENS ATEA
>    > ICN D CS D5
>    >
>    > Tel. : +32 14 25 3424
>    Fax : +32 14 25 3212
>    [1]mailto:[email-masked]
>    ____________________________________
> 
>    -----Original Message-----
>    From: Brian F. G. Bidulock [[2]mailto:[email-masked]]
>    Sent: vrijdag 22 juni 2001 21:11
>    To: sigtran
>    Subject: Re: SUA5: SG Relay Problems
> 
>    Verwimp,
> 
>    Please see additional discussion below...
> 
>    Verwimp Gery wrote:                     (Fri, 22 Jun 2001 17:14:33)
> 
>    [snip snipage]
>    >
>    > > >
>    > > > But, as you might know, when routing is on GT and GT
>    > > > translation is performed on the SG, it's the SG who has to
>    > > > take these actions (the ASP has then no idea of affected point
>    > > > codes). This is also a restriction in SCCP management ...
>    > >
>    > > Which direction are you talking about?  Translation towards or
>    > > away from the ASP?  It matters.
>    > >
>    > [GV] :
>    >
>    > Towards ASP : the concept is either you
>    > - use direct routing (DPC + SSN) : the SCCP-user is considered as
>    > being there on the SG itself (DPC = SG) from SS7 point of view,
>    > also if it is in fact located on an AS (several ASPs), so it
>    > affects SG administration and management procedures;
> 
>    There's the rub: you can't have two SG's acting as STPs with the
>    same point code (your "DPC = SG" above).  Your only option to keep
>    the SCCP users "local" is to have them running as mated subsystems.
>    In that case the SUA messages whould model the N-Primitives rather
>    than the SCCP messages and significant reworking of SUA is required.
> 
>    >>>>>>>>>>>>>>>
>    [GV2] : You can't have it bothways. Either you are the "end-system",
>    possibly selected from a mated subsystem pair during the final GTT in
>    the previous STP. From the moment the SG is selected, ALL messages
>    concerning the same TCAP transaction or SCCP connection will go to/via
>    this SG. That's the whole point, when routing on DPC+SSN in the SS7
>    network, you route towards an SG, NOT to an ASP/AS via different
>    possible SGs. If you like to see it otherwise, you use M3UA. It is not
>    the intention to copy MTP3/M3UA functionality in SUA ... that would be
>    re-inventing the wheel :-o True, the SG is single point of failure for
>    the active transactions/connections passed to him, but there's no
>    difference with current SS7 standings (if the entire end-system fails,
>    sorry, but your active TCAP transactions and SCCP connections are lost
>    as well then).
> 
>    Or either you are an SCCP-relay point (SG as STP, and GTT occurs at
>    the SG !!!). Connectionless traffic can continue using either SG from
>    the mated pair, but :
> 
>    - the same ASP should be selected for messages belonging to the same
>    TCAP transaction (this is a can of worms we haven't dug into yet; the
>    best way would be to give each ASP a unique E.164 number, which can be
>    returned to the originating SEP)
> 
>    - the in-sequence-delivery feature will lead to routing the messages
>    via the same SG under normal conditions
>    - for connection-oriented, see further.
>    >>>>>>>>>>>>>>>>
> 
>    >
>    > - use GT routing : the SCCP-user doesn't need to be considered by
>    > the SG as "local" (but still could be). We consider an enhanced
>    > GTT (=> AMF) which results in an AS destination rather than a SS7
>    > destination.
> 
>    Possible, but unlikely for PSTN.  It is more likely that final GTT
>    has already been performed.  I don't think anyone is going to want
>    to administrate 10-digit GTT for LNP in their SGs when the STPs are
>    already equipped to handle this.  Nevertheless, where you have
>    multiple SGs acting as STPs, you cannot couple at the SG for class 0
>    and 2 operation.  The necessity to support the above for subsequent
>    messages is the greater issue.
> 
>    >>>>>>>>>>>>>>>>
>    [GV2] : There's a mixup in your argument here. First of all, if you
>    want an integrated STP/SG/LNP : no problem ! Second, the LNP-access by
>    SCCP (SRF method) in an STP yields a routing number, to be considered
>    as the new GT. There's no link between doing LNP and having a final
>    GTT as well in the same STP ...
> 
>    >>>>>>>>>>>>>>>>>
> 
>    >
>    > Away from ASP (via SG to SS7) : you have the same possibilities
>    > - use direct routing : possibly the DPC+SSN is taken from a
>    > previously received message. Either ASP or SG (if ASP isn't
>    > concerned) could do the status check;
> 
>    For class 0 and class 2 operation, the SG which is chosen in the
>    multiple SG-STP arrangement must be based on proper SLS selection
>    for proper SS7 loadsharing over the STP sides of the SG-STP.  To
>    properly perform this loadsharing which is required within the SS7
>    network, the ASP must know the state of routesets on each SG.  This
>    includes not just subsystem availability, but point code
>    availability, congestions, and restriction.
> 
>    >>>>>>>>>>>>>>>>>>>
>    [GV2] : Yes, and this is done at the SG. The ASP gets informed of
>    subsystem/pointcode availability and congestion, via the SSNM
>    messages, as modelled by the N_State primitives.
> 
>    At the ASP, the SG can be modelled as a group of SGP's, which service
>    the interworking with SS7 for a certain SS7 routing key. It actually
>    doesn't even matter whether the SGPs belong to the same or a different
>    "host", SGPs are considered "hosts" on their own. It is between these
>    SGPs the ASP has to choose, for a certain RK, using ASP and SUA
>    management procedures to keep it's statuses up to date and keeping in
>    mind the in-sequence-delivery requirement. The ASP does not select an
>    SLS straight ahead (not part of SUA messages) !!!
> 
>    >>>>>>>>>>>>>>>>>>
> 
>    >
>    > - use GT routing : results in an SS7 destination this time.
> 
>    Again, it is unlikely that the GTT will be performed at the SG.  It
>    will likely be peformed by a primary STP in the SS7 network.
>    Nevertheless, this is not the problematic case. (The one above is.)
> 
>    >>>>>>>>>>>>>
>    [GV2] : The degree of unlikeliness is subject to debate. In next
>    generation GSM networks (UMTS), there is nothing but GTT, especially
>    at the SG (core network, roaming-SG between NGN based on IP and
>    traditional PLMN). And in ITU-T networks, when you cross a border, you
>    have to use GTT.
> 
>    >>>>>>>>>>>>>>
> 
>    >
>    > When GT routing is used throughout and translation is done on the
>    > SG, neither SEP nor ASP can take action even if they would know
>    > each other's status. They'll only take action on the SG's status.
> 
>    Well, you see, routing is never done on DPC+SSN.  It is done on DPC
>    at the MTP3 level.  It is only once the message reaches the
>    destination that the SCCP subsystem at the desination is invoked.
> 
>    For the SCCP to send a message using MTP3 services, it must be
>    cognisant of the status of the DPC based on MTP-STATUS, MTP-RESUME
>    and MTP-PAUSE primitives (not to mention restart).  In the case
>    where the ASP is selecting from one of two SG-STP, it is performing
>    an MTP3 routing function.  Either SUA at the ASP must performs MTP3
>    routing, or it must no connect to multiple SGs in a "non-local"
>    MTP-User fashion.
> 
>    How the ASP and SG are seen by the network (as implied by what type
>    of signalling links they are connected with) is rather germaine to
>    this discussion.
> 
>    If it is the intention of SUA to only support subsystems which are
>    considered "local" to the SG, then there is no need for coupling, no
>    need for GTT or AMF at the SG, and SUA should be modeled after the
>    N-Primitives at the SCCP-to-User interface rather than SCCP
>    peer-to-peer messages.
> 
>    Also, because only N-Primitives are supported, an ISO NSP would
>    suffice.
> 
>    >>>>>>>>>>>>>>>
>    [GV2] : I guess you're in love with MTP3 routing ;-) No, seriously,
>    the SG is what it is : a gateway between 2 worlds. MTP3 stops there,
>    the message is handed over to SCCP, and via interworking, passed to
>    SUA.
> 
>    There is need for GTT/AMF in SCCP/SUA, as there is need for coupling
>    of connection sections (as a network border is crossed). ISO NSP is a
>    model, not a working protocol ...
> 
>    Besides I'm a little bit confused about which scenario you're having
>    trouble with : is it the DPC+SSN ("local to SG") or GTT case ? You're
>    argument seems to be "well, GTT is not going to be used, so let's skip
>    GTT/AMF in the SG etc." and finally you end up with an unusable SUA
>    because it doesn't support MTP3 routing features ??
> 
>    >>>>>>>>>>>>>>>
> 
>    >
> 
>    You cannot get away with multiple SG's connected to the SS7 network
>    with B/D-links and supporting the transfer function (implicit in the
>    link type) and perform coupling at a single SG for protocol classes
>    0 and 2!  Also, you cannot get coupling unless you also do SCCP
>    translation and routing at the SG.
> 
>    >>>>>>>>>>>>>>>>>>
>    [GV2] : see comments above.
>    >>>>>>>>>>>>>>>>>>
> 
>    >
>    > The current position is to keep a clean separation at the SG.
>    > The ASP and SUA management should be sufficient.
>    >
> 
>    This is sufficient to rule out final GTT occuring in the SS7 network
>    and protocol class 0 and 2 operation.  If the SUA stops here, SUA
>    has been scoped down to supporting SCCP connectionless class 1 and
>    SCCP connection-oriented class 3 only with a requirement for
>    performing SCCP translation at the SG, and no support for multiple
>    SGs (multiple SGs must have the same point code and are therefore
>    really SGPs).  The SG must be precluded from acting as an STP in the
>    SS7 network and can only be allowed to support local SCCP users.
> 
>    I think that would be far too restrictive an application of SUA, so
>    the protocol elements must be put in place to permit the
>    interworking of SUA at MTP Level 3 in the SG.  Otherwise, M3UA will
>    be the only UA which is capable of fully supporting SCCP.
> 
>    I am rather disappointed and concerned that SUA-06 does not address
>    any of these relay problems, yet adds an AMF function which is of
>    little practical use.
> 
>    >>>>>>>>>>>>>>>>>>>
>    [GV2] : Although the SUA-06 text might not be "a-point" yet, some
>    final remarks :
> 
>    - the SG is part of the SS7 network. Final or non-final GTT can occur
>    at the SG, or might have occurred in the previous STP. In the latter
>    case, the SG is the end-node.
> 
>    - I fail to see the limitations. The SG must support not only GTT, but
>    accounting, screening etc.etc. Since we're talking about SCCP
>    messages, and these functions are performed on SCCP parameters, it's
>    handled at the SCCP layer (not the MTP3, this one has already done
>    it's job and handed the message to SCCP, NOT to SUA ...
> 
>    >>>>>>>>>>>>>>>>>>>
> 
>    --
>    Brian F. G. Bidulock
>    [email-masked]
>    [3]http://www.openss7.org/
> 
>    ---
>    You are currently subscribed to sigtran as:
>    [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
>    ---
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
> 
> References
> 
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. http://www.openss7.org/

-- 
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: "Lane, Sheila" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SS7
Date: Mon, 25 Jun 2001 10:57:14 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: postman.nlc.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: postman.nlc.com [209.204.132.16]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Patrick,

You requested information on our SS7 stack back on May 8th.  I sent an email
to you requesting additional information so that I could prepare an NDA and
get the technical documentation to you.  I did not get a response to my
email.  We would like to provide our documentation to you but need to have
an NDA in place.  Please let me know if your are still interested in our SS7
documentation; if so, I will need your company name, address, telephone and
fax numbers.

Thank you,
Sheila Lane
Next Level Communications
Telenetworks Products Group
[email-masked]
Tel:  707-584-6687
Fax:  707-584-6199

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 25 Jun 2001 15:55:05 -0700 (PDT)
From: Jonathan Wood <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [Tsvwg] sctpsocket: Returning unsent messages
To: "sigtran" <[email-masked]>
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
X-SMTP-HELO: mercury.Sun.COM
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mercury.Sun.COM [192.9.25.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

>
>With all that said, I think it is a fair statement to warn the user
>of the SCTP retrieval mechanism in the draft that some messages
>retrieved may have already been accepted by the peer app.  It also
>makes sense that, if retrieved messages are passed as ancillary data
>in recvmsg, that the retrieved data be marked with the assigned SSN
>(if any) and whether the DATA chunks was from your categories (1),
>(2) and (3) with an attribute in the ancillary data.  Retrieval

Brian,

I like this idea. Since I've just snipped lots of text, I'll recap:

When an association closes (gracefully or non-gracefully), and the caller
has enabled SCTP_SEND_FAILED events, the contents of the SCTP transmit queue
will be returned to the caller. Section 5.3.1.4 defines the following flags
for each returned message:

    SCTP_DATA_INQUEUE - When this flag is indicated the
                        data was never attempted to be
                        sent. I.e. it was never assigned
                        a TSN and sent onto the wire.

    SCTP_DATA_INTMIT  - When this flag is indicated the
                        data WAS assigned a TSN and sent
                        at least once but never acknowleged.

[ what does INTMIT stand for? ]

We should also add a third flag:

    SCTP_DATA_SACKED  - When this flag is indicated the
                        data WAS assigned a TSN and sent
                        at least once and was acknowleged
                        in a gap report, but the cumulative
                        TSN never passed it.

Sound OK?

Jonathan

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 25 Jun 2001 20:14:06 -0700 (PDT)
From: Kacheong Poon <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [Tsvwg] sctpsocket: Returning unsent messages
To: "sigtran" <[email-masked]>
Cc: [email-masked]
X-SMTP-HELO: saturn.sun.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: saturn.Sun.COM [192.9.25.2]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

> When an association closes (gracefully or non-gracefully),
> and the caller has enabled SCTP_SEND_FAILED events, the contents
> of the SCTP transmit queue will be returned to the caller. Section
> 5.3.1.4 defines the following flags for each returned message:
> 
>     SCTP_DATA_INQUEUE - When this flag is indicated the
>                         data was never attempted to be
>                         sent. I.e. it was never assigned
>                         a TSN and sent onto the wire.

Now looking at it, it seems that it is simpler to just say "the data has
never been sent."  "Attempted to be sent" can be confusing.  And
SCTP_DATA_INQUEUE may be confusing as data should be in the transmit queue
whether it has been sent or not.  Maybe we should change it to
SCTP_DATA_UNSENT?

>     SCTP_DATA_INTMIT  - When this flag is indicated the
>                         data WAS assigned a TSN and sent
>                         at least once but never acknowleged.
> 
> [ what does INTMIT stand for? ]

We proabably want to avoid using TSN in the API draft because apps do not
need to care about TSN.  In section 7.3, TSN is also mentioned.
I think we should remove that.

> We should also add a third flag:
> 
>     SCTP_DATA_SACKED  - When this flag is indicated the
>                         data WAS assigned a TSN and sent
>                         at least once and was acknowleged
>                         in a gap report, but the cumulative
>                         TSN never passed it.

Maybe Brian or other people familiar with the sigtran protocols can comment
on this.  Do we really need to separate the sack'ed but not cumulatively
ack'ed case?  The reason I ask is that the receiver is free to discard
sack'ed but not cumulatively ack'ed data chunks.  And I believe it is better
not talk about TSN in the API draft.  It seems to me that making this
distinction is not that useful.  I maybe wrong.  I suggest we should include
them both as SCTP_DATA_SENT?  This has a easier to understand semantics for
app programmers without the need to understand SCTP fully.

							K. Poon.
							[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 26 Jun 2001 10:48:39 +0100
From: Joyce Archibald <[email-masked]>
Organization: Agilent Technologies UK Ltd
X-Mailer: Mozilla 4.76 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
X-SMTP-HELO: msgbas1t.cos.agilent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: msgbas1tx.cos.agilent.com [192.6.9.34]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

I would like to register an objection to the current proposals on the
grounds that they would make it impossible to perform network monitoring.

In the case of multiple networks it is essential that the DATA message
should contain some indication of the network id and the pointcode format
(i.e. 14-bit, 16-bit or 24-bit). We expected to be able to get this
information from the Network Appearance parameter and the Routing Label
itself. We cannot use the Routing Context because we cannot know which
routing key it refers to, since the Registration Request/Response may have
taken place before monitoring was started and in any case it would be
impractical to maintain a complete list of all Routing Contexts on the
network.

If you are going to remove Network Appearance, you need to replace it with
something other than the Routing Context. I believe network/format
indicators on all pointcodes has already been considered and rejected.
Any other ideas?

Earlier this year Normand Glaude wrote:

> 
> Joyce,
> 
> Yes, you are correct in saying that the purpose of the Network Appearance
is to
> define the format and network indicator and protocol variant used within
the SS7
> network partition. However, in light of the later definitions, the concept
of
> "network partitioning" comes into play. So the question is: What is a
Network
> Partition?
> 
> This is what I'm trying to address.  More specifically, in the event that
an
> SG represents two end nodes in the same network, how can an ASP
distinguish  which
> end-node a DUNA pertains to? By defining a network appearance as the
appearance of a
> node in a network, this ambiguity is no longer there.
> 
> Greg/John, how about this as a definition?
> 
> Network Appearance - The Network Appearance uniquely identifies an SS7
entity (point
> code) into a SS7 network, as presented by the SG.  It is used for the
purposes of
> logically separating the signaling traffic between the SG and the
Application Server
> Processes over a common SCTP Association.  This partitioning is necessary
where an
> SG is logically partitioned to appear as an end-node elements in multiple
separate
> SS7 networks, in which case there is a separate network appearance for
each point
> code in the SS7 networks. It is also necessary when an SG is configured as
an STP
> hosting multiple point codes, or when configured as multiple endnodes
within the
> same network, in which case each point code is a separate network
appearance.
> Norm

This definition has now been adopted by SUA-06. Is there some reason why it
doesn't apply to M3UA?

In the light of this definition may I suggest again:

> Would it help to define the format of Network Appearance, maybe:-
>
>     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 = 1            |        Length = 8             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Network Id.   |         End node Id (or pointcode)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The End node Id could optionally be zero if the Network Appearance
> applied to the whole SS7 network.

Please see further comments inline...

"Brian F. G. Bidulock" wrote:
> 
> Greg,
> 
> Comments inline...
> 
> Greg Sidebottom wrote:                   (Thu, 21 Jun 2001 13:28:58)
> > > >
> > > > Greg,
> > > >
> > > > I see a number of difficulties in the packing and unpacking,
> > > > and filtering of DATA Payload information.  Perhaps not
> > > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > > the MTP Routing Label in the data payload.  The MTP RL is the
> > > > MTP Level 3 Header (much like an IP header) and is not part of
> > > > the payload transferred to an from the MTP-User.
> > > >
> > > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER
> > > > primitive contain the OPC, DPC, SLS and SIO.  The Routing
> > > > Label format was used for the Protocol Data parameter in the
> > > > Data message so that these fields are not re-encoded across
> > > > the SG.
> > >
> > > Ah, but they will be.  You see the SG MTP3 must unpack the
> > > routing label to determine whether the MSU is a management
> > > message.  By the time the MSU gets to an MTP3-User, the routing
> > > label has likely been removed and placed into an internal
> > > representation.  To put it back into the M3UA message would
> > > require an MTP3 routing label encoder.  If you look at M3UA in a
> > > simple case where it is just an MTP3-User, this is normally the
> > > case.  The MTP3-User does not have (nor want) direct access to
> > > the L3 protocol header.
> >
> > [Greg2] I really cannot say whether all MTP3 implementations
> > separate the routing label or not, or put it back in or not.  I
> > don't really want to get into how implementations will unpack
> > SS7 message parts into internal representations and and re-pack
> > information into M3UA DATA messages.  I'm sure that there are
> > lots of possibilities.  Separating out the Routing Label,
> > placing into an internal representation and then re-packing
> > using an MTP3 Routing Label encoder is one method I guess.
> 
> I think it is fair to say that all SG implmentations must understand
> each RL format and need to unpack it for comparison against routing
> keys to determine to which ASP the message is bound.  This is a
> normal function of MTP Level 3.  I agree that the spec should not
> restrict itself to one implementation, but it is difficult to see
> which implementations it supports without discussing them.
> Implementation experience is quite helpful to the process I believe.
> 
> MTP3 Routing Labels are packed in quite an unnatural format for
> a little-endian machine.  Even a big-endian machine requires
> shifting and masking to extract the components of the label for
> comparison.  An MTP3 implementation must index routing tables on
> the basis of these components, and it is hard to believe that
> M3UA in any form is suitable for simplified protocol conversion
> devices.  (The M3UA spec sees fit from previous discussion to
> warn against stateless protocol conversion approaches.)
> 
> I don't think that is is a massive leap in Engineering logic or
> experience, or practice to say that the MTP3 at the SG will unpack
> the label to peform its functions.
> 
> > > > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > > > following parameters:
> > > >
> > > >         OPC (see 2.2/Q.704)
> > > >         DPC (see 2.2/Q.704)
> > > >         SLS (see 2.2/Q.704)
> > > >         SIO (see 14.2/Q.704)
> > > >         User data (see 2.3.8/Q.703)
> > > >
> > > > You will find the same list of parameters in Table 9/T1.112.1.
> > > >
> > > > In neither list is the NI (Network Indicator) or MP (Message
> > > > Priority) listed.  This is, IMHO, because the assignment of
> > > > these values is to be peformed by MTP and is not at the
> > > > discretion of the MTP-User.
> > > >
> > > > [Greg] No, the NI and MP (national use) are shown as part of
> > > > the SIO Subservice Field in the relevant MTP3 recommendations
> > > > (Q.704 Section 14.2 or national equivalent).  Q.701 Table 1
> > > > (and your list above) lists the SIO as a parameter of the
> > > > MTP-TRANSFER and refers to Q.704 Section 14.2 for details.  So
> > > > IMO the SIO Subservice Field is included in the MTP-TRANSFER
> > > > and therfore the NI and MP (national variants) are there.
> > > > I'm not sure how all SS7 vendors implemented the MTP-TRANSFER
> > > > primitive as it is not visible, but I've always assumed that
> > > > the MTP3-User assigns the Message priority.  The NI could be
> > > > picked up without the MTP3-User assigning it but I'm not sure
> > > > that it really matters.
> > >
> > > In further discussion on SUA, it appears that MP must be
> > > assigned by SCCP in some cases (MTP3 is not expected to have
> > > knowledge of SCCP users) so it should be part of the structure
> > > in some form.  I would suggest unpacking it.  NI is clearly part
> > > of the MTP-SAPID and does not need to be transferred.
> >
> > [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.
> > As for the NI, I agree it can be picked up based on the MTP-SAPID.
> > In an SS7 node this is not an issue.  In the M3UA where the
> > MTP3-Users are remote I think it has to be transfered - see NA
> > response below ...
> 
> Network indicator has become link specific due to point-code
> exhausting in some administrations.  The NI does not necessarily
> identify the format of a point code.  The NI coupled with the link
> on which the message is received or sent does.  Although I agree
> that it might be advantageous to some network configurations to
> transfer the NI bits to the MTP3-User, their interpretation must
> be in light of local network configuration and administration
> practices.  That is why it is better to distinguish on MTP-SAPID.
> The MTP-SAPID is embodied in the Routing Context (a handle to the
> binding of ASP to MTP-SAPID).
> 

I have no objection to replacing the Routing Label with a mandatory header.
The NI bits are not needed if the Network Appearance parameter is present to
indicate different pointcode formats.

> >
> > > > In comparing this primitive to the Payload Data Message (DATA)
> > > > in Section 3.3.1 and bearing in mind the statements of Section
> > > > 4.1.1 with regards to MTP-Transfer, and considering IPSP
> > > > operation, I have the following problems:
> > > >
> > > > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > > > MTP-User, M3UA is required to pack a routing label into the
> > > > Payload of a DATA message.  Because the MTP-TRANSFER primitive
> > > > does not contain NI or MP parameters, M3UA will have to
> > > > generate them.
> > > >
> > > > [Greg] I don't agree - see above.  IMO the NI and MP are in
> > > > the MTP-TRANSFER primitive.
> > >
> > > See Al's discussion on SUA thread.
> > >
> > > > Also, M3UA will have to choose some variant for the packing of
> > > > the DATA Payload.  The receiving M3UA will have to unpack the
> > > > same data to be able to generate an MTP-TRANSFER primitive to
> > > > its MTP-User.
> > > >
> > > > [Greg] The M3UA at the SG doesn't really have to do any
> > > > choosing of variants.  The format of the incoming SIO/Routing
> > > > Label/User Data is already packed according to the MTP3
> > > > variant and is not changed.  The M3UA at the receiver knows
> > > > the variant used and the expectations of the format for the
> > > > upper layer primitive to the MTP3-User instance.
> > >
> > > With the data already unpacked from the MTP3 RL, the M3UA at the
> > > ASP need not know the RL structure to provide the MTP-TRANSFER
> > > primitive to its users.  Less chance for error, less
> > > parsing/building effort.
> >
> > [Greg2] Might make things easier at the ASP but introduces
> > complexity at the SG as it is in effect "normalizing" the MTP3
> > variations of SIO/RL structure/semantics into the new DATA
> > parameters.  I may be dense but don't see the net gain.  Other
> > opinions?
> 
> Normalizing the MTP3 interface is the current job of MTP Level 3
> protocol stacks which provide support for multiple point code
> formats and protocol variants.  Normalizing the representation of
> parameters in the MTP-TRANSFER is fascile, and a necessary part
> of a multiple variant implementation.
> 
> The net gain is that implementors of SGs will be able to integrate
> 3rd party MTP Level 3 stacks which have already been homogomized
> and conformance tested, plus implementors of ASPs will not need
> to understand the bit packing of routing labels.  If the ASP is
> kept above the MTP3 to MTP3-User boundary, conformance testing
> at Level 3 will not be necessary.  If the MTP3 functions become
> partitioned across SG and ASP (and encoding and decoding MTP3
> headers is one of those functions), then each permutation of
> SG/ASP combination will need be conformance tested.  Half the
> reason for using something like M3UA is so that a conforming SG
> can for the most part take the SS7 MTP compliance worries away from
> an application on an ASP.
> 
> >
> > > > This seems ridiculous, particularly in the IPSP case, where
> > > > the packing and unpacking is rather arbitrary.  It makes far
> > > > more sense to pass the OPC, DPC, SLS and SIO as separate
> > > > parameters of the DATA message and leave the User data from
> > > > the MTP-TRANSFER primitive as the Payload Data.
> > > >
> > > > [Greg] The IPSP case is a little more arbitrary, as you say,
> > > > but was left consistent with the SG/ASP case.
> > > >
> > > >
> > > > You will note that MP is *not* part of the MTP-TRANSFER
> > > > primitive and there is no need to distinguish between ITU (w/o
> > > > MP), ANSI, and TTC approaches in the Payload Data when the
> > > > proper parameters are added to the message.  It is the
> > > > responsibility of MTP Level 3 to determine the Message
> > > > Priority of a MTP-User message and not the responsibility of
> > > > the MTP-User.  The same is true for NI and it no longer
> > > > becomes necessary to include a Network Appearance parameter at
> > > > all.  (More on Network Appearance later...)
> > > >
> > > > [Greg] I guess we don't agree - IMO the Message priority
> > > > assignment is done by the MTP3-User (TTC might be an exception
> > > > though).
> > >
> > > Again, from SUA thread, SCCP must assign MP.  I don't care if it
> > > is added in the structure.  Just don't leave it in the routing
> > > label, and no need for differences for TTC.
> > >
> > > > The format of the routing label, by the way, can be dependent
> > > > upon SIO, and in some networks it is.  For example, one SIO
> > > > value can be assigned for National ISUP (where the routing
> > > > label is formatted using, say 24-bit point code) and another
> > > > assigned for International ISUP (where the routing label is
> > > > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > > > 2.2.1, last paragraph on Page 4.
> > > >
> > > > [Greg]  That is fine.  The current approach can handle this as
> > > > the SIO and Routing Label formats are not changed.
> > >
> > > But forces the work on the ASP when the SG MTP3 is already
> > > fitted with routing label parser/generators.
> > >
> > > > Treating the OPC, DPC, SLS and SIO as separate from the
> > > > message is no different than placing the Affected PC in a
> > > > parameter for the MTP-PAUSE, MTP-RESUME, and MTP-STATUS
> > > > primitives.  The point codes should be split out with TLV
> > > > parameters similar to those used to represent point codes in
> > > > the DUNA and DAVA messages.  SLS and SIO will require their
> > > > own parameters.  Because these parameters are mandatory
> > > > parameters of the MTP-TRANSFER primitive, it may be useful to
> > > > group them and place them in a single TLV as follows:
> > > >
> > > > [Greg]  Brian, this approach was considered early and had some
> > > > proponents.  But a choice was made for the current method.
> > > > The same appoach wasn't used for MTP-PAUSE/RESUME/STATUS
> > > > because these were generated internal to the SG by MTP3, as
> > > > opposed to MTP-TRANSFER which came in to the SG from the SS7
> > > > network already encoded (i.e., MTP3 SIO, Routing Label, ...).
> > > > It may look oddto some people but I think it works.
> > >
> > > What is the difference from extracting the PC from a TFP and
> > > putting it into a DUNA an extracting a PC from a routing label
> > > and putting it in a DATA message?  Sorry, but both are generated
> > > internal to the SG.
> >
> > [Greg2]  IMO the PC is not extracted from an incoming TFP and
> > put into a DUNA.  Incoming TFPs are consumed by the MTP3.
> 
> Well, it is clear to me that the MTP3 RL is the first thing
> consumed by the MTP3, headers need to be decoded before (or as)
> state machines are run.
> 
> >
> > > I think this should be re-examined.  I surely didn't hear any
> > > objections to this proposal.  Are there any objections out there?
> >
> > [Greg2] Sure, lets hear from some others - is there support for
> > the change?
> >
> > > >     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 = 28           |          Length = 24          |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |                     Originating Point Code                    |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |                     Destination Point Code                    |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |   Signalling Link Selection   |       Service Indicator       |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |            Tag = 3            |             Length            |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    \                                                               \
> > > >    /                        Protocol Data                          /
> > > >    \                                                               \
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > > Where now the Protocol Data would only contain MTP-User data.
> > > >
> > > > Note that I have removed the "Network Appearance" parameter.
> > > > This is because it is useless.  The Network Appearance
> > > > parameter is based on the premise that it somehow defines the
> > > > point code format used.  This is not the case, as the Service
> > > > Indicator Octet (and NI) must also be taken into consideration
> > > > when determining the point code format.
> > > >
> > > > [Greg] The Network Appearance indicates the SS7 network
> > > > partition (SG links/linksets/routes/routesets) for the
> > > > messages to be sent/received at the SG.  It is certainly not
> > > > useless.  Within a network partition, only one point code
> > > > format would be used.
> > >
> > > But, an ASP cannot span multiple SPMCs, so the routing context
> > > defines the network appearance and the network appearance is
> > > redundant.
> >
> > [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to
> > receive traffic for multiple Application Servers (with different
> > DPC/OPCs/NIs).  Are you saying we need to include the Routing
> > Context instead?  Can you fill this point out a bit - I don't see
> > it yet.
> 
> Yes.  I believe the Routing Context should be included with each
> message just as is the IID in M2UA.  I also believe that it should
> be included in other M3UA messages such as DUNA, DAVA, etc.  In
> consideration of gateway screening at an SG, a TFA does not
> translate to a DAVA for all routing contexts.  It should only send
> a DAVA to routing contexts to which the SG offers a route to the
> affected destination.  This is the way STP's operate today.  A
> switch in New Brunswick is not notified of the availability or
> prohibition or restriction of a switch in Sacrameto to which it
> has no trunks and no other need for a signalling route.  To do
> otherwise is to broadcast the unavailability of point codes internal
> to a network operator's network to the entire world (just about).
> The unavailability of point codes is confidential information to
> the network operator which they do not want to broadcast to
> interconnecting networks in most circumstances.
> 
> With this change, it will become possible under M3UA to have AS
> which are treated with different routing policies under gateway
> screening at the SG.
> 
> > > > By the same token, Network Appearance is useless in DUNA and
> > > > DAVA messages.  There is no network indicator provided in
> > > > MTP-PAUSE and MTP-RESUME primitives.
> > > >
> > > > [Greg] The alternative was to provide a Point Code Format
> > > > field/parameter and have entries for every PC permutation.  As
> > > > you say the Network Appearance is not passed up in MTP-PAUSE
> > > > and RESUME primitives - it is used in the M3UA to pass these
> > > > primitives to the correct MTP3-User instances at the ASPs.
> > > > The Network Appearance was already used to direct the
> > > > MTP-TRANSFER primitives to the correct instance so it was
> > > > re-used instead.
> > >
> > > Again, the ASP knows the point code format from the routing
> > > context (because it cannot span multiple SPMCs).  The network
> > > appearance is redundant.
> > >
> > > > On the other hand, for Q.701 7.2.6 operation with indication
> > > > of SIF permitted in TFP/TFA messages, the Affected PC
> > > > parameters of DUNA and DAVA need to be expanded to include the
> > > > SIF bits present in these indications.
> > > >
> > > > [Greg]  This section is talking about Red Book to Blue Book
> > > > link interworking.  Unless anyone is building an SG with links
> > > > into a Red Book MTP network (62-octet SIF maximum) I think we
> > > > can ignore this.
> > > >
> > > > Cheers,
> > > >
> > > >    Greg Sidebottom
> > > >
> > > >
> > > > Actually, Network Appearance should be struck from the whole
> > > > document.
> 
> I would be very interested to hear other opinions, but in today's
> economy, don't hold your breath! ;)
> 
> --
> 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]

-- 
================================================================== Joyce
Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521 Agilent Technologies
UK Ltd  | Telnet:   313 2521 South Queensferry,           | Mailstop:
SQFRD3A EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: DRST message.
Date: Tue, 26 Jun 2001 10:35:30 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail3.rdc1.on.home.com [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Nitin,

Responses below ...

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Saturday, June 23, 2001 10:48 PM
Subject: M3UA06: DRST message.

> Hi All,
>
>  I have few queries/comments on DRST message of M3UA draft 06:
>
> 1. Section 3.4.6
>   "The M3UA at the ASP is expected to send traffic to the affected
> destination via an alternate SG
>      of equal priority, but only if such an alternate route exists and is
> available",
>
>  -  Does this mean M3UA at ASP need to maintain the priority of the route
> among the SGs,
>     if yes, on what basis?
>

[Greg] If the two routes (to the two SGs) as are always of equal priority
and the traffic is normally loadshared equally, then I suppose there really
isn't a need to define priorities for the two routes.  I've always assumed
that an ASP with more than one route would follow the equivalent MTP3 route
management procedures but leaving it open does allow other possibilities.

It is possible that some may want to use one SG as the primary and the other
as the back-up route, or take into account differences in the route
capacity/delay, etc.  For the primary/back-up case, I think a DRST on the
currently used route would be ignored.  For other cases I don't know the
answer but things could get pretty complicated - I really don't want to go
there.

> 2. Section 1.3.2.4
>   "Providing an indication to MTP3-Users at an ASP that the routes to a
>    remote MTP3-User peer in the SS7 network are restricted"
>
> -  What possible use an MTP3-User can make out from knowing that the
> destination is
>    restricted? I think this text is not required in the draft.
>

[Greg] I have this in Section 1.3.2.3.   Anyway, this is definitely
incorrect - Thanks for catching this.  I think the bullet was added to cover
the case of informing the M3UA at the ASP (not the MTP3-User).  We can
change the bullet to:

>   "Providing an indication to the M3UA peer at an ASP that the routes to a
>    remote MTP3-User peer in the SS7 network are restricted"

or we can just delete it.

> 3. Greg, When can we expect M3UA draft 07?
>
> Regards
> Nitin.
>
>

I promised Lyndon to have it out by last Friday - I am probably driving him
(and others) crazy.   I still have a few things to look at, including some
good suggestions from Brian.   Should have it out this week.

Cheers,

  Greg Sidebottom

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 26 Jun 2001 11:13:26 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: gull.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gull.mail.pas.earthlink.net [207.217.121.85]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Joyce,

What do you care what the point code format is when it is justified into 24
bits?  Did you just want to pretty-print it on a display?
I seriously object to packing redundant information into each message just
so your monitoring box does not have to know network configuration
information.

As another point, with the addition of ASP Id, it would be possible to
discern point code format from routing context and static provisioning
information (because you know the identity of the ASP which registered and
can know how the ASP has been provisioned to register.  An ASP cannot
register for multiple networks anyway).

--Brian

Joyce Archibald wrote:                           (Tue, 26 Jun 2001 10:48:39)
> Greg,
> 
> I would like to register an objection to the current proposals on the
> grounds that they would make it impossible to perform network
> monitoring.
> 
> In the case of multiple networks it is essential that the DATA message
> should contain some indication of the network id and the pointcode
> format (i.e. 14-bit, 16-bit or 24-bit). We expected to be able to get
> this information from the Network Appearance parameter and the Routing
> Label itself. We cannot use the Routing Context because we cannot know
> which routing key it refers to, since the Registration Request/Response
> may have taken place before monitoring was started and in any case it
> would be impractical to maintain a complete list of all Routing Contexts
> on the network.
> 
> If you are going to remove Network Appearance, you need to replace it
> with something other than the Routing Context. I believe network/format
> indicators on all pointcodes has already been considered and rejected.
> Any other ideas?
> 
> Earlier this year Normand Glaude wrote:
> 
> > 
> > Joyce,
> > 
> > Yes, you are correct in saying that the purpose of the Network
Appearance is to
> > define the format and network indicator and protocol variant used within
the SS7
> > network partition. However, in light of the later definitions, the
concept of
> > "network partitioning" comes into play. So the question is: What is a
Network
> > Partition?
> > 
> > This is what I'm trying to address.  More specifically, in the event
that an
> > SG represents two end nodes in the same network, how can an ASP
distinguish  which
> > end-node a DUNA pertains to? By defining a network appearance as the
appearance of a
> > node in a network, this ambiguity is no longer there.
> > 
> > Greg/John, how about this as a definition?
> > 
> > Network Appearance - The Network Appearance uniquely identifies an SS7
entity (point
> > code) into a SS7 network, as presented by the SG.  It is used for the
purposes of
> > logically separating the signaling traffic between the SG and the
Application Server
> > Processes over a common SCTP Association.  This partitioning is
necessary where an
> > SG is logically partitioned to appear as an end-node elements in
multiple separate
> > SS7 networks, in which case there is a separate network appearance for
each point
> > code in the SS7 networks. It is also necessary when an SG is configured
as an STP
> > hosting multiple point codes, or when configured as multiple endnodes
within the
> > same network, in which case each point code is a separate network
appearance.
> > 
> > Norm
> 
> This definition has now been adopted by SUA-06. Is there some reason why
> it doesn't apply to M3UA?
> 
> In the light of this definition may I suggest again:
> 
> > Would it help to define the format of Network Appearance, maybe:-
> >
> >     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 = 1            |        Length = 8             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Network Id.   |         End node Id (or pointcode)            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > The End node Id could optionally be zero if the Network Appearance
> > applied to the whole SS7 network.
> 
> Please see further comments inline...
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Greg,
> > 
> > Comments inline...
> > 
> > Greg Sidebottom wrote:                   (Thu, 21 Jun 2001 13:28:58)
> > > > >
> > > > > Greg,
> > > > >
> > > > > I see a number of difficulties in the packing and unpacking,
> > > > > and filtering of DATA Payload information.  Perhaps not
> > > > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > > > the MTP Routing Label in the data payload.  The MTP RL is the
> > > > > MTP Level 3 Header (much like an IP header) and is not part of
> > > > > the payload transferred to an from the MTP-User.
> > > > >
> > > > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER
> > > > > primitive contain the OPC, DPC, SLS and SIO.  The Routing
> > > > > Label format was used for the Protocol Data parameter in the
> > > > > Data message so that these fields are not re-encoded across
> > > > > the SG.
> > > >
> > > > Ah, but they will be.  You see the SG MTP3 must unpack the
> > > > routing label to determine whether the MSU is a management
> > > > message.  By the time the MSU gets to an MTP3-User, the routing
> > > > label has likely been removed and placed into an internal
> > > > representation.  To put it back into the M3UA message would
> > > > require an MTP3 routing label encoder.  If you look at M3UA in a
> > > > simple case where it is just an MTP3-User, this is normally the
> > > > case.  The MTP3-User does not have (nor want) direct access to
> > > > the L3 protocol header.
> > >
> > > [Greg2] I really cannot say whether all MTP3 implementations
> > > separate the routing label or not, or put it back in or not.  I
> > > don't really want to get into how implementations will unpack
> > > SS7 message parts into internal representations and and re-pack
> > > information into M3UA DATA messages.  I'm sure that there are
> > > lots of possibilities.  Separating out the Routing Label,
> > > placing into an internal representation and then re-packing
> > > using an MTP3 Routing Label encoder is one method I guess.
> > 
> > I think it is fair to say that all SG implmentations must understand
> > each RL format and need to unpack it for comparison against routing
> > keys to determine to which ASP the message is bound.  This is a
> > normal function of MTP Level 3.  I agree that the spec should not
> > restrict itself to one implementation, but it is difficult to see
> > which implementations it supports without discussing them.
> > Implementation experience is quite helpful to the process I believe.
> > 
> > MTP3 Routing Labels are packed in quite an unnatural format for
> > a little-endian machine.  Even a big-endian machine requires
> > shifting and masking to extract the components of the label for
> > comparison.  An MTP3 implementation must index routing tables on
> > the basis of these components, and it is hard to believe that
> > M3UA in any form is suitable for simplified protocol conversion
> > devices.  (The M3UA spec sees fit from previous discussion to
> > warn against stateless protocol conversion approaches.)
> > 
> > I don't think that is is a massive leap in Engineering logic or
> > experience, or practice to say that the MTP3 at the SG will unpack
> > the label to peform its functions.
> > 
> > > > > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > > > > following parameters:
> > > > >
> > > > >         OPC (see 2.2/Q.704)
> > > > >         DPC (see 2.2/Q.704)
> > > > >         SLS (see 2.2/Q.704)
> > > > >         SIO (see 14.2/Q.704)
> > > > >         User data (see 2.3.8/Q.703)
> > > > >
> > > > > You will find the same list of parameters in Table 9/T1.112.1.
> > > > >
> > > > > In neither list is the NI (Network Indicator) or MP (Message
> > > > > Priority) listed.  This is, IMHO, because the assignment of
> > > > > these values is to be peformed by MTP and is not at the
> > > > > discretion of the MTP-User.
> > > > >
> > > > > [Greg] No, the NI and MP (national use) are shown as part of
> > > > > the SIO Subservice Field in the relevant MTP3 recommendations
> > > > > (Q.704 Section 14.2 or national equivalent).  Q.701 Table 1
> > > > > (and your list above) lists the SIO as a parameter of the
> > > > > MTP-TRANSFER and refers to Q.704 Section 14.2 for details.  So
> > > > > IMO the SIO Subservice Field is included in the MTP-TRANSFER
> > > > > and therfore the NI and MP (national variants) are there.
> > > > > I'm not sure how all SS7 vendors implemented the MTP-TRANSFER
> > > > > primitive as it is not visible, but I've always assumed that
> > > > > the MTP3-User assigns the Message priority.  The NI could be
> > > > > picked up without the MTP3-User assigning it but I'm not sure
> > > > > that it really matters.
> > > >
> > > > In further discussion on SUA, it appears that MP must be
> > > > assigned by SCCP in some cases (MTP3 is not expected to have
> > > > knowledge of SCCP users) so it should be part of the structure
> > > > in some form.  I would suggest unpacking it.  NI is clearly part
> > > > of the MTP-SAPID and does not need to be transferred.
> > >
> > > [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.
> > > As for the NI, I agree it can be picked up based on the MTP-SAPID.
> > > In an SS7 node this is not an issue.  In the M3UA where the
> > > MTP3-Users are remote I think it has to be transfered - see NA
> > > response below ...
> > 
> > Network indicator has become link specific due to point-code
> > exhausting in some administrations.  The NI does not necessarily
> > identify the format of a point code.  The NI coupled with the link
> > on which the message is received or sent does.  Although I agree
> > that it might be advantageous to some network configurations to
> > transfer the NI bits to the MTP3-User, their interpretation must
> > be in light of local network configuration and administration
> > practices.  That is why it is better to distinguish on MTP-SAPID.
> > The MTP-SAPID is embodied in the Routing Context (a handle to the
> > binding of ASP to MTP-SAPID).
> > 
> 
> I have no objection to replacing the Routing Label with a mandatory
> header. The NI bits are not needed if the Network Appearance parameter
> is present to indicate different pointcode formats.
> 
> > >
> > > > > In comparing this primitive to the Payload Data Message (DATA)
> > > > > in Section 3.3.1 and bearing in mind the statements of Section
> > > > > 4.1.1 with regards to MTP-Transfer, and considering IPSP
> > > > > operation, I have the following problems:
> > > > >
> > > > > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > > > > MTP-User, M3UA is required to pack a routing label into the
> > > > > Payload of a DATA message.  Because the MTP-TRANSFER primitive
> > > > > does not contain NI or MP parameters, M3UA will have to
> > > > > generate them.
> > > > >
> > > > > [Greg] I don't agree - see above.  IMO the NI and MP are in
> > > > > the MTP-TRANSFER primitive.
> > > >
> > > > See Al's discussion on SUA thread.
> > > >
> > > > > Also, M3UA will have to choose some variant for the packing of
> > > > > the DATA Payload.  The receiving M3UA will have to unpack the
> > > > > same data to be able to generate an MTP-TRANSFER primitive to
> > > > > its MTP-User.
> > > > >
> > > > > [Greg] The M3UA at the SG doesn't really have to do any
> > > > > choosing of variants.  The format of the incoming SIO/Routing
> > > > > Label/User Data is already packed according to the MTP3
> > > > > variant and is not changed.  The M3UA at the receiver knows
> > > > > the variant used and the expectations of the format for the
> > > > > upper layer primitive to the MTP3-User instance.
> > > >
> > > > With the data already unpacked from the MTP3 RL, the M3UA at the
> > > > ASP need not know the RL structure to provide the MTP-TRANSFER
> > > > primitive to its users.  Less chance for error, less
> > > > parsing/building effort.
> > >
> > > [Greg2] Might make things easier at the ASP but introduces
> > > complexity at the SG as it is in effect "normalizing" the MTP3
> > > variations of SIO/RL structure/semantics into the new DATA
> > > parameters.  I may be dense but don't see the net gain.  Other
> > > opinions?
> > 
> > Normalizing the MTP3 interface is the current job of MTP Level 3
> > protocol stacks which provide support for multiple point code
> > formats and protocol variants.  Normalizing the representation of
> > parameters in the MTP-TRANSFER is fascile, and a necessary part
> > of a multiple variant implementation.
> > 
> > The net gain is that implementors of SGs will be able to integrate
> > 3rd party MTP Level 3 stacks which have already been homogomized
> > and conformance tested, plus implementors of ASPs will not need
> > to understand the bit packing of routing labels.  If the ASP is
> > kept above the MTP3 to MTP3-User boundary, conformance testing
> > at Level 3 will not be necessary.  If the MTP3 functions become
> > partitioned across SG and ASP (and encoding and decoding MTP3
> > headers is one of those functions), then each permutation of
> > SG/ASP combination will need be conformance tested.  Half the
> > reason for using something like M3UA is so that a conforming SG
> > can for the most part take the SS7 MTP compliance worries away from
> > an application on an ASP.
> > 
> > >
> > > > > This seems ridiculous, particularly in the IPSP case, where
> > > > > the packing and unpacking is rather arbitrary.  It makes far
> > > > > more sense to pass the OPC, DPC, SLS and SIO as separate
> > > > > parameters of the DATA message and leave the User data from
> > > > > the MTP-TRANSFER primitive as the Payload Data.
> > > > >
> > > > > [Greg] The IPSP case is a little more arbitrary, as you say,
> > > > > but was left consistent with the SG/ASP case.
> > > > >
> > > > >
> > > > > You will note that MP is *not* part of the MTP-TRANSFER
> > > > > primitive and there is no need to distinguish between ITU (w/o
> > > > > MP), ANSI, and TTC approaches in the Payload Data when the
> > > > > proper parameters are added to the message.  It is the
> > > > > responsibility of MTP Level 3 to determine the Message
> > > > > Priority of a MTP-User message and not the responsibility of
> > > > > the MTP-User.  The same is true for NI and it no longer
> > > > > becomes necessary to include a Network Appearance parameter at
> > > > > all.  (More on Network Appearance later...)
> > > > >
> > > > > [Greg] I guess we don't agree - IMO the Message priority
> > > > > assignment is done by the MTP3-User (TTC might be an exception
> > > > > though).
> > > >
> > > > Again, from SUA thread, SCCP must assign MP.  I don't care if it
> > > > is added in the structure.  Just don't leave it in the routing
> > > > label, and no need for differences for TTC.
> > > >
> > > > > The format of the routing label, by the way, can be dependent
> > > > > upon SIO, and in some networks it is.  For example, one SIO
> > > > > value can be assigned for National ISUP (where the routing
> > > > > label is formatted using, say 24-bit point code) and another
> > > > > assigned for International ISUP (where the routing label is
> > > > > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > > > > 2.2.1, last paragraph on Page 4.
> > > > >
> > > > > [Greg]  That is fine.  The current approach can handle this as
> > > > > the SIO and Routing Label formats are not changed.
> > > >
> > > > But forces the work on the ASP when the SG MTP3 is already
> > > > fitted with routing label parser/generators.
> > > >
> > > > > Treating the OPC, DPC, SLS and SIO as separate from the
> > > > > message is no different than placing the Affected PC in a
> > > > > parameter for the MTP-PAUSE, MTP-RESUME, and MTP-STATUS
> > > > > primitives.  The point codes should be split out with TLV
> > > > > parameters similar to those used to represent point codes in
> > > > > the DUNA and DAVA messages.  SLS and SIO will require their
> > > > > own parameters.  Because these parameters are mandatory
> > > > > parameters of the MTP-TRANSFER primitive, it may be useful to
> > > > > group them and place them in a single TLV as follows:
> > > > >
> > > > > [Greg]  Brian, this approach was considered early and had some
> > > > > proponents.  But a choice was made for the current method.
> > > > > The same appoach wasn't used for MTP-PAUSE/RESUME/STATUS
> > > > > because these were generated internal to the SG by MTP3, as
> > > > > opposed to MTP-TRANSFER which came in to the SG from the SS7
> > > > > network already encoded (i.e., MTP3 SIO, Routing Label, ...).
> > > > > It may look oddto some people but I think it works.
> > > >
> > > > What is the difference from extracting the PC from a TFP and
> > > > putting it into a DUNA an extracting a PC from a routing label
> > > > and putting it in a DATA message?  Sorry, but both are generated
> > > > internal to the SG.
> > >
> > > [Greg2]  IMO the PC is not extracted from an incoming TFP and
> > > put into a DUNA.  Incoming TFPs are consumed by the MTP3.
> > 
> > Well, it is clear to me that the MTP3 RL is the first thing
> > consumed by the MTP3, headers need to be decoded before (or as)
> > state machines are run.
> > 
> > >
> > > > I think this should be re-examined.  I surely didn't hear any
> > > > objections to this proposal.  Are there any objections out there?
> > >
> > > [Greg2] Sure, lets hear from some others - is there support for
> > > the change?
> > >
> > > > >     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 = 28           |          Length = 24
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |                     Originating Point Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |                     Destination Point Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |   Signalling Link Selection   |       Service Indicator
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    |            Tag = 3            |             Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >    \
\
> > > > >    /                        Protocol Data
/
> > > > >    \
\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > >
> > > > > Where now the Protocol Data would only contain MTP-User data.
> > > > >
> > > > > Note that I have removed the "Network Appearance" parameter.
> > > > > This is because it is useless.  The Network Appearance
> > > > > parameter is based on the premise that it somehow defines the
> > > > > point code format used.  This is not the case, as the Service
> > > > > Indicator Octet (and NI) must also be taken into consideration
> > > > > when determining the point code format.
> > > > >
> > > > > [Greg] The Network Appearance indicates the SS7 network
> > > > > partition (SG links/linksets/routes/routesets) for the
> > > > > messages to be sent/received at the SG.  It is certainly not
> > > > > useless.  Within a network partition, only one point code
> > > > > format would be used.
> > > >
> > > > But, an ASP cannot span multiple SPMCs, so the routing context
> > > > defines the network appearance and the network appearance is
> > > > redundant.
> > >
> > > [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to
> > > receive traffic for multiple Application Servers (with different
> > > DPC/OPCs/NIs).  Are you saying we need to include the Routing
> > > Context instead?  Can you fill this point out a bit - I don't see
> > > it yet.
> > 
> > Yes.  I believe the Routing Context should be included with each
> > message just as is the IID in M2UA.  I also believe that it should
> > be included in other M3UA messages such as DUNA, DAVA, etc.  In
> > consideration of gateway screening at an SG, a TFA does not
> > translate to a DAVA for all routing contexts.  It should only send
> > a DAVA to routing contexts to which the SG offers a route to the
> > affected destination.  This is the way STP's operate today.  A
> > switch in New Brunswick is not notified of the availability or
> > prohibition or restriction of a switch in Sacrameto to which it
> > has no trunks and no other need for a signalling route.  To do
> > otherwise is to broadcast the unavailability of point codes internal
> > to a network operator's network to the entire world (just about).
> > The unavailability of point codes is confidential information to
> > the network operator which they do not want to broadcast to
> > interconnecting networks in most circumstances.
> > 
> > With this change, it will become possible under M3UA to have AS
> > which are treated with different routing policies under gateway
> > screening at the SG.
> > 
> > > > > By the same token, Network Appearance is useless in DUNA and
> > > > > DAVA messages.  There is no network indicator provided in
> > > > > MTP-PAUSE and MTP-RESUME primitives.
> > > > >
> > > > > [Greg] The alternative was to provide a Point Code Format
> > > > > field/parameter and have entries for every PC permutation.  As
> > > > > you say the Network Appearance is not passed up in MTP-PAUSE
> > > > > and RESUME primitives - it is used in the M3UA to pass these
> > > > > primitives to the correct MTP3-User instances at the ASPs.
> > > > > The Network Appearance was already used to direct the
> > > > > MTP-TRANSFER primitives to the correct instance so it was
> > > > > re-used instead.
> > > >
> > > > Again, the ASP knows the point code format from the routing
> > > > context (because it cannot span multiple SPMCs).  The network
> > > > appearance is redundant.
> > > >
> > > > > On the other hand, for Q.701 7.2.6 operation with indication
> > > > > of SIF permitted in TFP/TFA messages, the Affected PC
> > > > > parameters of DUNA and DAVA need to be expanded to include the
> > > > > SIF bits present in these indications.
> > > > >
> > > > > [Greg]  This section is talking about Red Book to Blue Book
> > > > > link interworking.  Unless anyone is building an SG with links
> > > > > into a Red Book MTP network (62-octet SIF maximum) I think we
> > > > > can ignore this.
> > > > >
> > > > > Cheers,
> > > > >
> > > > >    Greg Sidebottom
> > > > >
> > > > >
> > > > > Actually, Network Appearance should be struck from the whole
> > > > > document.
> > 
> > I would be very interested to hear other opinions, but in today's
> > economy, don't hold your breath! ;)
> > 
> > --
> > 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]
> 
> -- 
> ==================================================================
> Joyce Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521
> Agilent Technologies UK Ltd  | Telnet:   313 2521 
> South Queensferry,           | Mailstop: SQFRD3A
> EH30 9TG, Scotland.          | E-mail: [email-masked]
> ==================================================================
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 26 Jun 2001 11:29:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: gull.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gull.mail.pas.earthlink.net [207.217.121.85]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Verwimp,

Verwimp Gery wrote:                            (Tue, 26 Jun 2001 10:43:27)
> Brian,
> 
> 1) I didn't say TCAP transactions must be coupled. Where did you read that
?
> They can still follow either path via either SG (different point codes),
> keeping in mind in-sequence-delivery. When routing is on DPC, yes the SG
is

I was reading section 1.3.5 where it says:

    Replicated endpoints : only for the first message in a transaction
    or connection one of the SGs is chosen, depending on the traffic
    mode (primary/backup or loadsharing) and overoad conditions.  Once
    selected, the same SG is used for subsequent messages.

I interpreted this as a coupling of messages in the transaction.  Have I
somehow misinterpreted this passage?

> the end-point. But, if you insist, nothing prevents this DPC to be an
> "alias" point code, so that the previous STP still has the choice between
> the 2 SGs behind this "alias".

With "alias" point codes you get back into the problem area.  This approach
only works for relays, not for endpoint subsystems.

> 
> With routing on GT, of course every option of loadsharing and routing
> remains open.
> 
> So far for the main part of SCCP/SUA-users.
> 
> 2) SCCP connections (for the Nth time now) : the point is the second leg
> must be setup because you don't have point codes in the IP-domain.
Besides,
> coupling of connection sections is also described in ITU-T and ANSI as
being
> mandatory when network borders are crossed.

Because the subsystem is "local" to the SG, from the SS7 network
perspective, no network borders are being crossed.

> If you find this approach too restrictive : too bad. Just keep in mind,
that
> under normal circumstances, every CO message will flow through the same SG
> anyway.

No.  For loadsharing, the return messages can be sent via the opposite SG
under class 2.  The restriction is too severe.

Do you think that the situation is so hard for you to understand that a
proper response to me is to just say "too bad"?  All you have to do is
strike the text which imposes this "coupling" requirement and leave it to
the implementor's to decide how or when to do "uncoupled" relay (it *is*
done in SS7 networks).  Also, the addition of an SUA message equivalent to a
N-PCSTATE primitive would be helpful.

> 
> 3) With seemless I don't mean : "give every ASP/ASP group a point code and
> act like it's an MTP network", but
> 
> - the SS7 SEP doesn't notice he's dealing with an ASP
> - the ASP couldn't care less whether it's another ASP or an SS7 SEP he's
> conversing with, procedures are the same (objective of SUA management).

Some implementations of SUA at the ASP to perform decoupling at the SG care.
I am just looking for text and messages which permit decoupling.  It appears
that you want to restrict it because your specific and narrow application
does not need it.  That is no reason to restrict the specification from full
and seamless SCCP interworking.

> 
> All thanks to the SG.
> 
> P.S. either STP or SEP ? That's too restrictive an approach ! Any
> combination 'll do.

I say again (for the fourth time): STP does not work for decoupled operation
in classes 0 and 2.  Remove the coupling text and provide full point code
status support for N-PCSTATE and they will.

> 
> ____________________________
> 
> 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: maandag 25 juni 2001 18:38
> To: sigtran
> Cc: [email-masked]
> Subject: Re: SUA5: SG Relay Problems
> 
> 
> Verwimp,
> 
> Your are still missing the point.  The SGs must be viewed
> from the SS7 network as either SPs (with different point
> codes) or STPs (with different point codes).  The constraint
> in SUA that all transactions and connections must be "coupled"
> rules out the SS7 network viewing the SGs as STPs.  This
> leaves you will two choices:
> 
> 1)  Use only a single SG with no STP function (and no
>     GTT towards the ASP as far as the SS7 network is
>     concerned).
> 
> 2)  Use multiple SGs, but each has its own point code, does
>     not perform a relay function, and has no GTT as far as
>     the SS7 network is concerned towards the ASP, and can
>     only be replicated susbstems as far as the SS7 network
>     is concerned.
> 
> This is a very limited scenario.  I believe that SUA should
> permit a wider range of solutions at the SG than merely
> making SGs act as SEPs.
> 
> Also, this restricted arrangement is far from seamless.
> 
> --Brian
> 
> 
> 
> 
> ---
> 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/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 26 Jun 2001 13:01:57 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Some comments in-line.

/Kurt

Greg Sidebottom wrote:

> Thanks Brian,
>
> Responses below ...
>
> ----- Original Message -----
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Thursday, June 21, 2001 4:41 AM
> Subject: Re: Packing of DATA Payloads
>
> Greg,
>
> Please see comments below....
>
> Greg Sidebottom wrote:                          (Thu, 21 Jun 2001
03:42:09)
> > Thanks Brian,
> >
> > Some responses (finally!) below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Monday, June 04, 2001 3:08 PM
> > Subject: M3UA: Packing of DATA Payloads
> >
> >
> > Greg,
> >
> > I see a number of difficulties in the packing and unpacking,
> > and filtering of DATA Payload information.  Perhaps not
> > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > the MTP Routing Label in the data payload.  The MTP RL is
> > the MTP Level 3 Header (much like an IP header) and is not
> > part of the payload transferred to an from the MTP-User.
> >
> > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> > contain the OPC, DPC, SLS and SIO.  The Routing Label format was used
for
> > the Protocol Data parameter in the Data message so that these fields are
> not
> > re-encoded across the SG.
>
> Ah, but they will be.  You see the SG MTP3 must unpack the routing
> label to determine whether the MSU is a management message.  By the
> time the MSU gets to an MTP3-User, the routing label has likely
> been removed and placed into an internal representation.  To put
> it back into the M3UA message would require an MTP3 routing label
> encoder.  If you look at M3UA in a simple case where it is just
> an MTP3-User, this is normally the case.  The MTP3-User does not
> have (nor want) direct access to the L3 protocol header.
>
> [Greg2] I really cannot say whether all MTP3 implementations separate the
> routing label or not, or put it back in or not.  I don't really want to
get
> into how implementations will unpack SS7 message parts into internal
> representations and and re-pack information into M3UA DATA messages.  I'm
> sure that there are lots of possibilities.  Separating out the Routing
> Label, placing into an internal representation and then re-packing using
an
> MTP3 Routing Label encoder is one method I guess.

I am only familiar with 4 MTP3 implementations, but all of them separated
the routing
label from the payload data when delivering a message to the user. However,
a couple of
them offered a lower level interface to the MTP3 data where it was possible
to access a "raw"
data message.

>
>
> >
> >
> >
> > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > following parameters:
> >
> >         OPC (see 2.2/Q.704)
> >         DPC (see 2.2/Q.704)
> >         SLS (see 2.2/Q.704)
> >         SIO (see 14.2/Q.704)
> >         User data (see 2.3.8/Q.703)
> >
> > You will find the same list of parameters in Table 9/T1.112.1.
> >
> > In neither list is the NI (Network Indicator) or MP (Message
> > Priority) listed.  This is, IMHO, because the assignment of
> > these values is to be peformed by MTP and is not at the discretion
> > of the MTP-User.
> >
> > [Greg] No, the NI and MP (national use) are shown as part of the SIO
> > Subservice Field in the relevant MTP3 recommendations (Q.704 Section
14.2
> or
> > national equivalent).  Q.701 Table 1 (and your list above) lists the SIO
> as
> > a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
> > details.  So IMO the SIO Subservice Field is included in the
MTP-TRANSFER
> > and therfore the NI and MP (national variants) are there.   I'm not sure
> how
> > all SS7 vendors implemented the MTP-TRANSFER primitive as it is not
> visible,
> > but I've always assumed that the MTP3-User assigns the Message priority.
> > The NI could be picked up without the MTP3-User assigning it but I'm not
> > sure that it really matters.
>
> In further discussion on SUA, it appears that MP must be assigned by
> SCCP in some cases (MTP3 is not expected to have knowledge of SCCP users)
> so it should be part of the structure in some form.  I would suggest
> unpacking it.  NI is clearly part of the MTP-SAPID and does not need to
> be transferred.
>
> [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.  As for
> the NI, I agree it can be picked up based on the MTP-SAPID.   In an SS7
node
> this is not an issue.  In the M3UA where the MTP3-Users are remote I think
> it has to be transfered - see NA response below ...
>
> >
> >
> >
> > In comparing this primitive to the Payload Data Message (DATA)
> > in Section 3.3.1 and bearing in mind the statements of Section
> > 4.1.1 with regards to MTP-Transfer, and considering IPSP operation,
> > I have the following problems:
> >
> > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > MTP-User, M3UA is required to pack a routing label into the Payload
> > of a DATA message.  Because the MTP-TRANSFER primitive does not
> > contain NI or MP parameters, M3UA will have to generate them.
> >
> > [Greg] I don't agree - see above.  IMO the NI and MP are in the
> MTP-TRANSFER
> > primitive.
>
> See Al's discussion on SUA thread.
>
> >
> >
> > Also, M3UA will have to choose some variant for the packing of
> > the DATA Payload.  The receiving M3UA will have to unpack the
> > same data to be able to generate an MTP-TRANSFER primitive to
> > its MTP-User.
> >
> > [Greg] The M3UA at the SG doesn't really have to do any choosing of
> > variants.  The format of the incoming SIO/Routing Label/User Data is
> already
> > packed according to the MTP3 variant and is not changed.  The M3UA at
the
> > receiver knows the variant used and the expectations of the format for
the
> > upper layer primitive to the MTP3-User instance.
>
> With the data already unpacked from the MTP3 RL, the M3UA at the ASP need
> not know the RL structure to provide the MTP-TRANSFER primitive to its
> users.  Less chance for error, less parsing/building effort.
>
> [Greg2] Might make things easier at the ASP but introduces complexity at
the
> SG as it is in effect "normalizing" the MTP3 variations of SIO/RL
> structure/semantics into the new DATA parameters.  I may be dense but
don't
> see the net gain.  Other opinions?

For those MTP3 implemenations which already break out the RL, I agree with
Brian that it would be simpler to just pass the RL as parameters instead of
re-encoding the
RL. IMO, if the specifications indicate that the MTP-TRANSFER primitive
breaks out the RL from the User data then the DATA message should do the
same.

>
>
> >
> >
> >
> > This seems ridiculous, particularly in the IPSP case, where the
> > packing and unpacking is rather arbitrary.  It makes far more sense
> > to pass the OPC, DPC, SLS and SIO as separate parameters of the
> > DATA message and leave the User data from the MTP-TRANSFER primitive
> > as the Payload Data.
> >
> > [Greg] The IPSP case is a little more arbitrary, as you say, but was
left
> > consistent with the SG/ASP case.
> >
> >
> > You will note that MP is *not* part of the MTP-TRANSFER primitive
> > and there is no need to distinguish between ITU (w/o MP), ANSI,
> > and TTC approaches in the Payload Data when the proper parameters
> > are added to the message.  It is the responsibility of MTP Level 3
> > to determine the Message Priority of a MTP-User message and not
> > the responsibility of the MTP-User.  The same is true for NI and
> > it no longer becomes necessary to include a Network Appearance
> > parameter at all.  (More on Network Appearance later...)
> >
> > [Greg] I guess we don't agree - IMO the Message priority assignment is
> done
> > by the MTP3-User (TTC might be an exception though).
>
> Again, from SUA thread, SCCP must assign MP.  I don't care if it
> is added in the structure.  Just don't leave it in the routing
> label, and no need for differences for TTC.
>
> >
> >
> > The format of the routing label, by the way, can be dependent
> > upon SIO, and in some networks it is.  For example, one SIO
> > value can be assigned for National ISUP (where the routing
> > label is formatted using, say 24-bit point code) and another
> > assigned for International ISUP (where the routing label is
> > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > 2.2.1, last paragraph on Page 4.
> >
> > [Greg]  That is fine.  The current approach can handle this as the SIO
and
> > Routing Label formats are not changed.
>
> But forces the work on the ASP when the SG MTP3 is already fitted
> with routing label parser/generators.
>
> >
> >
> > Treating the OPC, DPC, SLS and SIO as separate from the message
> > is no different than placing the Affected PC in a parameter for
> > the MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives.  The point
> > codes should be split out with TLV parameters similar to those
> > used to represent point codes in the DUNA and DAVA messages.  SLS
> > and SIO will require their own parameters.  Because these
> > parameters are mandatory parameters of the MTP-TRANSFER primitive,
> > it may be useful to group them and place them in a single TLV
> > as follows:
> >
> > [Greg]  Brian, this approach was considered early and had some
proponents.
> > But a choice was made for the current method.  The same appoach wasn't
> used
> > for MTP-PAUSE/RESUME/STATUS because these were generated internal to the
> SG
> > by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the SS7
> > network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It may
look
> > oddto some people but I think it works.
>
> What is the difference from extracting the PC from a TFP and putting
> it into a DUNA an extracting a PC from a routing label and putting it
> in a DATA message?  Sorry, but both are generated internal to the SG.
>
> [Greg2]  IMO the PC is not extracted from an incoming TFP and put into a
> DUNA.  Incoming TFPs are consumed by the MTP3.
>
> I think this should be re-examined.  I surely didn't hear any
> objections to this proposal.  Are there any objections out there?
>
> [Greg2] Sure, lets hear from some others - is there support for the
change?

> >
> >
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |       Service Indicator       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Where now the Protocol Data would only contain MTP-User data.
> >
> >
> > Note that I have removed the "Network Appearance" parameter.  This
> > is because it is useless.  The Network Appearance parameter is based
> > on the premise that it somehow defines the point code format used.
> > This is not the case, as the Service Indicator Octet (and NI) must
> > also be taken into consideration when determining the point code
> > format.
> >
> > [Greg] The Network Appearance indicates the SS7 network partition (SG
> > links/linksets/routes/routesets) for the messages to be sent/received at
> the
> > SG.  It is certainly not useless.  Within a network partition, only one
> > point code format would be used.
>
> But, an ASP cannot span multiple SPMCs, so the routing context
> defines the network appearance and the network appearance is redundant.
>
> [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to receive
> traffic for multiple Application Servers (with different DPC/OPCs/NIs).
Are
> you saying we need to include the Routing Context instead?  Can you fill
> this point out a bit - I don't see it yet.
>
> Thanks,
>
>    Greg
>
> >
> >
> > By the same token, Network Appearance is useless in DUNA and DAVA
> > messages.  There is no network indicator provided in MTP-PAUSE
> > and MTP-RESUME primitives.
> >
> > [Greg] The alternative was to provide a Point Code Format
field/parameter
> > and have entries for every PC permutation.  As you say the Network
> > Appearance is not passed up in MTP-PAUSE and RESUME primitives - it is
> used
> > in the M3UA to pass these primitives to the correct MTP3-User instances
at
>
> > the ASPs.  The Network Appearance was already used to direct the
> > MTP-TRANSFER primitives to the correct instance so it was re-used
instead.
>
> Again, the ASP knows the point code format from the routing context
> (because it cannot span multiple SPMCs).  The network appearance is
> redundant.
>
> >
> >
> > On the other hand, for Q.701 7.2.6 operation with indication of
> > SIF permitted in TFP/TFA messages, the Affected PC parameters of
> > DUNA and DAVA need to be expanded to include the SIF bits present
> > in these indications.
> >
> > [Greg]  This section is talking about Red Book to Blue Book link
> > interworking.  Unless anyone is building an SG with links into a Red
Book
> > MTP network (62-octet SIF maximum) I think we can ignore this.
> >
> > Cheers,
> >
> >    Greg Sidebottom
> >
> >
> > Actually, Network Appearance should be struck from the whole
> > document.
> >
> > --Brian
> >
> > --
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 26 Jun 2001 14:38:42 -0700 (PDT)
From: Jonathan Wood <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [Tsvwg] sctpsocket: Returning unsent messages
To: "sigtran" <[email-masked]>
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc
X-SMTP-HELO: patan.sun.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: patan.Sun.COM [192.18.98.43]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

> 
> > When an association closes (gracefully or non-gracefully),
> > and the caller has enabled SCTP_SEND_FAILED events, the contents
> > of the SCTP transmit queue will be returned to the caller. Section
> > 5.3.1.4 defines the following flags for each returned message:
> > 
> >     SCTP_DATA_INQUEUE - When this flag is indicated the
> >                         data was never attempted to be
> >                         sent. I.e. it was never assigned
> >                         a TSN and sent onto the wire.
> 
> Now looking at it, it seems that it is simpler to just say "the data
> has never been sent."  "Attempted to be sent" can be confusing.  And
> SCTP_DATA_INQUEUE may be confusing as data should be in the transmit 
> queue whether it has been sent or not.  Maybe we should change it
> to SCTP_DATA_UNSENT?

I find this clearer.

[snip]

> > We should also add a third flag:
> > 
> >     SCTP_DATA_SACKED  - When this flag is indicated the
> >                         data WAS assigned a TSN and sent
> >                         at least once and was acknowleged
> >                         in a gap report, but the cumulative
> >                         TSN never passed it.
> 
> Maybe Brian or other people familiar with the sigtran protocols
> can comment on this.  Do we really need to separate the sack'ed
> but not cumulatively ack'ed case?  The reason I ask is that the
> receiver is free to discard sack'ed but not cumulatively ack'ed
> data chunks.  And I believe it is better not talk about TSN in
> the API draft.  It seems to me that making this distinction is
> not that useful.  I maybe wrong.  I suggest we should include them
> both as SCTP_DATA_SENT?  This has a easier to understand semantics 
> for app programmers without the need to understand SCTP fully.
> 

I admit the difference is slim. The only reason I suggested it was the maybe
apps we haven't thought of yet might actually find it useful.

Jonathan, easily swayed on this one.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 26 Jun 2001 15:36:23 -0700 (PDT)
From: Kacheong Poon <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [Tsvwg] sctpsocket: Returning unsent messages
To: "sigtran" <[email-masked]>
X-SMTP-HELO: saturn.sun.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.9.25.2]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

> > > Maybe Brian or other people familiar with the sigtran protocols
> > > can comment on this.  Do we really need to separate the sack'ed
> > > but not cumulatively ack'ed case?  The reason I ask is that the
> > > receiver is free to discard sack'ed but not cumulatively ack'ed
> > > data chunks.  And I believe it is better not talk about TSN in
> > > the API draft.  It seems to me that making this distinction is
> > > not that useful.  I maybe wrong.  I suggest we should include them
> > > both as SCTP_DATA_SENT?  This has a easier to understand semantics
> > > for app programmers without the need to understand SCTP fully.
> > >
> > 
> > I admit the difference is slim. The only reason I suggested it
> > was the maybe apps we haven't thought of yet might actually
> > find it useful.
> > 
> > Jonathan, easily swayed on this one.
> > 
> 
> I see no reason NOT to add the SACKED as well. The information is
> there, you are already passing up chunk status.. why not
> have it passed up as well.

The main reason I think is that it is a good idea not to expose protocol
details to apps if possible.  And as I pointed out previously, something
sack'ed really does not mean much.  Data can be discarded or data may not be
able to be delivered to the app because of ordering issue.
So this is kind of ambiguous.  Brian and other have pointed out that there
is an app level control to deal with this ambiguity if an app chooses to do
this retrieval.  I don't see why we need to complicate the API for the
little ambiguous info.

							K. Poon.
							[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA06: Routing Key Management procedure
Date: Tue, 26 Jun 2001 18:48:21 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: calliope1.fm.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.233.247.10]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,
  
I have few queries/comments on Routing key procedure.

- Nitin.

1. Is RKM procedure valid for IPSP-IPSP communication as well? In either
case I think the draft can specify it clearly in section 3.5.5 and related
sections.

2. De-registration request for RK not registered through REG REQ message is
valid or not? lets say RK was statically configured at an SG which supports
both static and dynamic configuration of RKs. 

3. In section 4.3.4.1 and 4.3.4.2, The draft does not specifies any timers
associated with the REG REQ and DEREG REQ messages, I think there is a need
for timers for RKM messages, as an ASP can not wait indefinitely for the REG
RSP if SG decides to respond to REG REQ containing multiple RKs with
multiple REG RSP messages'

The timer can be similar to what we have for ASPM messages, something like
this:
   
'When ASP sends an REG REQ it starts timer T(RK-ack). If the ASP does not
receive a response to REG REQ within T(RK-ack), the ASP may restart
T(RK-ack) and resend REG REQ messages until it receives an REG REQ message.
T(RK-ack) is provisionable, with a default of n seconds. Alternatively,
retransmission of REG RSP messages may be put under control of Layer
Management'

4. Can a ASP is authorized to receive REG-REG only and not authorized to
receive DEREG-REQ, in either case the draft can specify it clearly in
section 4.3.4.2.
5. Figure for "Routing Key" parameter description can be modified to
indicate the Network Appearance (optional) as first parameter. [To comply
with section 3.3.1 stating 'Where the optional Network Appearance parameter
is present, it must be the first parameter in the message'] 6. The
'Registration Status' parameter values in REG RSP message need one more type
of error value : 'Multiple SI not supported' as none of the existing error
values cover this [In case SG optionally support only one SI in a Routing
key as per section 1.4.2.2].
7. Section 3.5.5, 3.5.6, 3.5.7 and 3.5.8 numbering is duplicated.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Tomar, Nitin" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA06: M3UA - LM interface
Date: Tue, 26 Jun 2001 19:19:34 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: thalia.fm.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.233.247.11]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

I have few comments on section 1.6.3 'Definition of the boundary between
M3UA and Layer Management'

- Nitin.

1. This section contains typo error for following Interfaces

   M-ASP ACTIVE indication: The purpose says 'LM reports it has...' which
should be
                            'M3UA reports it has..'
   Similarly, for following interfaces:
   M-ASP INACTIVE indication,
   M-AS ACTIVE indication,
   M-AS INACTIVE indication,
   M-AS DOWN indication,
   The 'Purpose' shall be changed to 'M3UA reports it has..' from 'LM
reports..'

2. I suggest adding following interfaces in this section with the statement:
   
   If dynamic registration of RK is supported by M3UA layer, the layer MAY
support 
   following additional M3UA - LM interface primitives:
   
   M-RK REG request
   Direction LM -> M3UA
   Purpose:  LM requests ASP to register RK(s) with its peer by sending REG
REQ message.
   
   M-RK REG confirm
   Direction M3UA -> LM
   Purpose:  ASP reports that it has received REG RSP message with
registration status 
             as successful from its peer. 

   M-RK REG indication
   Direction M3UA -> LM
   Purpose:  M3UA informs LM that it has successfully processed an incoming
REG REQ 
             message from its peer.

   M-RK DEREG request
   Direction LM -> M3UA
   Purpose:  LM requests ASP to de-register RK(s) with its peer by sending
DEREG REQ
             message.
                
   M-RK DEREG confirm
   Direction M3UA -> LM
   Purpose:  ASP reports that it has received DEREG RSP message with
de-registration
             status as successful from its peer. 

   M-RK DEREG indication
   Direction M3UA -> LM
   Purpose:  M3UA informs LM that it has successfully processed an incoming
DEREG REQ 
             message from its peer.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: Flow control
Date: Wed, 27 Jun 2001 00:36:52 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail3.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.90]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Nitin,

Response below ...

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Saturday, June 23, 2001 10:42 PM
Subject: M3UA06: Flow control

> Hi All,
>
> I have a query on Section 1.4.5 Flow control which says -
>
>  "Local Management at an ASP may wish to stop traffic across an SCTP
> association in order to temporarily remove the association from service or
> to perform testing and maintenance activity.  The function could
optionally
> be used to control the start of traffic on to a newly available SCTP
> association."
>
>  - My understanding of the above text is: ASP will remain in its current
>    state but is locally inhibited for outgoing traffic.
>    How the incoming traffic is to be handled at ASP in this case?
>
> Regards
> Nitin
>

[Greg] This is a pretty general section describing an ASP M3UA function to
stop traffic.  From a protocol perspective, an ASP Inactive or ASP Down
message from the ASP accomplishes this.  The intent was for traffic in both
directions to be stopped.

Hope this helps,

   Greg Sidebottom

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Wed, 27 Jun 2001 10:12:37 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x1.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x1.nokia.com [131.228.20.21]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> I was reading section 1.3.5 where it says:
> 
>     Replicated endpoints : only for the first message in a transaction
>     or connection one of the SGs is chosen, depending on the traffic
>     mode (primary/backup or loadsharing) and overoad conditions.  Once
>     selected, the same SG is used for subsequent messages.
> 
> I interpreted this as a coupling of messages in the transaction.  Have
> I somehow misinterpreted this passage?

This text does need some work.  Thanks for pointing it out.  For class 0 or
1 service, the above text is too restrictive.  

For class 2 or 3 service, it is more accurate.  The problem is how to setup
SCCP/SUA connections in this case.  What do you think? 

In current SS7, how is the connection-oriented service handled? Are the
connections replicated through different STPs?  Should we try to mimic the
behavior at the SG?

> No.  For loadsharing, the return messages can be sent via the opposite
> SG under class 2.  The restriction is too severe.

[text clipped]

> All you have
> to do is strike the text which imposes this "coupling" requirement
> and leave it to the implementor's to decide how or when to do
> "uncoupled" relay (it *is* done in SS7 networks).  Also, the addition
> of an SUA message equivalent to a N-PCSTATE primitive would 
> be helpful.

So, getting rid some text in 1.3.5 is enough for you?  Or should we just add
text to 1.3.5 that makes coupling MAY?

> Some implementations of SUA at the ASP to perform decoupling at the
> SG care.  I am just looking for text and messages which permit
> decoupling.  It appears that you want to restrict it because your
> specific and narrow application does not need it.  That is no reason
> to restrict the specification from full and seamless SCCP 
> interworking.

and

> I say again (for the fourth time): STP does not work for decoupled
> operation in classes 0 and 2.  Remove the coupling text and provide
> full point code status support for N-PCSTATE and they will.

Would changing the text to the below be sufficient, or is there something
that should be explicitly stated?

	Replicated endpoints: the coupling between the SGs and the ASPs when

	the SGs act as replicated endpoints is an implementation issue. 

thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 27 Jun 2001 09:32:56 -0400
From: Vince Deters <[email-masked]>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: SUA - Traffic Mode Type in ASP-INACTIVE ?
X-SMTP-HELO: rtp-msg-core-1.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [161.44.11.97]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Not sure if this has been discussed on the alias...

Paragraph 2 of section 4.4.2.4 of the SUA draft makes mention of "...the
Traffic Mode Type parameter in the ASP-INACTIVE..." But according to the
description in section 3.6.3, ASP-INACTIVE does not include a Traffic Mode
Type parameter.

Vince

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Date: Wed, 27 Jun 2001 10:14:28 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Kurt,

Questions/comments below ..

----- Original Message -----
From: "Kurt Kite" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, June 26, 2001 2:01 PM
Subject: Re: Packing of DATA Payloads

> Some comments in-line.
>
> /Kurt
>
> Greg Sidebottom wrote:
>
> > Thanks Brian,
> >
> > Responses below ...
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Sent: Thursday, June 21, 2001 4:41 AM
> > Subject: Re: Packing of DATA Payloads
> >
> > Greg,
> >
> > Please see comments below....
> >
> > Greg Sidebottom wrote:                          (Thu, 21 Jun 2001
03:42:09)
> > > Thanks Brian,
> > >
> > > Some responses (finally!) below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Monday, June 04, 2001 3:08 PM
> > > Subject: M3UA: Packing of DATA Payloads
> > >
> > >
> > > Greg,
> > >
> > > I see a number of difficulties in the packing and unpacking,
> > > and filtering of DATA Payload information.  Perhaps not
> > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > the MTP Routing Label in the data payload.  The MTP RL is
> > > the MTP Level 3 Header (much like an IP header) and is not
> > > part of the payload transferred to an from the MTP-User.
> > >
> > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER primitive
> > > contain the OPC, DPC, SLS and SIO.  The Routing Label format was used
for
> > > the Protocol Data parameter in the Data message so that these fields
are
> > not
> > > re-encoded across the SG.
> >
> > Ah, but they will be.  You see the SG MTP3 must unpack the routing
> > label to determine whether the MSU is a management message.  By the
> > time the MSU gets to an MTP3-User, the routing label has likely
> > been removed and placed into an internal representation.  To put
> > it back into the M3UA message would require an MTP3 routing label
> > encoder.  If you look at M3UA in a simple case where it is just
> > an MTP3-User, this is normally the case.  The MTP3-User does not
> > have (nor want) direct access to the L3 protocol header.
> >
> > [Greg2] I really cannot say whether all MTP3 implementations separate
the
> > routing label or not, or put it back in or not.  I don't really want to
get
> > into how implementations will unpack SS7 message parts into internal
> > representations and and re-pack information into M3UA DATA messages.
I'm
> > sure that there are lots of possibilities.  Separating out the Routing
> > Label, placing into an internal representation and then re-packing using
an
> > MTP3 Routing Label encoder is one method I guess.
>
> I am only familiar with 4 MTP3 implementations, but all of them separated
the
> routing
> label from the payload data when delivering a message to the user.
However, a couple
> of
> them offered a lower level interface to the MTP3 data where it was
possible to
> access a "raw"
> data message.

[Greg3] Interesting information.  My follow-on questions are:

    1) How does the SIO fit in, i.e., is it also generally separated as well
or is the SIO considered part of the Routing Label by these implementations?

    2) What would the format of the separated Routing Label be - is it is
generally left in the same received format or is it normalized into
something else?

> > >
> > > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > > following parameters:
> > >
> > >         OPC (see 2.2/Q.704)
> > >         DPC (see 2.2/Q.704)
> > >         SLS (see 2.2/Q.704)
> > >         SIO (see 14.2/Q.704)
> > >         User data (see 2.3.8/Q.703)
> > >
> > > You will find the same list of parameters in Table 9/T1.112.1.
> > >
> > > In neither list is the NI (Network Indicator) or MP (Message
> > > Priority) listed.  This is, IMHO, because the assignment of
> > > these values is to be peformed by MTP and is not at the discretion
> > > of the MTP-User.
> > >
> > > [Greg] No, the NI and MP (national use) are shown as part of the SIO
> > > Subservice Field in the relevant MTP3 recommendations (Q.704 Section
14.2
> > or
> > > national equivalent).  Q.701 Table 1 (and your list above) lists the
SIO
> > as
> > > a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
> > > details.  So IMO the SIO Subservice Field is included in the
MTP-TRANSFER
> > > and therfore the NI and MP (national variants) are there.   I'm not
sure
> > how
> > > all SS7 vendors implemented the MTP-TRANSFER primitive as it is not
> > visible,
> > > but I've always assumed that the MTP3-User assigns the Message
priority.
> > > The NI could be picked up without the MTP3-User assigning it but I'm
not
> > > sure that it really matters.
> >
> > In further discussion on SUA, it appears that MP must be assigned by
> > SCCP in some cases (MTP3 is not expected to have knowledge of SCCP
users)
> > so it should be part of the structure in some form.  I would suggest
> > unpacking it.  NI is clearly part of the MTP-SAPID and does not need to
> > be transferred.
> >
> > [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.  As
for
> > the NI, I agree it can be picked up based on the MTP-SAPID.   In an SS7
node
> > this is not an issue.  In the M3UA where the MTP3-Users are remote I
think
> > it has to be transfered - see NA response below ...
> >
> > >
> > >
> > >
> > > In comparing this primitive to the Payload Data Message (DATA)
> > > in Section 3.3.1 and bearing in mind the statements of Section
> > > 4.1.1 with regards to MTP-Transfer, and considering IPSP operation,
> > > I have the following problems:
> > >
> > > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > > MTP-User, M3UA is required to pack a routing label into the Payload
> > > of a DATA message.  Because the MTP-TRANSFER primitive does not
> > > contain NI or MP parameters, M3UA will have to generate them.
> > >
> > > [Greg] I don't agree - see above.  IMO the NI and MP are in the
> > MTP-TRANSFER
> > > primitive.
> >
> > See Al's discussion on SUA thread.
> >
> > >
> > >
> > > Also, M3UA will have to choose some variant for the packing of
> > > the DATA Payload.  The receiving M3UA will have to unpack the
> > > same data to be able to generate an MTP-TRANSFER primitive to
> > > its MTP-User.
> > >
> > > [Greg] The M3UA at the SG doesn't really have to do any choosing of
> > > variants.  The format of the incoming SIO/Routing Label/User Data is
> > already
> > > packed according to the MTP3 variant and is not changed.  The M3UA at
the
> > > receiver knows the variant used and the expectations of the format for
the
> > > upper layer primitive to the MTP3-User instance.
> >
> > With the data already unpacked from the MTP3 RL, the M3UA at the ASP
need
> > not know the RL structure to provide the MTP-TRANSFER primitive to its
> > users.  Less chance for error, less parsing/building effort.
> >
> > [Greg2] Might make things easier at the ASP but introduces complexity at
the
> > SG as it is in effect "normalizing" the MTP3 variations of SIO/RL
> > structure/semantics into the new DATA parameters.  I may be dense but
don't
> > see the net gain.  Other opinions?
>
> For those MTP3 implemenations which already break out the RL, I agree with
Brian
> that it would be simpler to just pass the RL as parameters instead of
re-encoding
> the
> RL. IMO, if the specifications indicate that the MTP-TRANSFER primitive
breaks out
> the RL from the User data then the DATA message should do the same.
>

[Greg3] I'm a little confused here by the term "re-encoding".  I think you
are saying that it is (with many MTP3 stacks) simpler to leave the RL as a
separate parameter when creating the M3UA message.  I know of one
implementation where this is not true, but I'm willing to listen.   I may be
splitting hairs but to me if the RL format is not changed when it is
separated then I wouldn't call it re-encoding to re-pack it back into the
M3UA Protocol Data parameter.

FWIW the approach in the current M3UA version is that the Routing Label/SIO
(on the wire) is not re-encoded from the MTP3 input to the M3UA output.
Whether internally to the SG the format is changed/returned is something I
really never wanted to get into.  I'm sure there are a few possibilities for
the internal handling here.

Also, the MTP specifications do not show the MTP-TRANSFER primitive as
breaking out the Routing Label - they go deeper than that, showing the
OPC/DPC/SLS separately.  I think this is where Brian is going with the
proposal, even potentially breaking down the parts of the SIO (which is
technically not part of the RL).  If this is not how these MTP3 stacks do it
now then they are stuck with "re-encoding" either way.

Cheers,

  Greg Sidebottom

> >
> >
> > >
> > >
> > >
> > > This seems ridiculous, particularly in the IPSP case, where the
> > > packing and unpacking is rather arbitrary.  It makes far more sense
> > > to pass the OPC, DPC, SLS and SIO as separate parameters of the
> > > DATA message and leave the User data from the MTP-TRANSFER primitive
> > > as the Payload Data.
> > >
> > > [Greg] The IPSP case is a little more arbitrary, as you say, but was
left
> > > consistent with the SG/ASP case.
> > >
> > >
> > > You will note that MP is *not* part of the MTP-TRANSFER primitive
> > > and there is no need to distinguish between ITU (w/o MP), ANSI,
> > > and TTC approaches in the Payload Data when the proper parameters
> > > are added to the message.  It is the responsibility of MTP Level 3
> > > to determine the Message Priority of a MTP-User message and not
> > > the responsibility of the MTP-User.  The same is true for NI and
> > > it no longer becomes necessary to include a Network Appearance
> > > parameter at all.  (More on Network Appearance later...)
> > >
> > > [Greg] I guess we don't agree - IMO the Message priority assignment is
> > done
> > > by the MTP3-User (TTC might be an exception though).
> >
> > Again, from SUA thread, SCCP must assign MP.  I don't care if it
> > is added in the structure.  Just don't leave it in the routing
> > label, and no need for differences for TTC.
> >
> > >
> > >
> > > The format of the routing label, by the way, can be dependent
> > > upon SIO, and in some networks it is.  For example, one SIO
> > > value can be assigned for National ISUP (where the routing
> > > label is formatted using, say 24-bit point code) and another
> > > assigned for International ISUP (where the routing label is
> > > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > > 2.2.1, last paragraph on Page 4.
> > >
> > > [Greg]  That is fine.  The current approach can handle this as the SIO
and
> > > Routing Label formats are not changed.
> >
> > But forces the work on the ASP when the SG MTP3 is already fitted
> > with routing label parser/generators.
> >
> > >
> > >
> > > Treating the OPC, DPC, SLS and SIO as separate from the message
> > > is no different than placing the Affected PC in a parameter for
> > > the MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives.  The point
> > > codes should be split out with TLV parameters similar to those
> > > used to represent point codes in the DUNA and DAVA messages.  SLS
> > > and SIO will require their own parameters.  Because these
> > > parameters are mandatory parameters of the MTP-TRANSFER primitive,
> > > it may be useful to group them and place them in a single TLV
> > > as follows:
> > >
> > > [Greg]  Brian, this approach was considered early and had some
proponents.
> > > But a choice was made for the current method.  The same appoach wasn't
> > used
> > > for MTP-PAUSE/RESUME/STATUS because these were generated internal to
the
> > SG
> > > by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the
SS7
> > > network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It may
look
> > > oddto some people but I think it works.
> >
> > What is the difference from extracting the PC from a TFP and putting
> > it into a DUNA an extracting a PC from a routing label and putting it
> > in a DATA message?  Sorry, but both are generated internal to the SG.
> >
> > [Greg2]  IMO the PC is not extracted from an incoming TFP and put into a
> > DUNA.  Incoming TFPs are consumed by the MTP3.
> >
> > I think this should be re-examined.  I surely didn't hear any
> > objections to this proposal.  Are there any objections out there?
> >
> > [Greg2] Sure, lets hear from some others - is there support for the
change?
>
> > >
>
> > >
> > >
> > >     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 = 28           |          Length = 24          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Originating Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Destination Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Signalling Link Selection   |       Service Indicator       |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |            Tag = 3            |             Length            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    \                                                               \
> > >    /                        Protocol Data                          /
> > >    \                                                               \
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > Where now the Protocol Data would only contain MTP-User data.
> > >
> > >
> > > Note that I have removed the "Network Appearance" parameter.  This
> > > is because it is useless.  The Network Appearance parameter is based
> > > on the premise that it somehow defines the point code format used.
> > > This is not the case, as the Service Indicator Octet (and NI) must
> > > also be taken into consideration when determining the point code
> > > format.
> > >
> > > [Greg] The Network Appearance indicates the SS7 network partition (SG
> > > links/linksets/routes/routesets) for the messages to be sent/received
at
> > the
> > > SG.  It is certainly not useless.  Within a network partition, only
one
> > > point code format would be used.
> >
> > But, an ASP cannot span multiple SPMCs, so the routing context
> > defines the network appearance and the network appearance is redundant.
> >
> > [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to
receive
> > traffic for multiple Application Servers (with different DPC/OPCs/NIs).
Are
> > you saying we need to include the Routing Context instead?  Can you fill
> > this point out a bit - I don't see it yet.
> >
> > Thanks,
> >
> >    Greg
> >
> > >
> > >
> > > By the same token, Network Appearance is useless in DUNA and DAVA
> > > messages.  There is no network indicator provided in MTP-PAUSE
> > > and MTP-RESUME primitives.
> > >
> > > [Greg] The alternative was to provide a Point Code Format
field/parameter
> > > and have entries for every PC permutation.  As you say the Network
> > > Appearance is not passed up in MTP-PAUSE and RESUME primitives - it is
> > used
> > > in the M3UA to pass these primitives to the correct MTP3-User
instances at
> >
> > > the ASPs.  The Network Appearance was already used to direct the
> > > MTP-TRANSFER primitives to the correct instance so it was re-used
instead.
> >
> > Again, the ASP knows the point code format from the routing context
> > (because it cannot span multiple SPMCs).  The network appearance is
> > redundant.
> >
> > >
> > >
> > > On the other hand, for Q.701 7.2.6 operation with indication of
> > > SIF permitted in TFP/TFA messages, the Affected PC parameters of
> > > DUNA and DAVA need to be expanded to include the SIF bits present
> > > in these indications.
> > >
> > > [Greg]  This section is talking about Red Book to Blue Book link
> > > interworking.  Unless anyone is building an SG with links into a Red
Book
> > > MTP network (62-octet SIF maximum) I think we can ignore this.
> > >
> > > Cheers,
> > >
> > >    Greg Sidebottom
> > >
> > >
> > > Actually, Network Appearance should be struck from the whole
> > > document.
> > >
> > > --Brian

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA - Traffic Mode Type in ASP-INACTIVE ?
Date: Wed, 27 Jun 2001 10:22:32 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Vince,

Thanks for catching this.  This is just some stray text that must have been
missed when Traffic Mode was removed from the ASP Inactive message.  The
"mention" should be removed.

Cheers,

   Greg Sidebottom

----- Original Message -----
From: "Vince Deters" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Wednesday, June 27, 2001 9:32 AM
Subject: SUA - Traffic Mode Type in ASP-INACTIVE ?

> Not sure if this has been discussed on the alias...
>
> Paragraph 2 of section 4.4.2.4 of the SUA draft makes mention of "...the
> Traffic Mode Type parameter in the ASP-INACTIVE..." But according to the
> description in section 3.6.3, ASP-INACTIVE does not include a Traffic
> Mode Type parameter.
>
> Vince
>
>

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M3UA06: M3UA - LM interface
Date: Wed, 27 Jun 2001 10:58:24 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail1.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail1.rdc1.on.home.com [24.2.9.88]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Nitin,

Responses below ...

----- Original Message -----
From: "Tomar, Nitin" <[email-masked]> To: "sigtran"
<[email-masked]> Sent: Tuesday, June 26, 2001 10:19 PM
Subject: M3UA06: M3UA - LM interface

> Greg,
>
> I have few comments on section 1.6.3 'Definition of the boundary between
> M3UA and Layer Management'
>
> - Nitin.
>
> 1. This section contains typo error for following Interfaces
>
>    M-ASP ACTIVE indication: The purpose says 'LM reports it has...' which
> should be
>                             'M3UA reports it has..'
>    Similarly, for following interfaces:
>    M-ASP INACTIVE indication,
>    M-AS ACTIVE indication,
>    M-AS INACTIVE indication,
>    M-AS DOWN indication,
>    The 'Purpose' shall be changed to 'M3UA reports it has..' from 'LM
> reports..'
>

[Greg] Yes, Ian Rytina caught these as well in his LB comments.  They are
fixed.

> 2. I suggest adding following interfaces in this section with the
statement:
>
>    If dynamic registration of RK is supported by M3UA layer, the layer MAY
> support
>    following additional M3UA - LM interface primitives:
>
>    M-RK REG request
>    Direction LM -> M3UA
>    Purpose:  LM requests ASP to register RK(s) with its peer by sending
REG
> REQ message.
>
>    M-RK REG confirm
>    Direction M3UA -> LM
>    Purpose:  ASP reports that it has received REG RSP message with
> registration status
>              as successful from its peer.
>
>    M-RK REG indication
>    Direction M3UA -> LM
>    Purpose:  M3UA informs LM that it has successfully processed an
incoming
> REG REQ
>              message from its peer.
>
>    M-RK DEREG request
>    Direction LM -> M3UA
>    Purpose:  LM requests ASP to de-register RK(s) with its peer by sending
> DEREG REQ
>              message.
>
>    M-RK DEREG confirm
>    Direction M3UA -> LM
>    Purpose:  ASP reports that it has received DEREG RSP message with
> de-registration
>              status as successful from its peer.
>
>    M-RK DEREG indication
>    Direction M3UA -> LM
>    Purpose:  M3UA informs LM that it has successfully processed an
incoming
> DEREG REQ
>              message from its peer.

[Greg] Also mentioned by others  - I have added your text.

Thanks,

   Greg

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Wed, 27 Jun 2001 10:00:05 -0500
From: Kurt Kite <[email-masked]>
Reply-To: [email-masked]
Organization: Ericsson North America Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr1.ericy.com [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg Sidebottom wrote:

> Thanks Kurt,
>
> Questions/comments below ..

Greg, see comments below.

/Kurt

>
>
> ----- Original Message -----
> From: "Kurt Kite" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Sent: Tuesday, June 26, 2001 2:01 PM
> Subject: Re: Packing of DATA Payloads
>
> > Some comments in-line.
> >
> > /Kurt
> >
> > Greg Sidebottom wrote:
> >
> > > Thanks Brian,
> > >
> > > Responses below ...
> > >
> > > ----- Original Message -----
> > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > To: "sigtran" <[email-masked]>
> > > Sent: Thursday, June 21, 2001 4:41 AM
> > > Subject: Re: Packing of DATA Payloads
> > >
> > > Greg,
> > >
> > > Please see comments below....
> > >
> > > Greg Sidebottom wrote:                          (Thu, 21 Jun 2001
> 03:42:09)
> > > > Thanks Brian,
> > > >
> > > > Some responses (finally!) below ...
> > > >
> > > > ----- Original Message -----
> > > > From: "Brian F. G. Bidulock" <[email-masked]>
> > > > To: "sigtran" <[email-masked]>
> > > > Sent: Monday, June 04, 2001 3:08 PM
> > > > Subject: M3UA: Packing of DATA Payloads
> > > >
> > > >
> > > > Greg,
> > > >
> > > > I see a number of difficulties in the packing and unpacking,
> > > > and filtering of DATA Payload information.  Perhaps not
> > > > suprisingly, the MTP primitive MTP-TRANSFER does not contain
> > > > the MTP Routing Label in the data payload.  The MTP RL is
> > > > the MTP Level 3 Header (much like an IP header) and is not
> > > > part of the payload transferred to an from the MTP-User.
> > > >
> > > > [Greg] Both the MTP3 SIO/Routing Label and the MTP-TRANSFER
primitive
> > > > contain the OPC, DPC, SLS and SIO.  The Routing Label format was
used
> for
> > > > the Protocol Data parameter in the Data message so that these fields
> are
> > > not
> > > > re-encoded across the SG.
> > >
> > > Ah, but they will be.  You see the SG MTP3 must unpack the routing
> > > label to determine whether the MSU is a management message.  By the
> > > time the MSU gets to an MTP3-User, the routing label has likely
> > > been removed and placed into an internal representation.  To put
> > > it back into the M3UA message would require an MTP3 routing label
> > > encoder.  If you look at M3UA in a simple case where it is just
> > > an MTP3-User, this is normally the case.  The MTP3-User does not
> > > have (nor want) direct access to the L3 protocol header.
> > >
> > > [Greg2] I really cannot say whether all MTP3 implementations separate
> the
> > > routing label or not, or put it back in or not.  I don't really want
to
> get
> > > into how implementations will unpack SS7 message parts into internal
> > > representations and and re-pack information into M3UA DATA messages.
> I'm
> > > sure that there are lots of possibilities.  Separating out the Routing
> > > Label, placing into an internal representation and then re-packing
using
> an
> > > MTP3 Routing Label encoder is one method I guess.
> >
> > I am only familiar with 4 MTP3 implementations, but all of them
separated
> the
> > routing
> > label from the payload data when delivering a message to the user.
> However, a couple
> > of
> > them offered a lower level interface to the MTP3 data where it was
> possible to
> > access a "raw"
> > data message.
> >
> > >
>
> [Greg3] Interesting information.  My follow-on questions are:
>
>     1) How does the SIO fit in, i.e., is it also generally separated as
well
> or is the SIO considered part of the Routing Label by these
implementations?

It is provided separate from the RL.

>
>
>     2) What would the format of the separated Routing Label be - is it is
> generally left in the same received format or is it normalized into
> something else?

All of the implemenations normalize the data into the following parameters
(more or less):

opc, dpc, sio, sls

Some will provide the CIC, priority, etc., as well.

>
>
> > > >
> > > > The MTP-TRANSFER primitive is defined in Q.701 as having the
> > > > following parameters:
> > > >
> > > >         OPC (see 2.2/Q.704)
> > > >         DPC (see 2.2/Q.704)
> > > >         SLS (see 2.2/Q.704)
> > > >         SIO (see 14.2/Q.704)
> > > >         User data (see 2.3.8/Q.703)
> > > >
> > > > You will find the same list of parameters in Table 9/T1.112.1.
> > > >
> > > > In neither list is the NI (Network Indicator) or MP (Message
> > > > Priority) listed.  This is, IMHO, because the assignment of
> > > > these values is to be peformed by MTP and is not at the discretion
> > > > of the MTP-User.
> > > >
> > > > [Greg] No, the NI and MP (national use) are shown as part of the SIO
> > > > Subservice Field in the relevant MTP3 recommendations (Q.704 Section
> 14.2
> > > or
> > > > national equivalent).  Q.701 Table 1 (and your list above) lists the
> SIO
> > > as
> > > > a parameter of the MTP-TRANSFER and refers to Q.704 Section 14.2 for
> > > > details.  So IMO the SIO Subservice Field is included in the
> MTP-TRANSFER
> > > > and therfore the NI and MP (national variants) are there.   I'm not
> sure
> > > how
> > > > all SS7 vendors implemented the MTP-TRANSFER primitive as it is not
> > > visible,
> > > > but I've always assumed that the MTP3-User assigns the Message
> priority.
> > > > The NI could be picked up without the MTP3-User assigning it but I'm
> not
> > > > sure that it really matters.
> > >
> > > In further discussion on SUA, it appears that MP must be assigned by
> > > SCCP in some cases (MTP3 is not expected to have knowledge of SCCP
> users)
> > > so it should be part of the structure in some form.  I would suggest
> > > unpacking it.  NI is clearly part of the MTP-SAPID and does not need
to
> > > be transferred.
> > >
> > > [Greg2] Sorry, I must of missed this SUA thread - I'll look it up.  As
> for
> > > the NI, I agree it can be picked up based on the MTP-SAPID.   In an
SS7
> node
> > > this is not an issue.  In the M3UA where the MTP3-Users are remote I
> think
> > > it has to be transfered - see NA response below ...
> > >
> > > >
> > > >
> > > >
> > > > In comparing this primitive to the Payload Data Message (DATA)
> > > > in Section 3.3.1 and bearing in mind the statements of Section
> > > > 4.1.1 with regards to MTP-Transfer, and considering IPSP operation,
> > > > I have the following problems:
> > > >
> > > > When M3UA receives an MTP-TRANSFER primitive from the NIF or
> > > > MTP-User, M3UA is required to pack a routing label into the Payload
> > > > of a DATA message.  Because the MTP-TRANSFER primitive does not
> > > > contain NI or MP parameters, M3UA will have to generate them.
> > > >
> > > > [Greg] I don't agree - see above.  IMO the NI and MP are in the
> > > MTP-TRANSFER
> > > > primitive.
> > >
> > > See Al's discussion on SUA thread.
> > >
> > > >
> > > >
> > > > Also, M3UA will have to choose some variant for the packing of
> > > > the DATA Payload.  The receiving M3UA will have to unpack the
> > > > same data to be able to generate an MTP-TRANSFER primitive to
> > > > its MTP-User.
> > > >
> > > > [Greg] The M3UA at the SG doesn't really have to do any choosing of
> > > > variants.  The format of the incoming SIO/Routing Label/User Data is
> > > already
> > > > packed according to the MTP3 variant and is not changed.  The M3UA
at
> the
> > > > receiver knows the variant used and the expectations of the format
for
> the
> > > > upper layer primitive to the MTP3-User instance.
> > >
> > > With the data already unpacked from the MTP3 RL, the M3UA at the ASP
> need
> > > not know the RL structure to provide the MTP-TRANSFER primitive to its
> > > users.  Less chance for error, less parsing/building effort.
> > >
> > > [Greg2] Might make things easier at the ASP but introduces complexity
at
> the
> > > SG as it is in effect "normalizing" the MTP3 variations of SIO/RL
> > > structure/semantics into the new DATA parameters.  I may be dense but
> don't
> > > see the net gain.  Other opinions?
> >
> > For those MTP3 implemenations which already break out the RL, I agree
with
> Brian
> > that it would be simpler to just pass the RL as parameters instead of
> re-encoding
> > the
> > RL. IMO, if the specifications indicate that the MTP-TRANSFER primitive
> breaks out
> > the RL from the User data then the DATA message should do the same.
> >
>
> [Greg3] I'm a little confused here by the term "re-encoding".  I think you
> are saying that it is (with many MTP3 stacks) simpler to leave the RL as a
> separate parameter when creating the M3UA message.  I know of one
> implementation where this is not true, but I'm willing to listen.   I may
be
> splitting hairs but to me if the RL format is not changed when it is
> separated then I wouldn't call it re-encoding to re-pack it back into the
> M3UA Protocol Data parameter.

Sorry, I was not clear. All the MTP3 implementations I have seen (which is
only 4) breakout the RL and normalize it. These implementations would
require re-encoding.
I agree that if the the RL is simply passed up as a separate parameter it is
trivial to
re-pack it into the data message.

>
>
> FWIW the approach in the current M3UA version is that the Routing
Label/SIO
> (on the wire) is not re-encoded from the MTP3 input to the M3UA output.
> Whether internally to the SG the format is changed/returned is something I
> really never wanted to get into.  I'm sure there are a few possibilities
for
> the internal handling here.
>
> Also, the MTP specifications do not show the MTP-TRANSFER primitive as
> breaking out the Routing Label - they go deeper than that, showing the
> OPC/DPC/SLS separately.  I think this is where Brian is going with the
> proposal, even potentially breaking down the parts of the SIO (which is
> technically not part of the RL).  If this is not how these MTP3 stacks do
it
> now then they are stuck with "re-encoding" either way.

I agree that there is not going to be an answer that satisfies everyone. In
the end,

there will be some work to be done regardless of the decision. I'm ok with
either decision.
Passing the RL/SIO as separate parameters would simplify my implementation
but that work
is already done.

Regards,
Kurt

>
>
> Cheers,
>
>   Greg Sidebottom
>
> > >
> > >
> > > >
> > > >
> > > >
> > > > This seems ridiculous, particularly in the IPSP case, where the
> > > > packing and unpacking is rather arbitrary.  It makes far more sense
> > > > to pass the OPC, DPC, SLS and SIO as separate parameters of the
> > > > DATA message and leave the User data from the MTP-TRANSFER primitive
> > > > as the Payload Data.
> > > >
> > > > [Greg] The IPSP case is a little more arbitrary, as you say, but was
> left
> > > > consistent with the SG/ASP case.
> > > >
> > > >
> > > > You will note that MP is *not* part of the MTP-TRANSFER primitive
> > > > and there is no need to distinguish between ITU (w/o MP), ANSI,
> > > > and TTC approaches in the Payload Data when the proper parameters
> > > > are added to the message.  It is the responsibility of MTP Level 3
> > > > to determine the Message Priority of a MTP-User message and not
> > > > the responsibility of the MTP-User.  The same is true for NI and
> > > > it no longer becomes necessary to include a Network Appearance
> > > > parameter at all.  (More on Network Appearance later...)
> > > >
> > > > [Greg] I guess we don't agree - IMO the Message priority assignment
is
> > > done
> > > > by the MTP3-User (TTC might be an exception though).
> > >
> > > Again, from SUA thread, SCCP must assign MP.  I don't care if it
> > > is added in the structure.  Just don't leave it in the routing
> > > label, and no need for differences for TTC.
> > >
> > > >
> > > >
> > > > The format of the routing label, by the way, can be dependent
> > > > upon SIO, and in some networks it is.  For example, one SIO
> > > > value can be assigned for National ISUP (where the routing
> > > > label is formatted using, say 24-bit point code) and another
> > > > assigned for International ISUP (where the routing label is
> > > > formatted using 14-bit point code).  See Q.704 (07/96) Section
> > > > 2.2.1, last paragraph on Page 4.
> > > >
> > > > [Greg]  That is fine.  The current approach can handle this as the
SIO
> and
> > > > Routing Label formats are not changed.
> > >
> > > But forces the work on the ASP when the SG MTP3 is already fitted
> > > with routing label parser/generators.
> > >
> > > >
> > > >
> > > > Treating the OPC, DPC, SLS and SIO as separate from the message
> > > > is no different than placing the Affected PC in a parameter for
> > > > the MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives.  The point
> > > > codes should be split out with TLV parameters similar to those
> > > > used to represent point codes in the DUNA and DAVA messages.  SLS
> > > > and SIO will require their own parameters.  Because these
> > > > parameters are mandatory parameters of the MTP-TRANSFER primitive,
> > > > it may be useful to group them and place them in a single TLV
> > > > as follows:
> > > >
> > > > [Greg]  Brian, this approach was considered early and had some
> proponents.
> > > > But a choice was made for the current method.  The same appoach
wasn't
> > > used
> > > > for MTP-PAUSE/RESUME/STATUS because these were generated internal to
> the
> > > SG
> > > > by MTP3, as opposed to MTP-TRANSFER which came in to the SG from the
> SS7
> > > > network already encoded (i.e., MTP3 SIO, Routing Label, ...).  It
may
> look
> > > > oddto some people but I think it works.
> > >
> > > What is the difference from extracting the PC from a TFP and putting
> > > it into a DUNA an extracting a PC from a routing label and putting it
> > > in a DATA message?  Sorry, but both are generated internal to the SG.
> > >
> > > [Greg2]  IMO the PC is not extracted from an incoming TFP and put into
a
> > > DUNA.  Incoming TFPs are consumed by the MTP3.
> > >
> > > I think this should be re-examined.  I surely didn't hear any
> > > objections to this proposal.  Are there any objections out there?
> > >
> > > [Greg2] Sure, lets hear from some others - is there support for the
> change?
> >
> > > >
> >
> > > >
> > > >
> > > >     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 = 28           |          Length = 24          |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |                     Originating Point Code                    |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |                     Destination Point Code                    |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |   Signalling Link Selection   |       Service Indicator       |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    |            Tag = 3            |             Length            |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    \                                                               \
> > > >    /                        Protocol Data                          /
> > > >    \                                                               \
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >
> > > > Where now the Protocol Data would only contain MTP-User data.
> > > >
> > > >
> > > > Note that I have removed the "Network Appearance" parameter.  This
> > > > is because it is useless.  The Network Appearance parameter is based
> > > > on the premise that it somehow defines the point code format used.
> > > > This is not the case, as the Service Indicator Octet (and NI) must
> > > > also be taken into consideration when determining the point code
> > > > format.
> > > >
> > > > [Greg] The Network Appearance indicates the SS7 network partition
(SG
> > > > links/linksets/routes/routesets) for the messages to be
sent/received
> at
> > > the
> > > > SG.  It is certainly not useless.  Within a network partition, only
> one
> > > > point code format would be used.
> > >
> > > But, an ASP cannot span multiple SPMCs, so the routing context
> > > defines the network appearance and the network appearance is
redundant.
> > >
> > > [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to
> receive
> > > traffic for multiple Application Servers (with different
DPC/OPCs/NIs).
> Are
> > > you saying we need to include the Routing Context instead?  Can you
fill
> > > this point out a bit - I don't see it yet.
> > >
> > > Thanks,
> > >
> > >    Greg
> > >
> > > >
> > > >
> > > > By the same token, Network Appearance is useless in DUNA and DAVA
> > > > messages.  There is no network indicator provided in MTP-PAUSE
> > > > and MTP-RESUME primitives.
> > > >
> > > > [Greg] The alternative was to provide a Point Code Format
> field/parameter
> > > > and have entries for every PC permutation.  As you say the Network
> > > > Appearance is not passed up in MTP-PAUSE and RESUME primitives - it
is
> > > used
> > > > in the M3UA to pass these primitives to the correct MTP3-User
> instances at
> > >
> > > > the ASPs.  The Network Appearance was already used to direct the
> > > > MTP-TRANSFER primitives to the correct instance so it was re-used
> instead.
> > >
> > > Again, the ASP knows the point code format from the routing context
> > > (because it cannot span multiple SPMCs).  The network appearance is
> > > redundant.
> > >
> > > >
> > > >
> > > > On the other hand, for Q.701 7.2.6 operation with indication of
> > > > SIF permitted in TFP/TFA messages, the Affected PC parameters of
> > > > DUNA and DAVA need to be expanded to include the SIF bits present
> > > > in these indications.
> > > >
> > > > [Greg]  This section is talking about Red Book to Blue Book link
> > > > interworking.  Unless anyone is building an SG with links into a Red
> Book
> > > > MTP network (62-octet SIF maximum) I think we can ignore this.
> > > >
> > > > Cheers,
> > > >
> > > >    Greg Sidebottom
> > > >
> > > >
> > > > Actually, Network Appearance should be struck from the whole
> > > > document.
> > > >
> > > > --Brian
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 27 Jun 2001 10:08:13 -0500
From: Jacques Rajchgod <[email-masked]>
Subject: Test suggestions
To: [email-masked]
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-SMTP-HELO: pmesmtp02.wcom.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pmesmtp02.wcom.com [199.249.20.2]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD> <BODY
bgColor=#ffffff>
<DIV><FONT face=Arial size=2><SPAN class=690360415-27062001>I am working on
testing SIGTRAN and would be interested in any testing suggestions you might
have...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=690360415-27062001>My
appreciation.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <P><FONT size=2>Jacques
Rajchgod<BR>MCI Worldcom<BR>Next Generation System Evaluation<BR>Tel: [972]
729-1487<BR>E-mail: [email-masked] </FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

</x-html>
From: Songling Yang <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Packing of DATA Payloads
Date: Wed, 27 Jun 2001 11:17:16 -0400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: ss8mail1.ss8ott
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss8.ca [209.87.228.147]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

Is it an option that we include RC parm in every DATA message? I think it
can save some msg distribution work on ASP side.

Thanks,

Songling Yang
SS8 Networks Inc. http://www.ss8networks.com Tel: 613.592.2100 ext. 3269
Fax: 613.592.9634

-----Original Message-----
>
> [Greg2] An AS cannot span multiple SPMCs.  An ASP can register to receive
> traffic for multiple Application Servers (with different DPC/OPCs/NIs).
Are
> you saying we need to include the Routing Context instead?  Can you fill
> this point out a bit - I don't see it yet.
>
> Thanks,
>
>    Greg
>

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 27 Jun 2001 10:54:06 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: scaup.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: scaup.mail.pas.earthlink.net [207.217.121.49]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

Comments below...

[email-masked] wrote:           (Wed, 27 Jun 2001 10:12:37)
> Hi Brian,
> 
> > I was reading section 1.3.5 where it says:
> > 
> >     Replicated endpoints : only for the first message in a transaction
> >     or connection one of the SGs is chosen, depending on the traffic
> >     mode (primary/backup or loadsharing) and overoad conditions.  Once
> >     selected, the same SG is used for subsequent messages.
> > 
> > I interpreted this as a coupling of messages in the transaction.  Have
> > I somehow misinterpreted this passage?
> 
> This text does need some work.  Thanks for pointing it out.  For class
> 0 or 1 service, the above text is too restrictive.  
> 
> For class 2 or 3 service, it is more accurate.  The problem is how
> to setup SCCP/SUA connections in this case.  What do you think? 

It is only really accurate for class 3 operation.  Classes 0, 1 and 2 can
handle a change in SG due to failures or congestion in the SS7 network.

> 
> In current SS7, how is the connection-oriented service handled? Are
> the connections replicated through different STPs?  Should we try to
> mimic the behavior at the SG?

For CO operation whether the connection is "coupled" through the STP depends
on network configuration and the operator's selection of GTT points.

> 
> 
> > No.  For loadsharing, the return messages can be sent via the opposite
> > SG under class 2.  The restriction is too severe.
> 
> [text clipped]
> 
> > All you have
> > to do is strike the text which imposes this "coupling" requirement
> > and leave it to the implementor's to decide how or when to do
> > "uncoupled" relay (it *is* done in SS7 networks).  Also, the addition
> > of an SUA message equivalent to a N-PCSTATE primitive would 
> > be helpful.
> 
> So, getting rid some text in 1.3.5 is enough for you?  Or should we
> just add text to 1.3.5 that makes coupling MAY?

There may be other places in the text (I will look), but the more
restrictive statements from section 6 of the previous version have been
removed?  I would prefer the text removed since the coupling MAY or MAY NOT
be applicable depending on class and network configuration.

> 
> > Some implementations of SUA at the ASP to perform decoupling at the
> > SG care.  I am just looking for text and messages which permit
> > decoupling.  It appears that you want to restrict it because your
> > specific and narrow application does not need it.  That is no reason
> > to restrict the specification from full and seamless SCCP 
> > interworking.
> 
> and
> 
> > I say again (for the fourth time): STP does not work for decoupled
> > operation in classes 0 and 2.  Remove the coupling text and provide
> > full point code status support for N-PCSTATE and they will.
> 
> Would changing the text to the below be sufficient, or is there something
> that should be explicitly stated?
> 
> 	Replicated endpoints: the coupling between the SGs and the ASPs when
> 
> 	the SGs act as replicated endpoints is an implementation issue. 

That's a start; but, I think that it is also necessary to provide the ASP
SUA with the necessary information to make a proper SG selection in the
multiple SG case.  This would include signalling route set status at the SG
being communicated to the ASP SUA in support of N-PCSTATE primitives and in
support of SG selection.  This must include restriction of SGs.

-- 
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]
Date: Wed, 27 Jun 2001 12:12:46 -0500
From: Jacques Rajchgod <[email-masked]>
Subject: M2PA
To: "sigtran" <[email-masked]>
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-SMTP-HELO: pmesmtp01.wcom.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pmesmtp01.wcom.com [199.249.20.1]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD> <BODY
bgColor=#ffffff>
<DIV><FONT face=Arial size=2><SPAN class=840432616-27062001>I just heard of
a new Transport protocol called "M2PA". What is "M2PA"? (What does the "P"
stand for?)</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Jacques Rajchgod<BR>MCI Worldcom<BR>Next Generation System
Evaluation<BR>Tel: [972] 729-1487<BR>E-mail: [email-masked]
</FONT></P>
<DIV>&nbsp;</DIV>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 27 Jun 2001 13:24:23 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2PA
X-SMTP-HELO: pentagon.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pentagon.cisco.com [161.44.85.169]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Jacques,

Take a look at:

    draft-ietf-sigtran-m2pa-02.txt

SS7 MTP2-User Peer-to-Peer Adaptation Layer

Regards,

Ken

At 12:12 PM 6/27/01 -0500, you wrote:
>I just heard of a new Transport protocol called "M2PA". What is "M2PA"?
(What does the "P" stand for?)
>  
>
>Jacques Rajchgod
>MCI Worldcom
>Next Generation System Evaluation
>Tel: [972] 729-1487
>E-mail: [email-masked] 
>  
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Kevin McCandless <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA
Date: Wed, 27 Jun 2001 14:03:57 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: rainier.illuminet.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.116.20.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD> <BODY
bgColor=#ffffff>
<DIV><SPAN class=227480121-27062001><FONT face=Arial color=#0000ff size=2>P
stands peer.&nbsp; The M2PA is for peer to peer connection; SG to SG.&nbsp;
M2PA would be used when you would have two IP enabled switches back to back
like a mated pair or quad.</FONT></SPAN></DIV> <DIV><SPAN
class=227480121-27062001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=227480121-27062001><FONT face=Arial color=#0000ff size=2>
<P><FONT face="Lucida Calligraphy">Kevin McCandless</FONT> <BR><FONT
face=Arial size=2>Senior Network Planner</FONT> <BR><FONT face=Arial
size=2>Illuminet</FONT> <BR><FONT face=Arial size=2>913-814-6397</FONT>
<BR><FONT face=Arial size=2>[email-masked]</FONT>
</P></FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Jacques Rajchgod 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, June 27,
2001 
  12:13 PM<BR><B>To:</B> sigtran<BR><B>Subject:</B>
M2PA<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN class=840432616-27062001>I just heard
of a 
  new Transport protocol called "M2PA". What is "M2PA"? (What does the "P"
stand 
  for?)</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P><FONT size=2>Jacques Rajchgod<BR>MCI Worldcom<BR>Next Generation System

  Evaluation<BR>Tel: [972] 729-1487<BR>E-mail: [email-masked] 
  </FONT></P>
  <DIV>&nbsp;</DIV>---<BR>You are currently subscribed to sigtran as: 
  [email-masked]<BR>To unsubscribe send a blank email to 
  [email-masked] </BLOCKQUOTE> ---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
From: "Kendall, Greg" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Definition of "endpoints"
Date: Wed, 27 Jun 2001 15:57:30 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: smtp.nlc.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp.nlc.com [209.204.132.15]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I think I've misunderstood the following line in rfc2960, p12

"Two SCTP endpoints MUST NOT have more than one SCTP association between
them at any given time."

I think that because it seem pretty clear that the m2pa draft (ver 02) is
talking about what I would have considered 2 associations between an
endpoint (in 4.1.2 Link Alignment).  However, this goes away if an
"endpoint" is defined in terms of an IP address.  Is this the correct
interpretation?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Thu, 28 Jun 2001 10:46:06 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap111.atea.be [194.78.143.111]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian, John,

Some comments and possible other problems below ;)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent:
woensdag 27 juni 2001 9:13
To: sigtran
Subject: RE: SUA5: SG Relay Problems

Hi Brian,

> I was reading section 1.3.5 where it says:
> 
>     Replicated endpoints : only for the first message in a transaction
>     or connection one of the SGs is chosen, depending on the traffic
>     mode (primary/backup or loadsharing) and overoad conditions.  Once
>     selected, the same SG is used for subsequent messages.
> 
> I interpreted this as a coupling of messages in the transaction.  Have
> I somehow misinterpreted this passage?

This text does need some work.  Thanks for pointing it out.  For class 0 or
1 service, the above text is too restrictive.

[GV] : Hm, I agree. Connectionless messages (TCAP transactions) can take
either SG still, in either direction (provided "in-sequence-delivery etc
etc). But there is one caveat : since SUA doesn't have
segmenting/reassembly, each XUDT segment belonging to the same message
should "visit" the same SG, where they are assembled into 1 CLDT. The
alternative is to still support segmenting/reassembly, but for SUA I'd
really wanted to get rid of these UDT/XUDT/LUDT distinctions. I think most
(all?) of the authors agreed on that, to keep SCCP interworking problems at
the SG.

So, this might cause a problem when an XUDT segment lands on the "wrong" SG
due to route/linkset failures. May I propose following procedure ? Feel free
to shoot holes in it :))))

"If an SG is in mated pair configuration (either SEP/STP), and it receives a
non-first XUDT segment for which no reassembly process exists, it should
pass this segment to it's mate (assuming there's an SCTP association between
them); unless of course it was received from it's mate : then it's time to
issue an XUDTS (segmentation error) back to the SEP."

Or would this be overkill ?

For class 2 or 3 service, it is more accurate.  The problem is how to setup
SCCP/SUA connections in this case.  What do you think? 
In current SS7, how is the connection-oriented service handled? Are the
connections replicated through different STPs?  Should we try to mimic the
behavior at the SG?

> No.  For loadsharing, the return messages can be sent via the opposite
> SG under class 2.  The restriction is too severe.

[text clipped]

> All you have
> to do is strike the text which imposes this "coupling" requirement
> and leave it to the implementor's to decide how or when to do
> "uncoupled" relay (it *is* done in SS7 networks).  Also, the addition
> of an SUA message equivalent to a N-PCSTATE primitive would 
> be helpful.

So, getting rid some text in 1.3.5 is enough for you?  Or should we just add
text to 1.3.5 that makes coupling MAY?

> Some implementations of SUA at the ASP to perform decoupling at the
> SG care.  I am just looking for text and messages which permit
> decoupling.  It appears that you want to restrict it because your
> specific and narrow application does not need it.  That is no reason
> to restrict the specification from full and seamless SCCP 
> interworking.

and

> I say again (for the fourth time): STP does not work for decoupled
> operation in classes 0 and 2.  Remove the coupling text and provide
> full point code status support for N-PCSTATE and they will.

Would changing the text to the below be sufficient, or is there something
that should be explicitly stated?

	Replicated endpoints: the coupling between the SGs and the ASPs when

	the SGs act as replicated endpoints is an implementation issue.

[GV] : The N-PCSTATE is (already ?) covered by the DUNA/DAVA/SCON messages,
with a PC as address information. If the ASPs are concerned, they can keep
track of any PC's status. However, we should include an extra chapter (4.3.3
?) about SUA management to describe these procedures more accurately
(explanation with the messages themselves is not enough). Try to make some
draft text as soon as possible. Brian, would this be satisfactory ?

For the coupling of connection sections : alas no address information is
present in the CODT and subsequent messages, just a destination local
reference ... so I still would feel unhappy to just make it an
implementation issue. But supposing a different SG (we should start talking
about SGPs rather than SGs) is only chosen in case of link/association
failures, we could adopt the procedure as proposed for the XUDTs ?

P.S. Brian, I'm always open to suggestions/improvements, but you have a
tendency to get on the wrong side of people sometimes.
Anyway, I agree another thread should be started on the problem "how does
the UA know that SCTP has really delivered a message". Do we just assume
SCTP is as reliable as MTP ??

____________________________

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 28 Jun 2001 16:09:55 +0530
From: Vijay Kumar Choudhary <[email-masked]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
To: "sigtran" <[email-masked]>
Subject: Re: Definition of "endpoints"
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,

   An  application  on  a  host  is  said  to  be  multihomed  if  it  has
one  IP address  and  more  than one port number.

   An  application  on  a  host  is  said  to  be  multihomed  if  it  has
more  than one  IP  address  but only one  port number.

Which of the above statement is true??
Regards,
Vijay

"Antonio Alonso Alarcon EEM/TL/NA TU-148 Tlf.3085" wrote:

> Hi !
>
>    This is almost true. But take into account that, in a multihomed host
> (for example, with 2 different IP adresses defined: IP_1 and IP_2) you
> could have, in the same port (say port X), two different SCTP endpoints,
> one in <port X, IP_1> and other in <port X, IP_2>.
>
> Antonio
>
>
> > An SCTP endpoint can use multiple IP addresses that the host owns, but
it
> > must use the same port number.
> > That is to say, it is the Port Number that identifies the specific
endpoint
> > in one host.
> >
> > Le Yanqun
> >
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, June 28, 2001 2:30 PM
> > To: sigtran
> > Cc: [email-masked]
> > Subject: Re: Definition of "endpoints"
> >
> >
> > Greg,
> >
> > I think that you'll find that the definition of endpoint includes
> > port number, and, as such, is a rather trivial statement that the
> > cardinality of associations can only be determined by the uniqueness
> > of endpoints.
> >
> > --Brian
> >
> > Kendall, Greg wrote:                          (Wed, 27 Jun 2001
15:57:30)
> > >
> > > I think I've misunderstood the following line in rfc2960, p12
> > >
> > > "Two SCTP endpoints MUST NOT have more than one SCTP association
between
> > > them at any given time."
> > >
> > > I think that because it seem pretty clear that the m2pa draft (ver 02)
is
> > > talking about what I would have considered 2 associations between an
> > > endpoint (in 4.1.2 Link Alignment).  However, this goes away if an
> > > "endpoint" is defined in terms of an IP address.  Is this the correct
> > > interpretation?
> > >
> >
> > --
> > 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]
> >
> >
> > ---
> > You are currently subscribed to sigtran as:
[email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> >
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 28 Jun 2001 16:15:06 +0530
From: Vijay Kumar Choudhary <[email-masked]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
To: "sigtran" <[email-masked]>
Subject: Cookie-Mechanism...
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All,
    We have multiple streams to avoid head of line blocking in TCP. To avoid
SYN attack (in TCP), we do not keep the TCB every time, we get INIT.

    But what problem(in TCP) is solved by using cookie mechanism??

Regards,
Vijay

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Tuexen Michael <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Definition of "endpoints"
Date: Thu, 28 Jun 2001 12:57:27 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: gorilla.mchh.siemens.de
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: gorilla.mchh.siemens.de [194.138.158.18]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear  Vijay,
a host is multihomed if it has multiple IP addresses, not an applicaion.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210 Siemens AG        Fax:    +49 89
722 48212 ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Vijay Kumar Choudhary [SMTP:[email-masked]]
> Sent:	Thursday, June 28, 2001 12:40 PM
> To:	sigtran
> Subject:	Re: Definition of "endpoints"
> 
> Hi All,
> 
>    An  application  on  a  host  is  said  to  be  multihomed  if  it  has
one  IP
> address  and  more  than one port number.
> 
>    An  application  on  a  host  is  said  to  be  multihomed  if  it  has
more  than
> one  IP  address  but only one  port number.
> 
> Which of the above statement is true??
> Regards,
> Vijay
> 
> 
> "Antonio Alonso Alarcon EEM/TL/NA TU-148 Tlf.3085" wrote:
> 
> > Hi !
> >
> >    This is almost true. But take into account that, in a multihomed host
> > (for example, with 2 different IP adresses defined: IP_1 and IP_2) you
> > could have, in the same port (say port X), two different SCTP endpoints,
> > one in <port X, IP_1> and other in <port X, IP_2>.
> >
> > Antonio
> >
> >
> > > An SCTP endpoint can use multiple IP addresses that the host owns, but
it
> > > must use the same port number.
> > > That is to say, it is the Port Number that identifies the specific
endpoint
> > > in one host.
> > >
> > > Le Yanqun
> > >
> > > -----Original Message-----
> > > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, June 28, 2001 2:30 PM
> > > To: sigtran
> > > Cc: [email-masked]
> > > Subject: Re: Definition of "endpoints"
> > >
> > >
> > > Greg,
> > >
> > > I think that you'll find that the definition of endpoint includes
> > > port number, and, as such, is a rather trivial statement that the
> > > cardinality of associations can only be determined by the uniqueness
> > > of endpoints.
> > >
> > > --Brian
> > >
> > > Kendall, Greg wrote:                          (Wed, 27 Jun 2001
15:57:30)
> > > >
> > > > I think I've misunderstood the following line in rfc2960, p12
> > > >
> > > > "Two SCTP endpoints MUST NOT have more than one SCTP association
between
> > > > them at any given time."
> > > >
> > > > I think that because it seem pretty clear that the m2pa draft (ver
02) is
> > > > talking about what I would have considered 2 associations between an
> > > > endpoint (in 4.1.2 Link Alignment).  However, this goes away if an
> > > > "endpoint" is defined in terms of an IP address.  Is this the
correct
> > > > interpretation?
> > > >
> > >
> > > --
> > > 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]
> > >
> > >
> > > ---
> > > You are currently subscribed to sigtran as:
[email-masked]
> > > To unsubscribe send a blank email to
[email-masked]
> > >
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
[email-masked]
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 28 Jun 2001 13:32:10 +0100
From: Joyce Archibald <[email-masked]>
Organization: Agilent Technologies UK Ltd
X-Mailer: Mozilla 4.76 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
X-SMTP-HELO: msgbas1.cos.agilent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: msgbas1x.cos.agilent.com [192.6.9.33]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian, Greg,

I take your point that if all pointcodes are converted to 24-bit numbers,
then it is not essential that the original format is known.

Using your proposed new format for the DATA message:

>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |       Service Indicator       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Where now the Protocol Data would only contain MTP-User data.

Presumably, this should now be updated to include the Routing Context.
Are you proposing to add the ASP Id as a further parameter or are you saying
that this is implied by the Routing Context?

May I suggest:-

Payload Data Message
    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 = 28           |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Originating Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Point Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Signalling Link Selection   |  Network Id.  |  Service Ind. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 6            |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Routing Context                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If there is only one network partition, then the Network Id could optionally
be set to zero.

This would not increase the overall size of the message.

The Routing Key parameter surely needs some way of distinguishing pointcodes
from different networks. So if the Network Appearance parameter is removed,
a Network Id will be needed instead.

Perhaps it would help if I explain why a Network Id is needed by some
applications of Protocol Analysers & Link Monitoring Systems.

1. It is essential to know if messages containing the same pointcode
   actually refer to signalling points in different networks. Thus
   if an SG is connected to multiple networks it could refer to them
   using different locally defined Network Ids.

2. If a Protocol Analyser has to wait to see Routing Key Management
   messages, which I assume are fairly rare, before knowing which
   network a message belongs too, then it is less useful to its user
   than it might have been. Even permanently installed link monitoring
   systems cannot guarantee to see absolutely every message due to
   maintenance outages.

3. Clearly Analysers & Monitoring Systems need to acquire information
   about system configuration, but there's a big difference between
   knowing which Network Ids a signalling gateway is connected to and
   obtaining information about dynamically changing Routing Contexts.

Regards,
Joyce

-- 
================================================================== Joyce
Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521 Agilent Technologies
UK Ltd  | Telnet:   313 2521 South Queensferry,           | Mailstop:
SQFRD3A EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Thu, 28 Jun 2001 16:35:12 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x3.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [131.228.20.26]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,

> [GV] : Hm, I agree. Connectionless messages (TCAP 
> transactions) can take either SG still, in either direction (provided 
> "in-sequence-delivery etc). But there is one caveat : since SUA doesn't
have
> segmenting/reassembly, each XUDT segment belonging to the same message
> should "visit" the same SG, where they are assembled into 1 CLDT. The
> alternative is to still support segmenting/reassembly, but for SUA I'd
> really wanted to get rid of these UDT/XUDT/LUDT distinctions. 
> I think most (all?) of the authors agreed on that, to keep SCCP 
> interworking problems at the SG.

Yes.

> So, this might cause a problem when an XUDT segment lands on 
> the "wrong" SG
> due to route/linkset failures. May I propose following 
> procedure ? Feel free to shoot holes in it :))))
> 
> "If an SG is in mated pair configuration (either SEP/STP), 
> and it receives a
> non-first XUDT segment for which no reassembly process 
> exists, it should
> pass this segment to it's mate (assuming there's an SCTP 
> association between
> them); unless of course it was received from it's mate : then 
> it's time to
> issue an XUDTS (segmentation error) back to the SEP."
> 
> Or would this be overkill ?

I'd simply say that all XUDT messages must be reassembled before being
passed to the ASP.  If it is not possible to do so (for any reason) then a
XUDTS (segmentation error) must be sent back to the SEP.

End of story.

> [GV] : The N-PCSTATE is (already ?) covered by the DUNA/DAVA/SCON 
> messages, with a PC as address information. If the ASPs are concerned, 
> they can keep track of any PC's status. However, we should include an 
> extra chapter (4.3.3 ?) about SUA management to describe these procedures 
> more accurately (explanation with the messages themselves is not enough). 
> Try  tomake some draft text as soon as possible. Brian, would this be 
> satisfactory ?

agreed.

> For the coupling of connection sections : alas no address 
> information is
> present in the CODT and subsequent messages, just a destination local
> reference ... so I still would feel unhappy to just make it an
> implementation issue. But supposing a different SG (we should 
> start talking
> about SGPs rather than SGs) is only chosen in case of link/association
> failures, we could adopt the procedure as proposed for the XUDTs ?

Hmm, I have to think about what would be needed to accomplish this.
Essentially, the ASP would have n (SUA) connections to n SGs (or SGPs).  I
suppose the ASP & SGP could keep track of these SUA connections.  

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Thu, 28 Jun 2001 16:37:30 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x1.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x1.nokia.com [131.228.20.21]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> > For class 2 or 3 service, it is more accurate.  The problem is how
> > to setup SCCP/SUA connections in this case.  What do you think? 
> 
> It is only really accurate for class 3 operation.  Classes 0, 1 and 2
> can handle a change in SG due to failures or congestion in the SS7
> network.

OK..
 
> > 
> > In current SS7, how is the connection-oriented service handled? Are
> > the connections replicated through different STPs?  Should we try to
> > mimic the behavior at the SG?
> 
> For CO operation whether the connection is "coupled" through the
> STP depends on network configuration and the operator's selection
> of GTT points.

OK.

> > So, getting rid some text in 1.3.5 is enough for you?  Or should we
> > just add text to 1.3.5 that makes coupling MAY?
> 
> There may be other places in the text (I will look), but the more
> restrictive statements from section 6 of the previous version have
> been removed?  I would prefer the text removed since the coupling
> MAY or MAY NOT be applicable depending on class and network
> configuration.

Sounds OK.

> > Would changing the text to the below be sufficient, or is 
> there something
> > that should be explicitly stated?
> > 
> > 	Replicated endpoints: the coupling between the SGs and 
> >   the ASPs when the SGs act as replicated endpoints is an 
> >   implementation issue. 
> 
> That's a start; but, I think that it is also necessary to provide the
> ASP SUA with the necessary information to make a proper SG selection
> in the multiple SG case.  This would include signalling route 
> set status at the SG being communicated to the ASP SUA in support of 
> N-PCSTATE primitives and in support of SG selection.  This must include 
> restriction of SGs.

So, you are making two points here:

1) ASPs would need to have certain info in order to make a SG selection when
multiple SGs exist.

2) Support for N-PCSTATE.  

I'm not so clear as to what is missing.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: SUA - Traffic Mode Type in ASP-INACTIVE ?
Date: Thu, 28 Jun 2001 16:42:37 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x2.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x2.nokia.com [131.228.20.22]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Vince,

> Not sure if this has been discussed on the alias...
> 
> Paragraph 2 of section 4.4.2.4 of the SUA draft makes mention 
> of "...the
> Traffic Mode Type parameter in the ASP-INACTIVE..." But 
> according to the
> description in section 3.6.3, ASP-INACTIVE does not include a Traffic
> Mode Type parameter.

Thanks for the catch. The text is now updated.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 28 Jun 2001 12:30:13 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: avocet.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [207.217.121.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Joyce,

Please see comments below:

Joyce Archibald wrote:                           (Thu, 28 Jun 2001 13:32:10)
> Hi Brian, Greg,
> 
> I take your point that if all pointcodes are converted to 24-bit
> numbers,
> then it is not essential that the original format is known.
> 
> Using your proposed new format for the DATA message:
> 
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |       Service Indicator       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Where now the Protocol Data would only contain MTP-User data.
> 
> Presumably, this should now be updated to include the Routing Context.
> Are you proposing to add the ASP Id as a further parameter or are you 
> saying that this is implied by the Routing Context?
> 
> May I suggest:-
> 
> Payload Data Message
>     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 = 28           |          Length = 24          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Originating Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Destination Point Code                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Signalling Link Selection   |  Network Id.  |  Service Ind. |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 6            |          Length = 8           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Routing Context                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Tag = 3            |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    \                                                               \
>    /                        Protocol Data                          /
>    \                                                               \
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> If there is only one network partition, then the Network Id could
> optionally be set to zero.
> 
> This would not increase the overall size of the message.
> 
> The Routing Key parameter surely needs some way of distinguishing
> pointcodes from different networks. So if the Network Appearance
> parameter is removed, a Network Id will be needed instead.
> 
> Perhaps it would help if I explain why a Network Id is needed by some
> applications of Protocol Analysers & Link Monitoring Systems.

What is the "Network Id"?  How does the SG derive this?  If you are talking
about the NI bits in an MSU, they may be different for different links for
the same point code in the same network.  Also, in some circumstances, NI
bits are used to extend the point code by two bits.

> 
> 1. It is essential to know if messages containing the same pointcode
>    actually refer to signalling points in different networks. Thus
>    if an SG is connected to multiple networks it could refer to them
>    using different locally defined Network Ids.

This can be accomplished by placing a routing context in the message.
Nevertheless, I don't believe the situation you describe cannot occur
because an ASP cannot span multiple SPMCs (point-codes).

> 
> 2. If a Protocol Analyser has to wait to see Routing Key Management
>    messages, which I assume are fairly rare, before knowing which
>    network a message belongs too, then it is less useful to its user
>    than it might have been. Even permanently installed link monitoring
>    systems cannot guarantee to see absolutely every message due to
>    maintenance outages.

There is nothing restricting an SG from assigning a fixed routing context to
each of its routing keys.  I would suggest that if a network operator wishes
to attach fixed monitoring equipment to their network that they require that
the SG implementation assign fixed routing contexts to routing keys.

> 
> 3. Clearly Analysers & Monitoring Systems need to acquire information
>    about system configuration, but there's a big difference between
>    knowing which Network Ids a signalling gateway is connected to and
>    obtaining information about dynamically changing Routing Contexts.

Don't allow routing contexts to change dynamically with respect to routing
keys.  The spec does not require them to change dynamically with respect to
routing keys.  It only requires the SG to inform the ASP of the mapping
between routing key and routing context at the time of registration.
Presumably the ASP doesn't need to know this information in advance.

If the algorithm used at the SG is a simple static mapping of RK to RC, the
protocol analyzer or monitoring box can be provisioned with the same
mapping.  End of problem.

-- 
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]
Date: Thu, 28 Jun 2001 12:40:24 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: snipe.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [207.217.120.62]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gery,

Comments below...

Verwimp Gery wrote:                            (Thu, 28 Jun 2001 10:46:06)
> Hi Brian, John,
> 
> Some comments and possible other problems below ;)
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: woensdag 27 juni 2001 9:13
> To: sigtran
> Subject: RE: SUA5: SG Relay Problems
> 
> 
> Hi Brian,
> 
> > I was reading section 1.3.5 where it says:
> > 
> >     Replicated endpoints : only for the first message in a transaction
> >     or connection one of the SGs is chosen, depending on the traffic
> >     mode (primary/backup or loadsharing) and overoad conditions.  Once
> >     selected, the same SG is used for subsequent messages.
> > 
> > I interpreted this as a coupling of messages in the transaction.  Have
> > I somehow misinterpreted this passage?
> 
> This text does need some work.  Thanks for pointing it out.  For class
> 0 or 1 service, the above text is too restrictive.
> 
> >>>>>>>>>>>>>>>
> [GV]: Hm, I agree. Connectionless messages (TCAP transactions) can take
> either SG still, in either direction (provided "in-sequence-delivery etc
> etc). But there is one caveat : since SUA doesn't have
> segmenting/reassembly, each XUDT segment belonging to the same message
> should "visit" the same SG, where they are assembled into 1 CLDT. The
> alternative is to still support segmenting/reassembly, but for SUA I'd
> really wanted to get rid of these UDT/XUDT/LUDT distinctions. I think most
> (all?) of the authors agreed on that, to keep SCCP interworking problems
at
> the SG.
> 
> So, this might cause a problem when an XUDT segment lands on the "wrong"
SG
> due to route/linkset failures. May I propose following procedure ? Feel
free
> to shoot holes in it :))))
> 
> "If an SG is in mated pair configuration (either SEP/STP), and it receives
a
> non-first XUDT segment for which no reassembly process exists, it should
> pass this segment to it's mate (assuming there's an SCTP association
between
> them); unless of course it was received from it's mate : then it's time to
> issue an XUDTS (segmentation error) back to the SEP."
> 
> Or would this be overkill ?
> >>>>>>>>>>>>>>>

If you require reassembly at the SG, you will break class 0 operation for
STPs again.  When the SG is acting as an STP for class 0 operation it cannot
be guaranteed that all of the  segments beloning to the same NSDU will
arrive at one of the STPs, for any message.  In the case of multiple SGs
acting as STPs, the SUA at the ASP must do reassembly for class 0 operation
(at least).

> 
> For class 2 or 3 service, it is more accurate.  The problem is how
> to setup SCCP/SUA connections in this case.  What do you think? 
> In current SS7, how is the connection-oriented service handled? Are
> the connections replicated through different STPs?  Should we try to
> mimic the behavior at the SG?
> 
> > No.  For loadsharing, the return messages can be sent via the opposite
> > SG under class 2.  The restriction is too severe.
> 
> [text clipped]
> 
> > All you have
> > to do is strike the text which imposes this "coupling" requirement
> > and leave it to the implementor's to decide how or when to do
> > "uncoupled" relay (it *is* done in SS7 networks).  Also, the addition
> > of an SUA message equivalent to a N-PCSTATE primitive would 
> > be helpful.
> 
> So, getting rid some text in 1.3.5 is enough for you?  Or should we
> just add text to 1.3.5 that makes coupling MAY?
> 
> > Some implementations of SUA at the ASP to perform decoupling at the
> > SG care.  I am just looking for text and messages which permit
> > decoupling.  It appears that you want to restrict it because your
> > specific and narrow application does not need it.  That is no reason
> > to restrict the specification from full and seamless SCCP 
> > interworking.
> 
> and
> 
> > I say again (for the fourth time): STP does not work for decoupled
> > operation in classes 0 and 2.  Remove the coupling text and provide
> > full point code status support for N-PCSTATE and they will.
> 
> Would changing the text to the below be sufficient, or is there something
> that should be explicitly stated?
> 
> 	Replicated endpoints: the coupling between the SGs and the ASPs when
> 
> 	the SGs act as replicated endpoints is an implementation issue.
> 
> 
> >>>>>>>>>>>>>>>
> [GV]: The N-PCSTATE is (already ?) covered by the DUNA/DAVA/SCON messages,
> with a PC as address information. If the ASPs are concerned, they can keep
> track of any PC's status. However, we should include an extra chapter
> (4.3.3 ?) about SUA management to describe these procedures more
accurately
> (explanation with the messages themselves is not enough). Try to make some
> draft text as soon as possible. Brian, would this be satisfactory ?

Yes, just as long as the DUNA/DAVA/SCON messages can be made to include only
a point code (with no subsystem number), then they could be used to indicate
what is required.  (Does SCON provide for multiple congestion levels?)  In
addition, however, the ASP needs to keep track of the "restricted" status of
the SGs similar to the DRST message in M3UA.

> 
> For the coupling of connection sections : alas no address information is
> present in the CODT and subsequent messages, just a destination local
> reference ... so I still would feel unhappy to just make it an
> implementation issue. But supposing a different SG (we should start
talking
> about SGPs rather than SGs) is only chosen in case of link/association
> failures, we could adopt the procedure as proposed for the XUDTs ?
> >>>>>>>>>>>>>>>
> 
> P.S. Brian, I'm always open to suggestions/improvements, but you have a
> tendency to get on the wrong side of people sometimes.
> Anyway, I agree another thread should be started on the problem "how does
> the UA know that SCTP has really delivered a message". Do we just assume
> SCTP is as reliable as MTP ??

SCTP cannot be made as reliable as MTP using the same trasmission facilities
without additional procedures.  This is because SCTP only provides
retransmission mechanisms (multi-homing) on a nodal basis (host) whereas MTP
provides it on a network basis (associated/mated pairs).  It is in trying to
provide failover between multiple SCTP associations that the changeover
techniques of MTP are required to bring SCTP up to MTP's reliability.

-- 
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]
Date: Thu, 28 Jun 2001 12:47:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: scaup.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: scaup.mail.pas.earthlink.net [207.217.121.49]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

John,

[email-masked] wrote:           (Thu, 28 Jun 2001 16:37:30) [snip]
> 
> > > Would changing the text to the below be sufficient, or is 
> > there something
> > > that should be explicitly stated?
> > > 
> > > 	Replicated endpoints: the coupling between the SGs and 
> > >   the ASPs when the SGs act as replicated endpoints is an 
> > >   implementation issue. 
> > 
> > That's a start; but, I think that it is also necessary to provide the
> > ASP SUA with the necessary information to make a proper SG selection
> > in the multiple SG case.  This would include signalling route 
> > set status at the SG being communicated to the ASP SUA in support of 
> > N-PCSTATE primitives and in support of SG selection.  This must include 
> > restriction of SGs.
> 
> So, you are making two points here:
> 
> 1) ASPs would need to have certain info in order to make a SG selection
> when multiple SGs exist.
> 
> 2) Support for N-PCSTATE.  
> 
> I'm not so clear as to what is missing.
> 
Nothing earth-shattering, just an indication of routset (rather than
subsystem) availability and congestion, and indication of routeset
restriction via an SG.

-- 
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]
Sender: [email-masked]
Date: Thu, 28 Jun 2001 11:28:53 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: Re: Cookie-Mechanism...
X-SMTP-HELO: drawbridge.ascend.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: drawbridge.ascend.com [198.4.92.1]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

We cannot just discard the TCB. We put it into the cookie (compressed).
That's what the cookie is for.

Vijay Kumar Choudhary wrote:
> 
> Hi All,
>     We have multiple streams to avoid head of line blocking in TCP. To
> avoid SYN attack (in TCP), we do not keep the TCB every time, we get
> INIT.
> 
>     But what problem(in TCP) is solved by using cookie mechanism??
> 
> Regards,
> Vijay

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Subject: Re: SUA5: SG Relay Problems
To: "sigtran" <[email-masked]>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
From: [email-masked]
Date: Thu, 28 Jun 2001 14:11:25 -0500
X-MIMETrack: Serialize by Router on NMS_Notes4/Natural
MicroSystems/US(Release 
             5.07a |May 14, 2001) at 06/28/2001 03:11:22 PM
X-SMTP-HELO: ns.nmss.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [208.236.204.65]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Segmented SCCP unitdata messages are never transmitted using class 0; once a
SCCP unitdata
request is segmented, the protocol class for each segment is changed to
class 1, as per
ANSI T1.112.4 (1996) sec. 4.1.1.1.2 and  Q.714 sec. 4.1.1.2.2., as the
segments must arrive at the
destination in order.  Reassembly at the STP/SG would still be a problem in
failure conditions, though.

-Jeff

                    "Brian F. G.

                    Bidulock"            To:     "sigtran"
<[email-masked]>                      
                    <bidulock@ope        cc:

                    nss7.org>            Subject:     Re: SUA5: SG Relay
Problems                                  

                    06/28/01

                    12:44 PM

                    Please

                    respond to

                    sigtran

John,

Please see comments below...

[email-masked] wrote:           (Thu, 28 Jun 2001 16:35:12)
> Hi Gery,
>
> > [GV] : Hm, I agree. Connectionless messages (TCAP
> > transactions) can take either SG still, in either direction (provided
> > "in-sequence-delivery etc). But there is one caveat : since SUA doesn't
> have
> > segmenting/reassembly, each XUDT segment belonging to the same message
> > should "visit" the same SG, where they are assembled into 1 CLDT. The
> > alternative is to still support segmenting/reassembly, but for SUA I'd
> > really wanted to get rid of these UDT/XUDT/LUDT distinctions.
> > I think most (all?) of the authors agreed on that, to keep SCCP
> > interworking problems at the SG.
>
> Yes.
>
> > So, this might cause a problem when an XUDT segment lands on
> > the "wrong" SG
> > due to route/linkset failures. May I propose following
> > procedure ? Feel free to shoot holes in it :))))
> >
> > "If an SG is in mated pair configuration (either SEP/STP),
> > and it receives a
> > non-first XUDT segment for which no reassembly process
> > exists, it should
> > pass this segment to it's mate (assuming there's an SCTP
> > association between
> > them); unless of course it was received from it's mate : then
> > it's time to
> > issue an XUDTS (segmentation error) back to the SEP."
> >
> > Or would this be overkill ?
>
> I'd simply say that all XUDT messages must be reassembled before
> being passed to the ASP.  If it is not possible to do so (for any
> reason) then a XUDTS (segmentation error) must be sent back to the SEP.
>
> End of story.

This will cause problems again for STP configured SGs under class 0
operation.  The SG cannot be guaranteed by the SS7 network that segments
will be delivered to only one of the SGs, even in the absence of failure
conditions.  For class 0 (a really big class) and decoupled operation at the
SG, the ASP will need to do reassembly.

>
> > [GV] : The N-PCSTATE is (already ?) covered by the DUNA/DAVA/SCON
> > messages, with a PC as address information. If the ASPs are concerned,
> > they can keep track of any PC's status. However, we should include an
> > extra chapter (4.3.3 ?) about SUA management to describe these
procedures
> > more accurately (explanation with the messages themselves is not
enough).
> > Try  tomake some draft text as soon as possible. Brian, would this be
> > satisfactory ?
>
> agreed.
>
> > For the coupling of connection sections : alas no address
> > information is
> > present in the CODT and subsequent messages, just a destination local
> > reference ... so I still would feel unhappy to just make it an
> > implementation issue. But supposing a different SG (we should
> > start talking
> > about SGPs rather than SGs) is only chosen in case of link/association
> > failures, we could adopt the procedure as proposed for the XUDTs ?
>
> Hmm, I have to think about what would be needed to
> accomplish this.  Essentially, the ASP would
> have n (SUA) connections to n SGs (or SGPs).  I suppose the
> ASP & SGP could keep track of these SUA connections.
>
> John

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

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Gradischnig, Klaus" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: SG Relay Problems
Date: Thu, 28 Jun 2001 15:24:18 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: va02.npac.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: inetgw.va.neustar.com [209.173.53.225]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Where is the problem with re-assembling class 0 XUDT messages in an SG/STP?

See Q.714,4.1.1.1.2:
"
...
-   The protocol class for each segmented XUDT message shall be set to 1.
...
"
(In ITU shall = SHALL)

The original protocol class (of the unsegmented message) is transported in
bit 7 of octet 1 of the segmentation parameter. (Q.713, 3.17)

Klaus

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: June 28, 2001 1:40 PM
> To: sigtran
> Subject: Re: SUA5: SG Relay Problems
> 
> 
> Gery,
> 
> Comments below...
> 
> Verwimp Gery wrote:                            (Thu, 28 Jun 
> 2001 10:46:06)
> > Hi Brian, John,
> > 
> > Some comments and possible other problems below ;)
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: woensdag 27 juni 2001 9:13
> > To: sigtran
> > Subject: RE: SUA5: SG Relay Problems
> > 
> > 
> > Hi Brian,
> > 
> > > I was reading section 1.3.5 where it says:
> > > 
> > >     Replicated endpoints : only for the first message in 
> a transaction
> > >     or connection one of the SGs is chosen, depending on 
> the traffic
> > >     mode (primary/backup or loadsharing) and overoad 
> conditions.  Once
> > >     selected, the same SG is used for subsequent messages.
> > > 
> > > I interpreted this as a coupling of messages in the 
> transaction.  Have
> > > I somehow misinterpreted this passage?
> > 
> > This text does need some work.  Thanks for pointing it out. 
>  For class
> > 0 or 1 service, the above text is too restrictive.
> > 
> > >>>>>>>>>>>>>>>
> > [GV]: Hm, I agree. Connectionless messages (TCAP 
> transactions) can take
> > either SG still, in either direction (provided 
> "in-sequence-delivery etc
> > etc). But there is one caveat : since SUA doesn't have
> > segmenting/reassembly, each XUDT segment belonging to the 
> same message
> > should "visit" the same SG, where they are assembled into 1 
> CLDT. The
> > alternative is to still support segmenting/reassembly, but 
> for SUA I'd
> > really wanted to get rid of these UDT/XUDT/LUDT 
> distinctions. I think most
> > (all?) of the authors agreed on that, to keep SCCP 
> interworking problems at
> > the SG.
> > 
> > So, this might cause a problem when an XUDT segment lands 
> on the "wrong" SG
> > due to route/linkset failures. May I propose following 
> procedure ? Feel free
> > to shoot holes in it :))))
> > 
> > "If an SG is in mated pair configuration (either SEP/STP), 
> and it receives a
> > non-first XUDT segment for which no reassembly process 
> exists, it should
> > pass this segment to it's mate (assuming there's an SCTP 
> association between
> > them); unless of course it was received from it's mate : 
> then it's time to
> > issue an XUDTS (segmentation error) back to the SEP."
> > 
> > Or would this be overkill ?
> > >>>>>>>>>>>>>>>
> 
> If you require reassembly at the SG, you will break class 0 operation
> for STPs again.  When the SG is acting as an STP for class 0 operation
> it cannot be guaranteed that all of the  segments beloning to the same
> NSDU will arrive at one of the STPs, for any message.  In the case of
> multiple SGs acting as STPs, the SUA at the ASP must do reassembly for
> class 0 operation (at least).
> 
> > 
> > For class 2 or 3 service, it is more accurate.  The problem is how
> > to setup SCCP/SUA connections in this case.  What do you think? 
> > In current SS7, how is the connection-oriented service handled? Are
> > the connections replicated through different STPs?  Should we try to
> > mimic the behavior at the SG?
> > 
> > > No.  For loadsharing, the return messages can be sent via 
> the opposite
> > > SG under class 2.  The restriction is too severe.
> > 
> > [text clipped]
> > 
> > > All you have
> > > to do is strike the text which imposes this "coupling" requirement
> > > and leave it to the implementor's to decide how or when to do
> > > "uncoupled" relay (it *is* done in SS7 networks).  Also, 
> the addition
> > > of an SUA message equivalent to a N-PCSTATE primitive would 
> > > be helpful.
> > 
> > So, getting rid some text in 1.3.5 is enough for you?  Or should we
> > just add text to 1.3.5 that makes coupling MAY?
> > 
> > > Some implementations of SUA at the ASP to perform 
> decoupling at the
> > > SG care.  I am just looking for text and messages which permit
> > > decoupling.  It appears that you want to restrict it because your
> > > specific and narrow application does not need it.  That 
> is no reason
> > > to restrict the specification from full and seamless SCCP 
> > > interworking.
> > 
> > and
> > 
> > > I say again (for the fourth time): STP does not work for decoupled
> > > operation in classes 0 and 2.  Remove the coupling text 
> and provide
> > > full point code status support for N-PCSTATE and they will.
> > 
> > Would changing the text to the below be sufficient, or is 
> there something
> > that should be explicitly stated?
> > 
> > 	Replicated endpoints: the coupling between the SGs and 
> the ASPs when
> > 
> > 	the SGs act as replicated endpoints is an implementation issue.
> > 
> > 
> > >>>>>>>>>>>>>>>
> > [GV]: The N-PCSTATE is (already ?) covered by the 
> DUNA/DAVA/SCON messages,
> > with a PC as address information. If the ASPs are 
> concerned, they can keep
> > track of any PC's status. However, we should include an 
> extra chapter
> > (4.3.3 ?) about SUA management to describe these procedures 
> more accurately
> > (explanation with the messages themselves is not enough). 
> Try to make some
> > draft text as soon as possible. Brian, would this be satisfactory ?
> 
> Yes, just as long as the DUNA/DAVA/SCON messages can be made 
> to include
> only a point code (with no subsystem number), then they could be used
> to indicate what is required.  (Does SCON provide for 
> multiple congestion
> levels?)  In addition, however, the ASP needs to keep track of the
> "restricted" status of the SGs similar to the DRST message in M3UA.
> 
> > 
> > For the coupling of connection sections : alas no address 
> information is
> > present in the CODT and subsequent messages, just a 
> destination local
> > reference ... so I still would feel unhappy to just make it an
> > implementation issue. But supposing a different SG (we 
> should start talking
> > about SGPs rather than SGs) is only chosen in case of 
> link/association
> > failures, we could adopt the procedure as proposed for the XUDTs ?
> > >>>>>>>>>>>>>>>
> > 
> > P.S. Brian, I'm always open to suggestions/improvements, 
> but you have a
> > tendency to get on the wrong side of people sometimes.
> > Anyway, I agree another thread should be started on the 
> problem "how does
> > the UA know that SCTP has really delivered a message". Do 
> we just assume
> > SCTP is as reliable as MTP ??
> 
> SCTP cannot be made as reliable as MTP using the same 
> trasmission facilities
> without additional procedures.  This is because SCTP only provides
> retransmission mechanisms (multi-homing) on a nodal basis 
> (host) whereas MTP
> provides it on a network basis (associated/mated pairs).  It 
> is in trying to
> provide failover between multiple SCTP associations that the 
> changeover
> techniques of MTP are required to bring SCTP up to MTP's reliability.
> 
> 
> -- 
> 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]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 28 Jun 2001 15:38:17 -0500
From: Scott Yagel <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: SIGTRAN standards
X-SMTP-HELO: netmail2.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail2.alcatel.com [128.251.168.51]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

just a general standards question....

is the IETF preparing the only set of SIGTRAN standards documents , or will
there be corresponding documents by other standards bodies such as ITU,
ANSI, etc. ( such as with MEGACO and H.248, for example)?

thanks,
--
Scott Yagel
Alcatel USA
Networking Systems Group
Advanced Planning
[email-masked]
972 519 5858 (v)
972 519 3300 (f)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA
Date: Thu, 28 Jun 2001 23:17:13 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail16.sdc1.sfba.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail16.sdc1.sfba.home.com [24.0.95.143]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META
content="MSHTML 5.50.4207.2601" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi Kevin/Jacques,</FONT></DIV> <DIV><FONT
face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>I think
we can make this a little more generic - The M2PA protocol could be applied
between any two "IP enabled" nodes running SS7 MTP3 protocol.&nbsp; A node
could theoretically be a PSTN Switch, or a Signalling Gateway,
Softswitch/MGC,&nbsp;SCP, STP, or an HLR or whatever.&nbsp;&nbsp; The
nodes&nbsp;don't have to form mated pairs or quads, although they
could.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>Cheers,</FONT></DIV> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; Greg Sidebottom</FONT></DIV> <BLOCKQUOTE

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Kevin McCandless</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=[email-masked] 
  href="mailto:[email-masked]">sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, June 27, 2001 5:03 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: M2PA</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=227480121-27062001><FONT face=Arial color=#0000ff
size=2>P 
  stands peer.&nbsp; The M2PA is for peer to peer connection; SG to
SG.&nbsp; 
  M2PA would be used when you would have two IP enabled switches back to
back 
  like a mated pair or quad.</FONT></SPAN></DIV>
  <DIV><SPAN class=227480121-27062001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=227480121-27062001><FONT face=Arial color=#0000ff size=2>
  <P><FONT face="Lucida Calligraphy">Kevin McCandless</FONT> <BR><FONT 
  face=Arial size=2>Senior Network Planner</FONT> <BR><FONT face=Arial 
  size=2>Illuminet</FONT> <BR><FONT face=Arial size=2>913-814-6397</FONT> 
  <BR><FONT face=Arial size=2><A 
 
href="mailto:[email-masked]">[email-masked]</A></FONT>

  </P></FONT></SPAN></DIV>
  <BLOCKQUOTE>
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Jacques Rajchgod 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, June 27,

    2001 12:13 PM<BR><B>To:</B> sigtran<BR><B>Subject:</B> 
    M2PA<BR><BR></FONT></DIV>
    <DIV><FONT face=Arial size=2><SPAN class=840432616-27062001>I just heard
of 
    a new Transport protocol called "M2PA". What is "M2PA"? (What does the
"P" 
    stand for?)</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <P><FONT size=2>Jacques Rajchgod<BR>MCI Worldcom<BR>Next Generation
System 
    Evaluation<BR>Tel: [972] 729-1487<BR>E-mail: [email-masked]

    </FONT></P>
    <DIV>&nbsp;</DIV>---<BR>You are currently subscribed to sigtran as: 
    [email-masked]<BR>To unsubscribe send a blank email to 
    [email-masked] </BLOCKQUOTE>---<BR>You are

  currently subscribed to sigtran as: [email-masked]<BR>To unsubscribe
send a 
  blank email to [email-masked] </BLOCKQUOTE>
---<BR>
You are currently subscribed to sigtran as: [email-masked]<BR> To
unsubscribe send a blank email to
[email-masked] </BODY></HTML>

</x-html>
Date: Thu, 28 Jun 2001 22:30:04 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SUA5: SG Relay Problems
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: avocet.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: avocet.mail.pas.earthlink.net [207.217.121.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jeff,

Thanks for the correction.  It might not be a problem for Class 1 because
segmented messages will only go to the opposite SG at the instant of the
failure.  It might not be too onerous to send an [XL]UDTS for the messages
caught across the SGs and resume reassembly at the new SG.

With your clarifications, I don't think it is so much of a problem anymore
;)

--Brian

[email-masked] wrote:                (Thu, 28 Jun 2001 14:11:25)
> 
> Segmented SCCP unitdata messages are never transmitted using class
> 0; once a SCCP unitdata request is segmented, the protocol class
> for each segment is changed to class 1, as per ANSI T1.112.4
> (1996) sec. 4.1.1.1.2 and  Q.714 sec. 4.1.1.2.2., as the segments
> must arrive at the destination in order.  Reassembly at the STP/SG
> would still be a problem in failure conditions, though.
> 

-- 
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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Date: Thu, 28 Jun 2001 23:42:33 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [24.2.9.91]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

One question for you below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: <[email-masked]>
Sent: Thursday, June 28, 2001 1:30 PM
Subject: Re: Packing of DATA Payloads

> Joyce,
>
> Please see comments below:
>
> Joyce Archibald wrote:                           (Thu, 28 Jun 2001
13:32:10)
> > Hi Brian, Greg,
> >
> > I take your point that if all pointcodes are converted to 24-bit
> > numbers,
> > then it is not essential that the original format is known.
> >
> > Using your proposed new format for the DATA message:
> >
> > >     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 = 28           |          Length = 24          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Originating Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Destination Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Signalling Link Selection   |       Service Indicator       |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |            Tag = 3            |             Length            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    \                                                               \
> > >    /                        Protocol Data                          /
> > >    \                                                               \
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > Where now the Protocol Data would only contain MTP-User data.
> >
> > Presumably, this should now be updated to include the Routing Context.
> > Are you proposing to add the ASP Id as a further parameter or are you
> > saying that this is implied by the Routing Context?
> >
> > May I suggest:-
> >
> > Payload Data Message
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |  Network Id.  |  Service Ind. |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 6            |          Length = 8           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Routing Context                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > If there is only one network partition, then the Network Id could
> > optionally be set to zero.
> >
> > This would not increase the overall size of the message.
> >
> > The Routing Key parameter surely needs some way of distinguishing
> > pointcodes from different networks. So if the Network Appearance
> > parameter is removed, a Network Id will be needed instead.
> >
> > Perhaps it would help if I explain why a Network Id is needed by some
> > applications of Protocol Analysers & Link Monitoring Systems.
>
>
> What is the "Network Id"?  How does the SG derive this?  If you are
> talking about the NI bits in an MSU, they may be different for different
> links for the same point code in the same network.  Also, in some
> circumstances, NI bits are used to extend the point code by two bits.
>
> >
> > 1. It is essential to know if messages containing the same pointcode
> >    actually refer to signalling points in different networks. Thus
> >    if an SG is connected to multiple networks it could refer to them
> >    using different locally defined Network Ids.
>
> This can be accomplished by placing a routing context in the message.
> Nevertheless, I don't believe the situation you describe cannot occur
> because an ASP cannot span multiple SPMCs (point-codes).
>

[Greg] Brain, you have mentioned this restriction in a couple of recent
e-mails.  Where do you see this restriction?  Couldn't an ASP register (or
be statically configured) to send/receive traffic in two different SS7
networks, each available through the same SG.  The SG would have a separate
Point Code in each network partition.  The current registration procedures
seem to allow the ASP, via two separate Registrations (one in each Network
Appearance) to do this.  The Network Appearance (or the Routing Context in
your proposals) could subsequently be used to tell the traffic and SSNM
messages apart.

I'm not sure if it is really practical to do this but it seems to be
possible.  Am I missing something?

Thanks,

   Greg

> >
> > 2. If a Protocol Analyser has to wait to see Routing Key Management
> >    messages, which I assume are fairly rare, before knowing which
> >    network a message belongs too, then it is less useful to its user
> >    than it might have been. Even permanently installed link monitoring
> >    systems cannot guarantee to see absolutely every message due to
> >    maintenance outages.
>
> There is nothing restricting an SG from assigning a fixed routing
> context to each of its routing keys.  I would suggest that if a
> network operator wishes to attach fixed monitoring equipment to
> their network that they require that the SG implementation assign
> fixed routing contexts to routing keys.
>
> >
> > 3. Clearly Analysers & Monitoring Systems need to acquire information
> >    about system configuration, but there's a big difference between
> >    knowing which Network Ids a signalling gateway is connected to and
> >    obtaining information about dynamically changing Routing Contexts.
>
> Don't allow routing contexts to change dynamically with respect to
> routing keys.  The spec does not require them to change dynamically
> with respect to routing keys.  It only requires the SG to inform the
> ASP of the mapping between routing key and routing context at the
> time of registration.  Presumably the ASP doesn't need to know this
> information in advance.
>
> If the algorithm used at the SG is a simple static mapping of RK to RC,
> the protocol analyzer or monitoring box can be provisioned with the
> same mapping.  End of problem.
>
> --
> 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: Greg Sidebottom <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Date: Thu, 28 Jun 2001 23:46:46 -0400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-SMTP-HELO: femail4.rdc1.on.home.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: femail4.rdc1.on.home.com [24.2.9.91]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

A question below ...

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]> To: "sigtran"
<[email-masked]> Cc: <[email-masked]>
Sent: Thursday, June 28, 2001 1:30 PM
Subject: Re: Packing of DATA Payloads

> Joyce,
>
> Please see comments below:
>
> Joyce Archibald wrote:                           (Thu, 28 Jun 2001
13:32:10)
> > Hi Brian, Greg,
> >
> > I take your point that if all pointcodes are converted to 24-bit
> > numbers,
> > then it is not essential that the original format is known.
> >
> > Using your proposed new format for the DATA message:
> >
> > >     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 = 28           |          Length = 24          |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Originating Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                     Destination Point Code                    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |   Signalling Link Selection   |       Service Indicator       |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |            Tag = 3            |             Length            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    \                                                               \
> > >    /                        Protocol Data                          /
> > >    \                                                               \
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > Where now the Protocol Data would only contain MTP-User data.
> >
> > Presumably, this should now be updated to include the Routing Context.
> > Are you proposing to add the ASP Id as a further parameter or are you
> > saying that this is implied by the Routing Context?
> >
> > May I suggest:-
> >
> > Payload Data Message
> >     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 = 28           |          Length = 24          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Originating Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                     Destination Point Code                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Signalling Link Selection   |  Network Id.  |  Service Ind. |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 6            |          Length = 8           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Routing Context                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |            Tag = 3            |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    \                                                               \
> >    /                        Protocol Data                          /
> >    \                                                               \
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > If there is only one network partition, then the Network Id could
> > optionally be set to zero.
> >
> > This would not increase the overall size of the message.
> >
> > The Routing Key parameter surely needs some way of distinguishing
> > pointcodes from different networks. So if the Network Appearance
> > parameter is removed, a Network Id will be needed instead.
> >
> > Perhaps it would help if I explain why a Network Id is needed by some
> > applications of Protocol Analysers & Link Monitoring Systems.
>
>
> What is the "Network Id"?  How does the SG derive this?  If you are
> talking about the NI bits in an MSU, they may be different for different
> links for the same point code in the same network.  Also, in some
> circumstances, NI bits are used to extend the point code by two bits.
>
> >
> > 1. It is essential to know if messages containing the same pointcode
> >    actually refer to signalling points in different networks. Thus
> >    if an SG is connected to multiple networks it could refer to them
> >    using different locally defined Network Ids.
>
> This can be accomplished by placing a routing context in the message.
> Nevertheless, I don't believe the situation you describe cannot occur
> because an ASP cannot span multiple SPMCs (point-codes).
>

[Greg] Brain, you have mentioned this restriction in a couple of recent
e-mails.  Where do you see this restriction?  Couldn't an ASP register (or
be statically configured) to send/receive traffic in two different SS7
networks, each available through the same SG.  The SG would have a separate
Point Code in each network partition.  The current registration procedures
seem to allow the ASP, via two separate Registrations (one in each Network
Appearance) to do this.  The Network Appearance (or the Routing Context in
your proposals) could subsequently be used to tell the traffic and SSNM
messages apart.

I'm not sure if it is really practical to do this but it seems to be
possible.  Am I missing something?

Thanks,

   Greg

> >
> > 2. If a Protocol Analyser has to wait to see Routing Key Management
> >    messages, which I assume are fairly rare, before knowing which
> >    network a message belongs too, then it is less useful to its user
> >    than it might have been. Even permanently installed link monitoring
> >    systems cannot guarantee to see absolutely every message due to
> >    maintenance outages.
>
> There is nothing restricting an SG from assigning a fixed routing
> context to each of its routing keys.  I would suggest that if a
> network operator wishes to attach fixed monitoring equipment to
> their network that they require that the SG implementation assign
> fixed routing contexts to routing keys.
>
> >
> > 3. Clearly Analysers & Monitoring Systems need to acquire information
> >    about system configuration, but there's a big difference between
> >    knowing which Network Ids a signalling gateway is connected to and
> >    obtaining information about dynamically changing Routing Contexts.
>
> Don't allow routing contexts to change dynamically with respect to
> routing keys.  The spec does not require them to change dynamically
> with respect to routing keys.  It only requires the SG to inform the
> ASP of the mapping between routing key and routing context at the
> time of registration.  Presumably the ASP doesn't need to know this
> information in advance.
>
> If the algorithm used at the SG is a simple static mapping of RK to RC,
> the protocol analyzer or monitoring box can be provisioned with the
> same mapping.  End of problem.
>
> --
> 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]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 29 Jun 2001 00:56:50 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Packing of DATA Payloads
Reply-To: [email-masked]
User-Agent: Mutt/1.2.5i
Organization: http://www.openss7.org/
Dsn-Notification-To: <[email-masked]>
X-SMTP-HELO: falcon.mail.pas.earthlink.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: falcon.mail.pas.earthlink.net [207.217.120.74]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

No, I don't believe that you are missing anything.  I just mean that since
the RK and RC cannot span SPMCs (and thus an AS cannot span multiple SPMCs)
that it is not possible to confuse the ASP registered in one AS with another
and there is no need for additional "Network Identity" in the transfer
message.

Now that you mentioned it, however, Routing Context has the advantage over
Network Appearance in that the ASP could then register against two point
codes (SPMCs or ASs) in the *same* network.  Messages for either point code
can be distinguished by Routing Context where the Network Appearances would
have been the same.

--Brian

> 
> 
> [Greg] Brain, you have mentioned this restriction in a couple of recent
> e-mails.  Where do you see this restriction?  Couldn't an ASP register (or
> be statically configured) to send/receive traffic in two different SS7
> networks, each available through the same SG.  The SG would have a
separate
> Point Code in each network partition.  The current registration procedures
> seem to allow the ASP, via two separate Registrations (one in each Network
> Appearance) to do this.  The Network Appearance (or the Routing Context in
> your proposals) could subsequently be used to tell the traffic and SSNM
> messages apart.
> 
> I'm not sure if it is really practical to do this but it seems to be
> possible.  Am I missing something?
> 

-- 
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]
Date: Fri, 29 Jun 2001 12:32:27 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Comments on M3UA MIB
Organization: Mercury Corporation, India
X-mailer: FoxMail 2.1 [en]
X-SMTP-HELO: india.mercurykr.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [165.133.13.60]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Antonio,

I have some comments on the M3UA MIB Draft ver 01 -

1. Section 3.1.2.3 Signaling Process Table - Para 4 "Several SP will
correspond to one SP Endpoint. They will be linked by the Association Id."
I don't understand what you want to say by the above statement

2. Section 3.1.2.4 Signaling Process Endpoint Table - Para 6 "The main table
also contains statistics data related to the M3UA messaging exchanged
through that association between the Signaling Processes that hold the
association."
This has been moved to another table.

3. Section 3.1.2.5 Signaling Process Endpoint Statistics Table As per the
object definition for this table, the following fields need to be included
in this table - m3uaAppId and m3uaSpEpId Remove m3uaSpEpRowStatus.
I have a question here. Do you want to maintain statistics on a per AS - ASP
basis ? In that case how do you propose to maitain statistics for messages
which are not related to a particular AS such as ASPUP, ASPDN etc. ?
Or should it be only on ASP basis, instead of AS - ASP ?

4. Section 3.1.2.6 Routing Table
What about "Routing Context" ? Or do you propose to use m3uaPeerAppId as the
routing context ?

5. Section 3.1.2.6 Network Appearance Table Duplicate Section No., Add
m3uaNaRowStatus

6. Section 3.1.2.7.2 Local and Remote IP Address Tables I suggest using
m3uaSpEpId instead of m3uaAssocId as the index.

7. Object Definition of m3uaMaxStreamInbound Should it have a MAX-ACCESS of
"read-write" or "read-only" ?
Secondly the SCTP MIB already has this object, and while accepting incoming
associations, SCTP uses its own value rather than M3UA's value.

8. Object Definition of m3uaSpEpEntry
Index should not include "m3uaAppId"

9. Object Definition of m3uaSpEpStatRowStatus Delete definition as all
entries in this table are "read-only"

10. Object Definition of m3uaRoutingTable As the object is currently
defined, this cannot be used at at a ASP M3UA. A Routing Key at an ASP would
be for the peer Logical Application ie. SG. Thus, only the DPC component of
routing key would be used, everything else would be null.
But a DPC may be accessible to ASP via multiple SGs. But the table cannot
take multiple rows becoz that would lead to duplicate routing keys which is
the index for the table.

11. Typos -
-Date on Page 1. Should be May 23, 2001 -Abstract on Page 1 - Para 2. Should
be M3UA -Section 1. Introduction - Para 3. Should be M3UA -Object Definition
of "LOGICAL APPLICATION TABLE" : Change "Application Server" to "Logical
Application" and "AS" to "App"

Regards,
Srivats P.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SUA6: SG Relay Problems
Date: Fri, 29 Jun 2001 12:19:24 +0200
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: hrtades9.atea.be
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: viap083.atea.be [194.78.143.83]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

Let's wrap some things up for the SG :

1. Reassembly of XUDT at SG : I think everyone agrees on that now. To deal
with link/routeset failures, can everyone agree on following procedure ?

"If a SG is operated in mated pair configuration, and it receives a
non-first XUDT segment for which no reassembly process exists, it should
pass on this segment to it's mate; if the segment was already received from
the mated SG or if no mated SG is available, the return on error procedures
must be invoked."

2. Coupling of connection sections at SG : let's see if we can reach a
compromise ...

The CR message can contain information (e.g. GT, SSN) based on which an
AS/ASP is selected. This information is no longer present in subsequent CO
messages. Therefor, in order to provide seemless SS7 - IP interworking,
coupling of connection sections is required in the SG when :

- the SG acts as SEP : in this case SUA is used to provide the interface
between SCCP on the SG and the SCCP-user on the ASP.

- the SG acts as STP, and the AS/ASP cannot be derived from the received
SCCP-CO message, or the SEP cannot be derived from the received SUA-CO
message.

To avoid coupling, we need SS7 address info (at least a PC) in all SUA-CO
messages (CODT etc.) ! If we want coupling of connection sections optional
at the SG, we need to update the SUA-CO messages in this respect.

BTW : are we going to work with routing contexts instead of network
appearance now in each SUA-CL and CO message ? If so, this could be used for
mapping to a SEP in case of "no coupling" at the SG. To me this sounds like
a good idea for 2 reasons :

- the network appearance parameter definition is still rather shaky - the
routing context could well provide the same (and more) functionality

3. SCON : yes, there are multiple congestion levels (0 -> 7)

4. Concerning DRST : let's see if I get it straight ... this is to signal to
concerned/neighbouring nodes that a SG/SUA-relay node from a mated pair has
lost connectivity to a SEP/SUA-end node and routing should preferably
continue over the other mate. The other mate will receive a DUNA instead of
a DRST, and when he loses connectivity to the same endpoint as well, both
SGs will send DUNA to their neighbours.

Since SGs can consist of several SGPs (and would be modelled as such in the
ASP to guard SCTP connectivity), the SSNM messages (DUNA, DAVA, SCON, DRST),
when received from any of these SGPs, should be regarded as valid for the
entire SG.

Regards,

____________________________

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