Subject: May 2001 archived mail

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

To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: [M3UA] AS state machine sharing between SGPs
X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3
Date: Tue, 01 May 2001 13:26:51 +0900
From: Kazuo Watanabe <[email-masked]>
X-SMTP-HELO: TYO201.gate.nec.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: TYO201.gate.nec.co.jp [202.32.8.214]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

> In the case where there are multiple SGPs in an SG, and the SGPs have
> magically determined in their coordinated MTP3 route management logic that
> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU
> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the

no.
i think all concerned ASPs should receive but not all SGPs should send.
because DUNA indicates SS7 route state not SG/SGP state.

> answer is yes given the logic of the discussion on this thread.  So that
> means that if the triggering event is reception of TFP(s) from the SS7
> network, then all SGPs in an SG must coordinate their MTP3 view of the
> availability of the SS7 destination.   Equivalent arguments can be made
for
> virtually any SS7 link or route management event.

yes.
i think this is `multiple SGPs in an SG.'

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view.
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP.

in that case, each SGP could have different AS state and should have the
same SS7 state.

> Also, if one SGP has determined an SS7 destination is unavailable, but the
> destination is still available via other SGPs (a link event?), then I
assume

according to my understanding, this is multiple SGs not multiple SGPs in an
SG.

> that the SGP would optionally send an DRST - although we could make the
case
> that a DUPU could be used by SGP implementations that don't redirect any
> traffic received to the other SGPs.  I wouldn't recommend it though as
this
> implies message loss.
> Does this sound right?

if you are saying about STP-like SGs configuration, it sounds right to me.

-- 
Kazuo Watanabe

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Tue, 01 May 2001 08:01:17 +0100
From: Joyce Archibald <[email-masked]>
Reply-To: [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: Network Appearance.
X-SMTP-HELO: msgbas1.cos.agilent.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [192.6.9.33]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Norm/John/Greg,

I still don't quite understand why you need a Network Appearance per
pointcode. Surely in a DUNA message, for example, the SS7 network would be
defined by the Network Appearance and the individual end nodes by the
affected DPCs.

Perhaps it would help if you could give me an example of the application of
Network Appearance, i.e. define a SG connecting to multiple networks and
show how Network Appearance would be used.

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.

Regards,
Joyce

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
> --
> 
> Joyce Archibald wrote:
> 
> > Hi Norm,
> >
> > As I understand it in SUA, the purpose of Network Appearance is to
> > define "... the SS7 Point Code format used, the SS7 Network Indicator
> > value and the SCCP protocol type/variant/version used within the SS7
> > network partion". I don't see how this can be defined as "a single point
> > code in any given network". While it is possible that each point code in
> > a network may use a different format and thus require a different
> > Network Appearance, it doesn't seem very likely.
> >
> > If you are saying that it is possible for a network management message
> > to contain point codes with different formats, then having one Network
> > Appearance parameter in the message is not going to work, however you
> > define it. If that is the case please see the thread "M3UA and SUA:
> > Point Code formats" beginning on 8th March.
> >
> > Regards,
> > Joyce
> >
> > Normand Glaude wrote:
> > > Folks, I circulated a message on the list in January about the
> > > definition of the Network Appearance. This was discussed in
Minneapolis,
> > > and I thought I'd produce a bit more info, so that we all agreed on
> > > basic definitions.
> > >
> > > There are 2 definitions circulating in the drafts today for Network
> > > Appearance
> > >
> > > 1) In M3UA, it means the appearance OF a network. Essentially, all
point
> > > codes in the same network belong network appearance.
> > >
> > > 2) In SUA, it means the appearance IN a network. Essentially, a single
> > > point code in any given network is a network appearance, in a
one-to-one
> > > relationship.
> > >
> > > There are issues with (1), in that all network management messages
> > > (DUNA, DAVA, etc.) use the network appearance as the context, and that
> > > creates ambiguities in cases where multiple point codes are
represented
> > > by a single signaling gateway in a network.
> > >
> > > There are duplication issues with (2), as a single event in the SS7
> > > network may generate multiple events on the M3UA side.
> > >
> > > I propose we use definition (2), since duplication is less of an issue
> > > than ambiguity.
> > >
> > > The following is what I circulated in January, and it covers the same
> > > issue for different reasons, and the SUA definition has changed since.
> > >
> > > Greg/John, I'll produce some text for the drafts to clearly indicate
> > > this, unless this becomes a hot debate on the mailing list, like it
did
> > > the last time :-)
> > >
> > > Norm.
> > >
> >
> > --
> > ==================================================================
> > 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]
> 
> --
> Normand Glaude, Chief Engineer, Signaling Systems Group
> Performance Technologies Canada, Inc.
> E-Mail: [email-masked]
> Tel: +1 (613) 237 4344       Fax: +1 (613) 237 4456
> 
> ---
> 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: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: ENUM : some explanation on the use of GTT
Date: Tue, 1 May 2001 11:53:48 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate3.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate3.mot.com [144.189.100.103]
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.2654.19">
<TITLE>RE: ENUM : some explanation on the use of GTT</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>&gt; 1. First of all, GT routing enhances the routing
capabilities of the</FONT> <BR><FONT SIZE=2>&gt; underlying layers (MTP just
routes on point codes, IP just on </FONT> <BR><FONT SIZE=2>&gt; IP
addresses).</FONT> <BR><FONT SIZE=2>&gt; In SS7, it's useful to cross
network boundaries (the same </FONT> <BR><FONT SIZE=2>&gt; point codes can
be</FONT> <BR><FONT SIZE=2>&gt; (re)used in different networks, SSNs may
have a different meaning in</FONT> <BR><FONT SIZE=2>&gt; different networks,
etc.). Does this bring anything in an all </FONT> <BR><FONT SIZE=2>&gt; IP
environment</FONT> <BR><FONT SIZE=2>&gt; ? At least it might be useful to
seperate networks, in the sence that</FONT> <BR><FONT SIZE=2>&gt;
administration in one network is not influenced by a change in other</FONT>
<BR><FONT SIZE=2>&gt; (operator's) networks, except in the gateway where
this network border</FONT> <BR><FONT SIZE=2>&gt; crossing is
executed.</FONT> <BR><FONT SIZE=2>&gt; Your administration/management
functions will be influenced </FONT> <BR><FONT SIZE=2>&gt; if you just
work</FONT> <BR><FONT SIZE=2>&gt; in an end-to-end mode, and have to setup
SCTP associations with every</FONT> <BR><FONT SIZE=2>&gt; possible
communication partner in everybody elses network ... </FONT> <BR><FONT
SIZE=2>&gt; And if you</FONT> <BR><FONT SIZE=2>&gt; want to send a critical
signalling message, you don't want </FONT> <BR><FONT SIZE=2>&gt; the burden
of</FONT> <BR><FONT SIZE=2>&gt; setting up a new SCTP association first
!</FONT> </P>

<P><FONT SIZE=2>I can understand that GT routing enhances the routing
capabilities of MTP as point code based routing is hop by hop.&nbsp;
However, I don't the understand the enhancement to IP routing.&nbsp; I view
IP address as kind of Global Title.&nbsp; Can you please elaborate more on
this?</FONT></P>

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

<P><FONT SIZE=2>Michael </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Thursday, April 26, 2001 2:24
AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt;
Subject: RE: ENUM : some explanation on the use of GTT</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello all,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Some points were raised on the use of GTT in the SG or
in an all IP</FONT> <BR><FONT SIZE=2>&gt; environment. Maybe it would be a
good thing to start with the </FONT> <BR><FONT SIZE=2>&gt; basics and
see</FONT> <BR><FONT SIZE=2>&gt; what GTT might bring us.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Srini, I've put the answers to your questions below
(after </FONT> <BR><FONT SIZE=2>&gt; this proze) ;-)</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1. First of all, GT routing enhances the routing
capabilities of the</FONT> <BR><FONT SIZE=2>&gt; underlying layers (MTP just
routes on point codes, IP just on </FONT> <BR><FONT SIZE=2>&gt; IP
addresses).</FONT> <BR><FONT SIZE=2>&gt; In SS7, it's useful to cross
network boundaries (the same </FONT> <BR><FONT SIZE=2>&gt; point codes can
be</FONT> <BR><FONT SIZE=2>&gt; (re)used in different networks, SSNs may
have a different meaning in</FONT> <BR><FONT SIZE=2>&gt; different networks,
etc.). Does this bring anything in an all </FONT> <BR><FONT SIZE=2>&gt; IP
environment</FONT> <BR><FONT SIZE=2>&gt; ? At least it might be useful to
seperate networks, in the sence that</FONT> <BR><FONT SIZE=2>&gt;
administration in one network is not influenced by a change in other</FONT>
<BR><FONT SIZE=2>&gt; (operator's) networks, except in the gateway where
this network border</FONT> <BR><FONT SIZE=2>&gt; crossing is
executed.</FONT> <BR><FONT SIZE=2>&gt; Your administration/management
functions will be influenced </FONT> <BR><FONT SIZE=2>&gt; if you just
work</FONT> <BR><FONT SIZE=2>&gt; in an end-to-end mode, and have to setup
SCTP associations with every</FONT> <BR><FONT SIZE=2>&gt; possible
communication partner in everybody elses network ... </FONT> <BR><FONT
SIZE=2>&gt; And if you</FONT> <BR><FONT SIZE=2>&gt; want to send a critical
signalling message, you don't want </FONT> <BR><FONT SIZE=2>&gt; the burden
of</FONT> <BR><FONT SIZE=2>&gt; setting up a new SCTP association first
!</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2. To the E.212/E.214 (IMSI number, ...) issue : for
(international)</FONT> <BR><FONT SIZE=2>&gt; roaming, these numbers are
always translated to a MSISDN </FONT> <BR><FONT SIZE=2>&gt; (Mobile
Station</FONT> <BR><FONT SIZE=2>&gt; ISDN number), which is a E.164 number,
for routing across the </FONT> <BR><FONT SIZE=2>&gt; PLMN border</FONT>
<BR><FONT SIZE=2>&gt; towards the destination HLR. GTT not only allows you
to find </FONT> <BR><FONT SIZE=2>&gt; the next node</FONT> <BR><FONT
SIZE=2>&gt; (end- or next relay-node), but also to change the GT </FONT>
<BR><FONT SIZE=2>&gt; addresses in the format</FONT> <BR><FONT SIZE=2>&gt;
required by the intermediate networks. And 3GPP will try to </FONT>
<BR><FONT SIZE=2>&gt; use as much of</FONT> <BR><FONT SIZE=2>&gt; the
existing GSM architecture /infrastructure as possible ...</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 3. Where to put this GTT-function ?</FONT> <BR><FONT
SIZE=2>&gt; At the SG, it is clear we leave it to the existing SCCP layer
</FONT> <BR><FONT SIZE=2>&gt; to perform</FONT> <BR><FONT SIZE=2>&gt; GTT.
However, this GTT-function has to be enhanced, because </FONT> <BR><FONT
SIZE=2>&gt; next to the</FONT> <BR><FONT SIZE=2>&gt; (traditional) SS7
destinations, now also destinations in the </FONT> <BR><FONT SIZE=2>&gt;
IP-domain are</FONT> <BR><FONT SIZE=2>&gt; possible. How one goes about this
(via AS-ID as result of </FONT> <BR><FONT SIZE=2>&gt; SCCP's GTT, or</FONT>
<BR><FONT SIZE=2>&gt; whatever) is an implementation issue. The point is,
through GT</FONT> <BR><FONT SIZE=2>&gt; administration, a portion of the
SCCP SS7 traffic will be </FONT> <BR><FONT SIZE=2>&gt; relayed towards
an</FONT> <BR><FONT SIZE=2>&gt; IP-node via SUA; thus we already have (of
sorts) the </FONT> <BR><FONT SIZE=2>&gt; functionality intended</FONT>
<BR><FONT SIZE=2>&gt; by the &quot;routing key/context&quot;
mechanism.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At the IP end-point (ASP), the functionality is not
required, </FONT> <BR><FONT SIZE=2>&gt; i.e. you only</FONT> <BR><FONT
SIZE=2>&gt; act as SUA end-point and you want to deliver the received SUA
</FONT> <BR><FONT SIZE=2>&gt; messages to</FONT> <BR><FONT SIZE=2>&gt; your
users, not forward them to a next SUA-node. And for </FONT> <BR><FONT
SIZE=2>&gt; outgoing messages,</FONT> <BR><FONT SIZE=2>&gt; you send them to
a peer ASP or to the SG of which you know </FONT> <BR><FONT SIZE=2>&gt; (via
admin) it</FONT> <BR><FONT SIZE=2>&gt; has connectivity to the SS7 network
you want; and of course, </FONT> <BR><FONT SIZE=2>&gt; the SG can</FONT>
<BR><FONT SIZE=2>&gt; perform GTT as well, so if your user comes up with a
GT, the </FONT> <BR><FONT SIZE=2>&gt; SG is the one</FONT> <BR><FONT
SIZE=2>&gt; you want to send your SUA message to.</FONT> <BR><FONT
SIZE=2>&gt; However, if you want the benefits of a GTT-function (as </FONT>
<BR><FONT SIZE=2>&gt; explained briefly in</FONT> <BR><FONT SIZE=2>&gt; 1.),
you might consider implementing this function (based on </FONT> <BR><FONT
SIZE=2>&gt; your existing</FONT> <BR><FONT SIZE=2>&gt; SCCP implementation,
or from scratch ...) or at least trigger </FONT> <BR><FONT SIZE=2>&gt; your
SUA to</FONT> <BR><FONT SIZE=2>&gt; access a database </FONT> <BR><FONT
SIZE=2>&gt; by &quot;other means&quot; (hopefully NOT DNS).</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; These &quot;other means&quot; cannot be specified in
the SUA document, </FONT> <BR><FONT SIZE=2>&gt; but what should</FONT>
<BR><FONT SIZE=2>&gt; be made clear is :</FONT> <BR><FONT SIZE=2>&gt; - the
GTT process : based on ITU-T Q.714, but enhanced with the new</FONT>
<BR><FONT SIZE=2>&gt; hostname/IP address parameters, i.e. valid
input/output;</FONT> <BR><FONT SIZE=2>&gt; - performance requirements :
based on ITU-T Q.716, there is </FONT> <BR><FONT SIZE=2>&gt; an upper
limit</FONT> <BR><FONT SIZE=2>&gt; on the transit time (= time an SUA
message needs from </FONT> <BR><FONT SIZE=2>&gt; entering a SUA relay</FONT>
<BR><FONT SIZE=2>&gt; node till leaving it), and yes, it is less than a
second (DNS ??)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 4. ENUM : since IP addresses are global in scope, you
can use </FONT> <BR><FONT SIZE=2>&gt; them as global</FONT> <BR><FONT
SIZE=2>&gt; titles; but again, you don't want SCTP associations for every
possible</FONT> <BR><FONT SIZE=2>&gt; signalling relation. GTT is the answer
!</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Best regards,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ____________________________</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gery Verwimp</FONT> <BR><FONT SIZE=2>&gt; &gt; SIEMENS
ATEA</FONT> <BR><FONT SIZE=2>&gt; &gt; ICN D CS D5</FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel. : +32 14 25 3424</FONT> <BR><FONT
SIZE=2>&gt; Fax : +32 14 25 3212</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>&gt;
____________________________________</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: Miriyala Srinivas-FSM016 [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: dinsdag 24 april 2001 22:23</FONT> <BR><FONT
SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: RE:
ENUM</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello Greg/Lode and Chirayu,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; I have some basic questions regarding SUA and I hope
you guys </FONT> <BR><FONT SIZE=2>&gt; can help me</FONT> <BR><FONT
SIZE=2>&gt; come out of this mystery world.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; 1. If a box has to implement multiple SCCP user
protocols </FONT> <BR><FONT SIZE=2>&gt; (e.g TCAP, RANAP</FONT> <BR><FONT
SIZE=2>&gt; e.t.c) how does the implementation of these stacks map into AS
and ASP</FONT> <BR><FONT SIZE=2>&gt; concepts. I hope I am making some sense
here. My question is does ASP</FONT> <BR><FONT SIZE=2>&gt; implements SUA
and each upper layer protocol can be implemented by</FONT> <BR><FONT
SIZE=2>&gt; individual AS (Is this a valid logical functional break down).
</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [GV] : That's a way to do it. But it is not
necessarily so : </FONT> <BR><FONT SIZE=2>&gt; one AS may</FONT> <BR><FONT
SIZE=2>&gt; serve several SCCP SSN's as well. E.g. take the &quot;MAP&quot;
AS, </FONT> <BR><FONT SIZE=2>&gt; handling all MAP</FONT> <BR><FONT
SIZE=2>&gt; related traffic : MAP_HLR, MAP_MSC, MAP_VLR, MAP_AC ...</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; 2. Can &quot;network appearance field&quot; (Protocol
type/variant </FONT> <BR><FONT SIZE=2>&gt; portion) in the</FONT> <BR><FONT
SIZE=2>&gt; CLDT message be used by the SUA layer for routing the message
</FONT> <BR><FONT SIZE=2>&gt;&nbsp; to its upper</FONT> <BR><FONT
SIZE=2>&gt; layer protocols (e.g to TCAP or RANAP). </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [GV] : the &quot;network appearance&quot; specifies
the SS7 network context the</FONT> <BR><FONT SIZE=2>&gt; message has to be
viewed in. Apart from the standardized SSNs </FONT> <BR><FONT SIZE=2>&gt;
(0..31 by</FONT>
<BR><FONT SIZE=2>&gt; ITU-T, some others by GSM), the same SSN values may
have a </FONT> <BR><FONT SIZE=2>&gt; different meaning</FONT> <BR><FONT
SIZE=2>&gt; in a different network. Also, point codes only make sense in
</FONT> <BR><FONT SIZE=2>&gt; a SS7 network</FONT> <BR><FONT SIZE=2>&gt;
context; so the SG may be confused when it gets just the </FONT> <BR><FONT
SIZE=2>&gt; point code, but no</FONT> <BR><FONT SIZE=2>&gt; network
appearance in the received CLDT =&gt; what possible SS7 </FONT> <BR><FONT
SIZE=2>&gt; end-node should</FONT> <BR><FONT SIZE=2>&gt; it relay the (X)UDT
message to ??</FONT> <BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; 3.&nbsp; Can only one SCTP association exists between
two ASPs.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [GV] : Yip. One peer ASP = one SCTP association
!</FONT> <BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; 4. How does MI (Management instance) uses the routing
context </FONT> <BR><FONT SIZE=2>&gt; information it</FONT> <BR><FONT
SIZE=2>&gt; receives in the ASP Active message (ACTIVE). What address
translation</FONT> <BR><FONT SIZE=2>&gt; service does this logical MI
provides. </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [GV] : At the SG, it somehow means building up your
routing tables</FONT> <BR><FONT SIZE=2>&gt; dynamically ... My personal
feeling is that these procedures </FONT> <BR><FONT SIZE=2>&gt; are not
clear</FONT> <BR><FONT SIZE=2>&gt; at all (overlapping parameters, what
combinations are </FONT> <BR><FONT SIZE=2>&gt; allowed, registration</FONT>
<BR><FONT SIZE=2>&gt; sequence of ASPs, security issues ????). For SUA, I
think the </FONT> <BR><FONT SIZE=2>&gt; existing SCCP</FONT> <BR><FONT
SIZE=2>&gt; GTT function takes care of it.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; 5. Is the concept, &quot;routing key' is only valid in
the context </FONT> <BR><FONT SIZE=2>&gt; of Signaling</FONT> <BR><FONT
SIZE=2>&gt; Gateway. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [GV] : Think so. The definition talks about &quot;set
of SS7 </FONT> <BR><FONT SIZE=2>&gt; parameters&quot;, so</FONT> <BR><FONT
SIZE=2>&gt; forget about it in an all IP context ;-)</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Regards</FONT>
<BR><FONT SIZE=2>&gt; Srini </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send a
blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 01 May 2001 09:46:17 -0700
To: "sigtran" <[email-masked]>
From: Jerry Xu <[email-masked]>
Subject: Re: FW: M2UA Question ....
Cc: [email-masked], [email-masked]
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]

<x-flowed>Hi,

Another similar question, in M2UA Version 7, there is an audit message sent
from ASP to SG M2UA. Basically, it tries to get the link state information.

I didn't see any detail spec in M2UA Version 7. I guess it's an
implementation dependent. You can get link state either from MTP2 or keep
one copy of the link state in M2UA.

As stated in the following message -- "the MTP specs do not standardize the
interface boundary between L2 and L3.
They are an illustrative partitioning of MTP functions."

Most of third part MTP2 software don't have such API for upper layer to
query link state.

Is there someone out there thinking about this ? which way is better and
reason?

Thanks

Jerry

At 09:12 AM 4/20/01 -0700, you wrote:

>Ken,
>
>I checked the MTP3 specs, and the SDL's do not have legs for receipt of
>confirm primitive for certain requests. When MTP3 sends a request to do
>emergency alignment, it is not going to have a state to wait for the
>confirm. If MTP3 were to actually wait for the confirm then the failure and
>retry legs (if no confirm was received) would have to be defined. If not
>then the confirm primitive would just be dropped by MTP3 which would defeat
>its purpose.
>
>The interface in Q.704 is illustrative partioning which just implies that
>you can club the functionality in any number of primitives with any names.
>It however does not imply that you send unexpected confirms.
>
>CP
>
>-----Original Message-----
>From: Ken Morneault [mailto:[email-masked]]
>Sent: Wednesday, April 18, 2001 3:33 PM
>To: sigtran
>Subject: Re: M2UA Question ....
>
>
>
>
>Sandeep,
>
>The opposite question was asked of an earlier release of the draft
>that did NOT have "results" returned for Status information such
>as LPO_SET, etc.  At that time, it was decided it would be
>useful to add confirmations.
>
>It is possible that an SG may have an internal error that causes
>a failure while acting on the Status information.  It may be useful for
>an implementation to be able to receive such a failure notification.
>
>Regarding the specs, the MTP specs do not standardize the interface
>boundary between L2 and L3.  They are an illustrative partitioning
>of MTP functions.
>
>Regards,
>
>Ken
>
>At 12:45 PM 4/18/01 -0700, Balani, Sandeep wrote:
> >Hi All,
> >   I have a question about the interface between M2UA/MTP3 and M2UA/MTP2
>via
> >NIF.
> >
> >   To my understanding in ITU specifications for MTP2/MTP3, when MTP3
sends
> >Status information to MTP2 for cases like LPO_SET, LPO_CLEAR, EMERGENCY,
> >EMERGENCY_CEASES, MTP3 doesn't expect any response  ( such as Status done
)
> >from MTP2, but in the M2UA draft for all the above events a Confirmation
is
> >expected at MTP3/M2UA boundary and at IP layer ( between SG and ASP ).
> >
> >I think for all the above cases this is just an status set information
>given
> >to MTP2 and MTP3 does'nt have any state machine dependency on the confirm
>of
> >this information, then why this confirm is a part of M2UA draft and why
are
> >there Confirm at all for such cases ?
> >
> >Of course Status confirmation is need for cases such as Retrieve BSN,
> >Retrieve message, flow control status where an information need to be
> >transfered to MTP3, but for other cases i don't think we need such
> >confirmation ? please correct me here.
> >
> >
> >Thanks
> >Sandeep
> >
> >
> >
> >
> >---
> >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] </x-flowed>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA: Management Blocking at the SG
Date: Tue, 1 May 2001 13:58:14 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: M3UA: Management Blocking at the SG</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>I'm not sure that what Hanns-Juergen and Kurt propose as
solutions here is consistent with the original problem.&nbsp; The original
management blocking that I had in mind was simply to allow the SG to refuse
an individual ASP-Up request, as a temporary ASP lock-out, not as a general
mechanism to also force any other ASPs that are currently &quot;inactive or
active&quot; to go &quot;down&quot;.&nbsp;&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=2>The M3UA currently doesn't have a mechanism for the SG to
&quot;force&quot; a change in the ASP or AS state.&nbsp; Kurt's
interpretation that this was subtly intended by the ASP-DOWN text was
interesting - but this was not the real reason behind the text.&nbsp; The
text was like that to cover the point-to-point case where two ASPs are
peers, with no SG.</FONT></P>

<P><FONT SIZE=2>The spec so far follows the assumption that the ASPs (using
inter-ASP communication where necessary) are the masters in charge of the
initiation of ASP and AS state changes.&nbsp;&nbsp; The Notify message is
more of an indication to an ASP of a change in the AS state or an indication
of a change of ASP roles within the AS.&nbsp; An ASP can compare this
notification to their view of the ASP/AS state and could take action, but I
thought it was clear that the ASPs are not obligated.&nbsp; Certainly for at
least the &quot;AS-Pending&quot; or &quot;Insufficient ASP Resources active
in AS&quot; Notifies, it is clear in Section 4.3.3.6 that &quot;the Notify
does not explicitly compel the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) traffic action is
taken.&quot;&nbsp;&nbsp; In this context, I have no problem adding the new
Notifies that Hanns-Juergen and/or Kurt suggests, with the continuing
proviso that they are &quot;non-compelling&quot;</FONT></P>

<P><FONT SIZE=2>So, do we want to continue with the assumption that the ASPs
are the masters for the initiation of AS/ASP state changes or do we want to
add to the SG the ability to force ASPs&nbsp; to &quot;down or
inactive&quot;.&nbsp; This has been requested a couple of times in the past
but I thought the rough consensus then and now was that this was not
needed.&nbsp;&nbsp; If we conclude that it is now needed, then we should
probably run with Kurt's suggestions, rather than using
Notifies.&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=2>Feedback, flames welcome!</FONT> </P>

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

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

<P><FONT SIZE=2>PS: I'm not ruling out any other protocol solutions - but
lets agree on the requirement first. </FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Kurt Kite [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Saturday, April 21, 2001 12:31
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re:
M3UA: Management Blocking at the SG</FONT> </P>

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

<P><FONT SIZE=2>Some of this has been discussed before, but I would not say
that any consensus</FONT> <BR><FONT SIZE=2>was reached. See below for some
comments.</FONT> </P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Kurt</FONT>
</P>

<P><FONT SIZE=2>Schwarzbauer Hanns Juergen wrote:</FONT> </P>

<P><FONT SIZE=2>&gt; Folks,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; hopefully I didn't miss some old E-Mails in case the
issue shown below has already been discussed.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Chapter 4.3.3.1 &quot;ASP-UP&quot; contains a very
short paragraph talking about the case where on</FONT> <BR><FONT SIZE=2>&gt;
the SG a management action was taken, forcing the SG to respond to
subsequent ASP-UP</FONT> <BR><FONT SIZE=2>&gt; messages with ASP-Down Ack as
shown below:</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
blocking&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-UP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Question:</FONT>
<BR><FONT SIZE=2>&gt; What should happen, if there are already aktive ASP's
when this management action is taken?</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; My proposal to handle this is shown below:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY
(ASP-blocked)&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Down&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The proposed contents of NOTIFY message would
be:</FONT> <BR><FONT SIZE=2>&gt; Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 2, &quot;other&quot; (already there)</FONT> <BR><FONT SIZE=2>&gt;
Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 3, &quot;ASP blocked (to
be added)</FONT> </P>

<P><FONT SIZE=2>I believe that the draft intended to use the ASP-Down
message to accomplish</FONT> <BR><FONT SIZE=2>the above.</FONT>
</P>

<P><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&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;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp; management|----------------------------&gt;|</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&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;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Down&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&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;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; |</FONT> </P>

<P><FONT SIZE=2>The ASP-Down content is:</FONT> <BR><FONT SIZE=2>Reason:
Management Blocking</FONT> </P>

<P><FONT SIZE=2>Reception of an ASP-Down with the above reason would force
the ASP</FONT> <BR><FONT SIZE=2>to move the ASP to a Down state and send an
ASP-Down Ack.</FONT> <BR><FONT SIZE=2>You will notice that the draft is
careful to say that the ASP-Down &quot;is used</FONT> <BR><FONT SIZE=2>to
indicate to a remote M3UA peer . . . .&quot; It does not restrict the
ASP-Down</FONT> <BR><FONT SIZE=2>from being sent only from the ASP to the
SG. However, this procedure is not</FONT> <BR><FONT SIZE=2>explicitly
described in the draft.</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; This Notify message would force the receiving ASP to
initiate the</FONT> <BR><FONT SIZE=2>&gt; ASP-Down procedure. The SG might
want to start a supervision timer</FONT> <BR><FONT SIZE=2>&gt; and upon its
expiry could initiate the SCTP shutdown procedure.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Now having a clean procedure to force an ASP to enter
the ASP-Down state</FONT> <BR><FONT SIZE=2>&gt; initiated by the SG, we
could alsowell ask why not to have the same</FONT> <BR><FONT SIZE=2>&gt;
mechanism to handle blocking of Routing Context at the SG (some
operators</FONT> <BR><FONT SIZE=2>&gt; might want to do this, intentionally
or not).</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The proposed procedure is shown below:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Active(RC1)&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Active
Ack(RC1) |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
blocking&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (RC-blocked,RC1) |</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Inactive(RC1)&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Inactive ACK(RC1)&nbsp;
|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The proposed contents of NOTIFY message would
be:</FONT> <BR><FONT SIZE=2>&gt; Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 2, &quot;other&quot; (already there)</FONT> <BR><FONT SIZE=2>&gt;
Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 4, &quot;RC blocked (to
be added)</FONT> </P>

<P><FONT SIZE=2>I raised the same question earlier. You can read the mails
with</FONT> <BR><FONT SIZE=2>subject &quot;Static Configuration&quot; for
all of the details. My issue</FONT> <BR><FONT SIZE=2>was that the operator
wanted to remove an AS from the SG</FONT> <BR><FONT SIZE=2>configuration
data. The proposed solution was similar to the</FONT> <BR><FONT SIZE=2>one
you describe above.</FONT> </P>

<P><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&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;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Active(RC1)&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Active Ack(RC1)
|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
removal&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; |</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (AS-Inactive,RC1)|</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&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;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; |</FONT> </P>

<P><FONT SIZE=2>The proposed contents of NOTIFY message would be:</FONT>
<BR><FONT SIZE=2>Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 1, &quot;AS state change&quot; (already there)</FONT> <BR><FONT
SIZE=2>Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 2,
&quot;AS-Inactive&quot; (already there)</FONT> </P>

<P><FONT SIZE=2>The NOTIFY message would force the receiving ASP to mark
the</FONT> <BR><FONT SIZE=2>RC as Inactive. There is already a precedent for
this with the NOTIFY</FONT> <BR><FONT SIZE=2>message with the
&quot;Alternate ASP Active&quot; status information. This</FONT> <BR><FONT
SIZE=2>solution eliminates a couple of messages and the need for a
timer.</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; This Notify message would force the receiving ASP to
initiate the</FONT> <BR><FONT SIZE=2>&gt; ASP-Inactive procedure for that
RC. The SG might want to start a</FONT> <BR><FONT SIZE=2>&gt; supervision
timer and upon its expiry could initiate the SCTP</FONT> <BR><FONT
SIZE=2>&gt; shutdown procedure, thus however, bringing the whole ASP
down.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Two more scenarios should be considered:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; a) no ASP in Active state at all</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
blocking&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (RC-blocked,RC1) |</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;| do nothing, if no</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&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; | ASP-Active was sent</FONT> </P>

<P><FONT SIZE=2>The above scenario goes away if the NOTIFY forces the
ASP</FONT> <BR><FONT SIZE=2>to move the RC into the Inactive state as I
described above.</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; b)race condition ASP-Active and NOTIFY</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; ASP-Active(RC1)|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; blocking&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------|</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY|(RC-blocked,RC1) |</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |-----------|----------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;
|&lt;----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp; respond
with|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Inactive ACK(RC1)&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; ASPIA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Resolving this race condition would require allowing
to acknowledge an</FONT> <BR><FONT SIZE=2>&gt; ASP-Active message with an
ASP-Inactive message. However, this is already</FONT> <BR><FONT SIZE=2>&gt;
allowed for the ASP-Up as shown in the first figure.</FONT> </P>

<P><FONT SIZE=2>Yes, it is already allowed for the ASP-Up, but I think that
makes the protocol</FONT> <BR><FONT SIZE=2>more complicated and confusing
than it needs to be. Why not just use the ERR</FONT> <BR><FONT
SIZE=2>message for these kinds of response. Why have an Ack message that can
indicate</FONT> <BR><FONT SIZE=2>both success and failure and the ERR
message that can also indicate failure?</FONT> </P>

<P><FONT SIZE=2>I propose that ERR (new error &quot;Management
Blocked&quot;) be used in this case.</FONT> <BR><FONT SIZE=2>I wouldn't mind
using ERR for the ASP Up case as well. 8^).</FONT> </P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Kurt</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; looking forward hearing from you guys</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; HannsJuergen</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; SIEMENS AG</FONT> <BR><FONT SIZE=2>&gt; Information
and Communication Networks</FONT> <BR><FONT SIZE=2>&gt; Wireline Network
Communication</FONT> <BR><FONT SIZE=2>&gt; Carrier Switching Networks</FONT>
<BR><FONT SIZE=2>&gt; ICN WN CS SE 51</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Tel:&nbsp;&nbsp;&nbsp; +49 89 722 24236</FONT>
<BR><FONT SIZE=2>&gt; Fax:&nbsp;&nbsp;&nbsp; +49 89 722 48212</FONT>
<BR><FONT SIZE=2>&gt; E-mail [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send a
blank email to [email-masked]</FONT> </P>
<BR>
<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>
From: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: ENUM : some explanation on the use of GTT
Date: Wed, 2 May 2001 11:56:02 +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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Michael,

Yes, the IP-address is global in scope, but so is the pointcode (at least in
US).

But GT routing has a bunch of additional features :

- loadsharing and primary/backup routing (of course, this has to be seen on
top of what's provided by ASP management, or MTP alias point codes and
combined linkset)
- address conversion of both called and calling party address - unique
identification of user or network node - screening, accounting of SUA
messages - support for number portability

Also, IP addresses may not always be global in scope (NAT, etc.)

In terms of SCTP, it means one doesn't have to know the IP-address of every
communication partner, and in particular, you don't have to set up
associations with every possible communication partner. As an example, take
the 3GPP architecture for 3G mobile networks : the subscriber's HLR is found
based on his E.164 number and routing then goes like this (e.g.
international roaming)

1. Visited MSC performs GTT and forwards message to it's own outgoing
gateway (roaming subscriber)
2. Outgoing gateway performs GTT and forwards message (via international
network) to "incoming" gateway of destination network (where the
subscriber's HLR is located)
3. Incoming gateway performs GTT and finally forwards the message to the HLR
!

So the routing database is distributed. Imagine the address of the HLR
changes (locally) : only the database in the incoming gateway then has to be
changed. If every MSC had an SCTP association with every HLR, then each MSC
would be affected by a change of the HLR's address ...

Best regards,

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

-----Original Message-----
From: Young Michael-Y10724 [mailto:[email-masked]] Sent: dinsdag
1 mei 2001 17:54
To: sigtran
Subject: RE: ENUM : some explanation on the use of GTT

Hi Gery, 
> 1. First of all, GT routing enhances the routing capabilities of the 
> underlying layers (MTP just routes on point codes, IP just on 
> IP addresses). 
> In SS7, it's useful to cross network boundaries (the same 
> point codes can be 
> (re)used in different networks, SSNs may have a different meaning in 
> different networks, etc.). Does this bring anything in an all 
> IP environment 
> ? At least it might be useful to seperate networks, in the sence that 
> administration in one network is not influenced by a change in other 
> (operator's) networks, except in the gateway where this network border 
> crossing is executed. 
> Your administration/management functions will be influenced 
> if you just work 
> in an end-to-end mode, and have to setup SCTP associations with every 
> possible communication partner in everybody elses network ... 
> And if you 
> want to send a critical signalling message, you don't want 
> the burden of 
> setting up a new SCTP association first ! 
I can understand that GT routing enhances the routing capabilities of MTP as
point code based routing is hop by hop.  However, I don't the understand the
enhancement to IP routing.  I view IP address as kind of Global Title.  Can
you please elaborate more on this?
Thanks, 
Michael 

---
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: [M3UA] AS state machine sharing between SGPs
Date: Wed, 2 May 2001 14:17:06 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2
cents on this topic anyway ;-))

We're talking about redundancy on three different levels, I think :

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as
well, or am I missing something here ? (Multiple routes, handled by multiple
processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is
responsible of informing layer management of it's part of the view (status
of physical connections).

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic.

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two.

Any views on this ?

____________________________

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

-----Original Message-----
From: Kazuo Watanabe [mailto:[email-masked]] Sent: dinsdag 1 mei
2001 6:27
To: sigtran
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs

Greg,

> In the case where there are multiple SGPs in an SG, and the SGPs have
> magically determined in their coordinated MTP3 route management logic that
> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU
> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the

no.
i think all concerned ASPs should receive but not all SGPs should send.
because DUNA indicates SS7 route state not SG/SGP state.

> answer is yes given the logic of the discussion on this thread.  So that
> means that if the triggering event is reception of TFP(s) from the SS7
> network, then all SGPs in an SG must coordinate their MTP3 view of the
> availability of the SS7 destination.   Equivalent arguments can be made
for
> virtually any SS7 link or route management event.

yes.
i think this is `multiple SGPs in an SG.'

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view.
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP.

in that case, each SGP could have different AS state and should have the
same SS7 state.

> Also, if one SGP has determined an SS7 destination is unavailable, but the
> destination is still available via other SGPs (a link event?), then I
assume

according to my understanding, this is multiple SGs not multiple SGPs in an
SG.

> that the SGP would optionally send an DRST - although we could make the
case
> that a DUPU could be used by SGP implementations that don't redirect any
> traffic received to the other SGPs.  I wouldn't recommend it though as
this
> implies message loss.
> Does this sound right?

if you are saying about STP-like SGs configuration, it sounds right to me.

-- 
Kazuo Watanabe

---
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, 02 May 2001 08:44:01 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: ENUM : some explanation on the use of GTT
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]

I would like to emphasize Gery's paragraph ...

"> So the routing database is distributed. Imagine the address of the HLR
> changes (locally) : only the database in the incoming gateway then has to
be
> changed. If every MSC had an SCTP association with every HLR, then each
MSC
> would be affected by a change of the HLR's address ...the comment"

This is a very important point, i.e., the point that GTT keeps you from
having to administer the addresses of everyone else's network, albeit point
codes or IP addresses. All each network needs to administer is the address
of each network's gateway (which are STP pairs in today's network).  The
Gateway then handles the addressing within its own network.  Without this
architecture, you have an administrative nightmare.  For example, let's say
networks a,b,c&d have 5000 signaling points among them and they all talk to
network e.  If network e makes a change to its network, adds a node, or a
new NPA-NXX that network a,b,c&d want to talk to, then all 5000 signaling
points need to make a change if they don't use a mechanism like GTT.  If
memory serves me well, I think there are on the order of several thousand of
these chagnes a month.  Ouch times 5000.  Using GTT, only the GTT databases
need to be changed in the Gateways (much easier).  

Jeff

Verwimp Gery wrote:
> 
> Hello Michael,
> 
> Yes, the IP-address is global in scope, but so is the pointcode (at least
in
> US).
> 
> But GT routing has a bunch of additional features :
> 
> - loadsharing and primary/backup routing (of course, this has to be seen
on
> top of what's provided by ASP management, or MTP alias point codes and
> combined linkset)
> - address conversion of both called and calling party address
> - unique identification of user or network node
> - screening, accounting of SUA messages
> - support for number portability
> 
> Also, IP addresses may not always be global in scope (NAT, etc.)
> 
> In terms of SCTP, it means one doesn't have to know the IP-address of
every
> communication partner, and in particular, you don't have to set up
> associations with every possible communication partner. As an example,
take
> the 3GPP architecture for 3G mobile networks : the subscriber's HLR is
found
> based on his E.164 number and routing then goes like this (e.g.
> international roaming)
> 
> 1. Visited MSC performs GTT and forwards message to it's own outgoing
> gateway (roaming subscriber)
> 2. Outgoing gateway performs GTT and forwards message (via international
> network) to "incoming" gateway of destination network (where the
> subscriber's HLR is located)
> 3. Incoming gateway performs GTT and finally forwards the message to the
HLR
> !
> 
> So the routing database is distributed. Imagine the address of the HLR
> changes (locally) : only the database in the incoming gateway then has to
be
> changed. If every MSC had an SCTP association with every HLR, then each
MSC
> would be affected by a change of the HLR's address ...
> 
> Best regards,
> 
> ____________________________
> Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> -----Original Message-----
> From: Young Michael-Y10724 [mailto:[email-masked]]
> Sent: dinsdag 1 mei 2001 17:54
> To: sigtran
> Subject: RE: ENUM : some explanation on the use of GTT
> 
> Hi Gery,
> > 1. First of all, GT routing enhances the routing capabilities of the
> > underlying layers (MTP just routes on point codes, IP just on
> > IP addresses).
> > In SS7, it's useful to cross network boundaries (the same
> > point codes can be
> > (re)used in different networks, SSNs may have a different meaning in
> > different networks, etc.). Does this bring anything in an all
> > IP environment
> > ? At least it might be useful to seperate networks, in the sence that
> > administration in one network is not influenced by a change in other
> > (operator's) networks, except in the gateway where this network border
> > crossing is executed.
> > Your administration/management functions will be influenced
> > if you just work
> > in an end-to-end mode, and have to setup SCTP associations with every
> > possible communication partner in everybody elses network ...
> > And if you
> > want to send a critical signalling message, you don't want
> > the burden of
> > setting up a new SCTP association first !
> I can understand that GT routing enhances the routing capabilities of MTP
as
> point code based routing is hop by hop.  However, I don't the understand
the
> enhancement to IP routing.  I view IP address as kind of Global Title.
Can
> you please elaborate more on this?
> Thanks,
> Michael
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley3.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 02 May 2001 10:33:23 -0500
From: Qiaobing Xie <[email-masked]>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: Re: ENUM : some explanation on the use of GTT
X-SMTP-HELO: ftpbox.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ftpbox.mot.com [129.188.136.101]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

...
> 1. Visited MSC performs GTT and forwards message to it's own outgoing
> gateway (roaming subscriber)
> 2. Outgoing gateway performs GTT and forwards message (via international
> network) to "incoming" gateway of destination network (where the
> subscriber's HLR is located)
> 3. Incoming gateway performs GTT and finally forwards the message to the
HLR

Gery,

In IP's term, this GTT function can be performed by DNS. Your statement
below only becomes true if there is no DNS function present in the network,
in such a case every one would need to know the other's IP address before
they can communicate.

> 
> So the routing database is distributed. Imagine the address of the HLR
> changes (locally) : only the database in the incoming gateway then has to
be
> changed. If every MSC had an SCTP association with every HLR, then each
MSC
> would be affected by a change of the HLR's address ...

This is not true. You can always assign the destination HLR a host name
(e.g., hlr101.operator.com). If the local administrator moves the HLR to a
different subnet and changes its IP address, as long as he/she updates the
DNS entry, nothing on the originating MSC will be affected.

-Qiaobing

> 
> Best regards,
> 
> ____________________________
> Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> -----Original Message-----
> From: Young Michael-Y10724 [mailto:[email-masked]]
> Sent: dinsdag 1 mei 2001 17:54
> To: sigtran
> Subject: RE: ENUM : some explanation on the use of GTT
> 
> Hi Gery,
> > 1. First of all, GT routing enhances the routing capabilities of the
> > underlying layers (MTP just routes on point codes, IP just on
> > IP addresses).
> > In SS7, it's useful to cross network boundaries (the same
> > point codes can be
> > (re)used in different networks, SSNs may have a different meaning in
> > different networks, etc.). Does this bring anything in an all
> > IP environment
> > ? At least it might be useful to seperate networks, in the sence that
> > administration in one network is not influenced by a change in other
> > (operator's) networks, except in the gateway where this network border
> > crossing is executed.
> > Your administration/management functions will be influenced
> > if you just work
> > in an end-to-end mode, and have to setup SCTP associations with every
> > possible communication partner in everybody elses network ...
> > And if you
> > want to send a critical signalling message, you don't want
> > the burden of
> > setting up a new SCTP association first !
> I can understand that GT routing enhances the routing capabilities of MTP
as
> point code based routing is hop by hop.  However, I don't the understand
the
> enhancement to IP routing.  I view IP address as kind of Global Title.
Can
> you please elaborate more on this?
> Thanks,
> Michael
> 
> ---
> 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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: ENUM : some explanation on the use of GTT
Date: Wed, 2 May 2001 18:25:56 +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]

Hello Qiaobing,

Yes, that's a valid alternative (routing on hostname) ! And ENUM can be used
to change an E.164 number to a hostname or IP-address directly ...

Actually, we enlarged the scope of GTT a bit to incorporate routing on
hostname as well, so maybe the term "Address translation" is better (less
confusing), with whatever means this is accomplished (DNS, ENUM, LDAP, ...)
as long as performance requirements are met.

But I think you agree it's beyond routing purely on IP-addresses ?

-Gery

____________________________

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

-----Original Message-----
From: Qiaobing Xie [mailto:[email-masked]] Sent: woensdag 2 mei 2001
17:33
To: sigtran
Cc: [email-masked]
Subject: Re: ENUM : some explanation on the use of GTT

...
> 1. Visited MSC performs GTT and forwards message to it's own outgoing
> gateway (roaming subscriber)
> 2. Outgoing gateway performs GTT and forwards message (via international
> network) to "incoming" gateway of destination network (where the
> subscriber's HLR is located)
> 3. Incoming gateway performs GTT and finally forwards the message to the
HLR

Gery,

In IP's term, this GTT function can be performed by DNS. Your statement
below only becomes true if there is no DNS function present in the network,
in such a case every one would need to know the other's IP address before
they can communicate.

> 
> So the routing database is distributed. Imagine the address of the HLR
> changes (locally) : only the database in the incoming gateway then has to
be
> changed. If every MSC had an SCTP association with every HLR, then each
MSC
> would be affected by a change of the HLR's address ...

This is not true. You can always assign the destination HLR a host name
(e.g., hlr101.operator.com). If the local administrator moves the HLR to a
different subnet and changes its IP address, as long as he/she updates the
DNS entry, nothing on the originating MSC will be affected.

-Qiaobing

> 
> Best regards,
> 
> ____________________________
> Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> -----Original Message-----
> From: Young Michael-Y10724 [mailto:[email-masked]]
> Sent: dinsdag 1 mei 2001 17:54
> To: sigtran
> Subject: RE: ENUM : some explanation on the use of GTT
> 
> Hi Gery,
> > 1. First of all, GT routing enhances the routing capabilities of the
> > underlying layers (MTP just routes on point codes, IP just on
> > IP addresses).
> > In SS7, it's useful to cross network boundaries (the same
> > point codes can be
> > (re)used in different networks, SSNs may have a different meaning in
> > different networks, etc.). Does this bring anything in an all
> > IP environment
> > ? At least it might be useful to seperate networks, in the sence that
> > administration in one network is not influenced by a change in other
> > (operator's) networks, except in the gateway where this network border
> > crossing is executed.
> > Your administration/management functions will be influenced
> > if you just work
> > in an end-to-end mode, and have to setup SCTP associations with every
> > possible communication partner in everybody elses network ...
> > And if you
> > want to send a critical signalling message, you don't want
> > the burden of
> > setting up a new SCTP association first !
> I can understand that GT routing enhances the routing capabilities of MTP
as
> point code based routing is hop by hop.  However, I don't the understand
the
> enhancement to IP routing.  I view IP address as kind of Global Title.
Can
> you please elaborate more on this?
> Thanks,
> Michael
> 
> ---
> 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: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: ENUM : some explanation on the use of GTT
Date: Wed, 2 May 2001 18:32:56 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: woensdag 2 mei 2001 17:33
> To: sigtran
> Cc: [email-masked]
> Subject: Re: ENUM : some explanation on the use of GTT
> 
> 
> ...
> > 1. Visited MSC performs GTT and forwards message to it's 
> own outgoing
> > gateway (roaming subscriber)
> > 2. Outgoing gateway performs GTT and forwards message (via 
> international
> > network) to "incoming" gateway of destination network (where the
> > subscriber's HLR is located)
> > 3. Incoming gateway performs GTT and finally forwards the 
> message to the HLR
> 
> Gery,
> 
> In IP's term, this GTT function can be performed by DNS. Your 
> statement
> below only becomes true if there is no DNS function present in the
> network, in such a case every one would need to know the other's IP
> address before they can communicate.

Not really, they only would have to know the destination GT, and the IP
address of a SUA relay point/gateway. 
However if you only take into account the point-to-point case, then you are
right.
> 
> > 
> > So the routing database is distributed. Imagine the address 
> of the HLR
> > changes (locally) : only the database in the incoming 
> gateway then has to be
> > changed. If every MSC had an SCTP association with every 
> HLR, then each MSC
> > would be affected by a change of the HLR's address ...
> 
> This is not true. You can always assign the destination HLR a 
> host name
> (e.g., hlr101.operator.com). If the local administrator moves 
> the HLR to
> a different subnet and changes its IP address, as long as 
> he/she updates
> the DNS entry, nothing on the originating MSC will be affected.

correct, but then this update of the DNS needs to be distributed(and this
does not happen instantanously). In any case , with or without the use of
DNS, the originating MSC will not be affected: the question is more with
DNS: do I make the resolving global(like in DNS) or do I keep it local(like
in GTT). It becomes more a filosofical argument at that point. 
(By the way sometimes HLR are split or subscribers transfered from one to
another HLR.  Quite some interesting possibilities could occur)

In any case there are some DNS hooks that are possible within SUA.

And by the way, we should try to limit the overloading of the DNS(as
presented in the plenary at San Diego) otherwise a very angry mob could be
chasing us in a couple of years from here: I'll SMS something and then we
invoke the DNS: ahhum ...huhh 

Yours sincerly,
Lode

> 
> -Qiaobing
> 
> > 
> > Best regards,
> > 
> > ____________________________
> > 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]
To: "sigtran" <[email-masked]>
Date: Wed, 02 May 2001 09:33:22 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: ENUM : some explanation on the use of GTT
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

DNS is not a bad analogy, I think.  GTT allows you to use an address that is
not routable in the signaling network, such as an 800 telephone number.  DNS
similarly allows you to use a more user-friendly name rather than the actual
routing address.

The mechanism is different, though, the GTT translation point actually
forwards each message, whereas DNS requires a separate query for resolution,
and would typically not be done per message. 

Cheers,

Lyndon
--

On Wed, 02 May 2001 10:33:23   Qiaobing Xie wrote:
>...
>> 1. Visited MSC performs GTT and forwards message to it's own outgoing
>> gateway (roaming subscriber)
>> 2. Outgoing gateway performs GTT and forwards message (via international
>> network) to "incoming" gateway of destination network (where the
>> subscriber's HLR is located)
>> 3. Incoming gateway performs GTT and finally forwards the message to the
HLR
>
>Gery,
>
>In IP's term, this GTT function can be performed by DNS. Your statement
>below only becomes true if there is no DNS function present in the
>network, in such a case every one would need to know the other's IP
>address before they can communicate.
>
>> 
>> So the routing database is distributed. Imagine the address of the HLR
>> changes (locally) : only the database in the incoming gateway then has to
be
>> changed. If every MSC had an SCTP association with every HLR, then each
MSC
>> would be affected by a change of the HLR's address ...
>
>This is not true. You can always assign the destination HLR a host name
>(e.g., hlr101.operator.com). If the local administrator moves the HLR to
>a different subnet and changes its IP address, as long as he/she updates
>the DNS entry, nothing on the originating MSC will be affected.
>
>-Qiaobing
>
>> 
>> Best regards,
>> 
>> ____________________________
>> Gery Verwimp
>> SIEMENS ATEA
>> ICN D CS D5
>> Tel. : +32 14 25 3424
>> Fax : +32 14 25 3212
>> mailto:[email-masked]
>> ____________________________________
>> 
>> -----Original Message-----
>> From: Young Michael-Y10724 [mailto:[email-masked]]
>> Sent: dinsdag 1 mei 2001 17:54
>> To: sigtran
>> Subject: RE: ENUM : some explanation on the use of GTT
>> 
>> Hi Gery,
>> > 1. First of all, GT routing enhances the routing capabilities of the
>> > underlying layers (MTP just routes on point codes, IP just on
>> > IP addresses).
>> > In SS7, it's useful to cross network boundaries (the same
>> > point codes can be
>> > (re)used in different networks, SSNs may have a different meaning in
>> > different networks, etc.). Does this bring anything in an all
>> > IP environment
>> > ? At least it might be useful to seperate networks, in the sence that
>> > administration in one network is not influenced by a change in other
>> > (operator's) networks, except in the gateway where this network border
>> > crossing is executed.
>> > Your administration/management functions will be influenced
>> > if you just work
>> > in an end-to-end mode, and have to setup SCTP associations with every
>> > possible communication partner in everybody elses network ...
>> > And if you
>> > want to send a critical signalling message, you don't want
>> > the burden of
>> > setting up a new SCTP association first !
>> I can understand that GT routing enhances the routing capabilities of MTP
as
>> point code based routing is hop by hop.  However, I don't the understand
the
>> enhancement to IP routing.  I view IP address as kind of Global Title.
Can
>> you please elaborate more on this?
>> Thanks,
>> Michael
>> 
>> ---
>> 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]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Miriyala Srinivas-FSM016 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: ENUM : some explanation on the use of GTT
Date: Wed, 2 May 2001 13:31:09 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate2.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate2.mot.com [136.182.1.10]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Gery,

You raised a good point here. I think we should avoid the term GTT in the
SUA. I would call it as 'Address Mapping' because 'Address Translation'
might sound like NAT functionality.

Regards
Srini

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]] Sent: Wednesday,
May 02, 2001 11:26 AM
To: sigtran
Subject: RE: ENUM : some explanation on the use of GTT

Hello Qiaobing,

Yes, that's a valid alternative (routing on hostname) ! And ENUM can be used
to change an E.164 number to a hostname or IP-address directly ...

Actually, we enlarged the scope of GTT a bit to incorporate routing on
hostname as well, so maybe the term "Address translation" is better (less
confusing), with whatever means this is accomplished (DNS, ENUM, LDAP, ...)
as long as performance requirements are met.

But I think you agree it's beyond routing purely on IP-addresses ?

-Gery

____________________________

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

-----Original Message-----
From: Qiaobing Xie [mailto:[email-masked]] Sent: woensdag 2 mei 2001
17:33
To: sigtran
Cc: [email-masked]
Subject: Re: ENUM : some explanation on the use of GTT

...
> 1. Visited MSC performs GTT and forwards message to it's own outgoing
> gateway (roaming subscriber)
> 2. Outgoing gateway performs GTT and forwards message (via international
> network) to "incoming" gateway of destination network (where the
> subscriber's HLR is located)
> 3. Incoming gateway performs GTT and finally forwards the message to the
HLR

Gery,

In IP's term, this GTT function can be performed by DNS. Your statement
below only becomes true if there is no DNS function present in the network,
in such a case every one would need to know the other's IP address before
they can communicate.

> 
> So the routing database is distributed. Imagine the address of the HLR
> changes (locally) : only the database in the incoming gateway then has to
be
> changed. If every MSC had an SCTP association with every HLR, then each
MSC
> would be affected by a change of the HLR's address ...

This is not true. You can always assign the destination HLR a host name
(e.g., hlr101.operator.com). If the local administrator moves the HLR to a
different subnet and changes its IP address, as long as he/she updates the
DNS entry, nothing on the originating MSC will be affected.

-Qiaobing

> 
> Best regards,
> 
> ____________________________
> Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> -----Original Message-----
> From: Young Michael-Y10724 [mailto:[email-masked]]
> Sent: dinsdag 1 mei 2001 17:54
> To: sigtran
> Subject: RE: ENUM : some explanation on the use of GTT
> 
> Hi Gery,
> > 1. First of all, GT routing enhances the routing capabilities of the
> > underlying layers (MTP just routes on point codes, IP just on
> > IP addresses).
> > In SS7, it's useful to cross network boundaries (the same
> > point codes can be
> > (re)used in different networks, SSNs may have a different meaning in
> > different networks, etc.). Does this bring anything in an all
> > IP environment
> > ? At least it might be useful to seperate networks, in the sence that
> > administration in one network is not influenced by a change in other
> > (operator's) networks, except in the gateway where this network border
> > crossing is executed.
> > Your administration/management functions will be influenced
> > if you just work
> > in an end-to-end mode, and have to setup SCTP associations with every
> > possible communication partner in everybody elses network ...
> > And if you
> > want to send a critical signalling message, you don't want
> > the burden of
> > setting up a new SCTP association first !
> I can understand that GT routing enhances the routing capabilities of MTP
as
> point code based routing is hop by hop.  However, I don't the understand
the
> enhancement to IP routing.  I view IP address as kind of Global Title.
Can
> you please elaborate more on this?
> Thanks,
> Michael
> 
> ---
> 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: Wed, 02 May 2001 14:42:54 -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: M3UA: Management Blocking at the SG
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [12.34.240.68]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

See comments below please.

Regards,
Kurt

"Sidebottom, Greg [BCNR:7M01:EXCH]" wrote:

>
>
> Greetings,
>
> I'm not sure that what Hanns-Juergen and Kurt propose as solutions
> here is consistent with the original problem.  The original management
> blocking that I had in mind was simply to allow the SG to refuse an
> individual ASP-Up request, as a temporary ASP lock-out, not as a
> general mechanism to also force any other ASPs that are currently
> "inactive or active" to go "down".

Yes, they are solutions to a new set of problems. In the case of static
configuration, it is probably reasonable to allow the configuration to be
changed independently. So, it is possible that an AS definition to be
removed from the SG after it has become Active.

>
>
> The M3UA currently doesn't have a mechanism for the SG to "force" a
> change in the ASP or AS state.  Kurt's interpretation that this was
> subtly intended by the ASP-DOWN text was interesting - but this was
> not the real reason behind the text.  The text was like that to cover
> the point-to-point case where two ASPs are peers, with no SG.

I was just looking for any solution that would not extend the protocol.
8^)

>
>
> The spec so far follows the assumption that the ASPs (using inter-ASP
> communication where necessary) are the masters in charge of the
> initiation of ASP and AS state changes.   The Notify message is more
> of an indication to an ASP of a change in the AS state or an
> indication of a change of ASP roles within the AS.  An ASP can compare
> this notification to their view of the ASP/AS state and could take
> action, but I thought it was clear that the ASPs are not obligated.
> Certainly for at least the "AS-Pending" or "Insufficient ASP Resources
> active in AS" Notifies, it is clear in Section 4.3.3.6 that "the
> Notify does not explicitly compel the ASP(s) receiving the message to
> become active. The ASPs remain in control of what (and when) traffic
> action is taken."   In this context, I have no problem adding the new
> Notifies that Hanns-Juergen and/or Kurt suggests, with the continuing
> proviso that they are "non-compelling"

I agree in general that the ASP normally dictates ASP and AS state changes.
However, I would argue that the Notify (Alternate ASP Active) forces the ASP
into the Inactive state, albeit at due to another ASP sending an ASP Active
for an AS in Over-ride mode.

In any case, I think that certain actions on the SG, like an operator
removing configuration data, should force the ASP to change state. I do not
think that the SG should ever be able to force the ASP to become Active for
an AS, but it should be able to force the ASP to become Inactive. The ASP is
then free to remain Inactive or to become Active again.

>
>
> So, do we want to continue with the assumption that the ASPs are the
> masters for the initiation of AS/ASP state changes or do we want to
> add to the SG the ability to force ASPs  to "down or inactive".  This
> has been requested a couple of times in the past but I thought the
> rough consensus then and now was that this was not needed.   If we
> conclude that it is now needed, then we should probably run with
> Kurt's suggestions, rather than using Notifies.

If the SG cannot force the ASP to become Inactive then which of the
following behaviors is appropriate when an operator wants to remove an AS
that is already active from the configuration data on the SG: 1) Do not
allow. The AS must be Inactive before it can be removed. This implies that
the ASP must first Inactivate the ASP. This behavior is restrictive in my
opinion.
2) Allow. Notify (AS-Inactive) is sent to ASP. ASP is not compelled to
become Inactive, so it still considers itself Active. The SG will no longer
forward traffic to the AS because it is not defined. I don't think that this
is the correct behavior.

BTW, the solutions I proposed actually use a combination of ASP Down and
Notifys. As I indicated below I would suggest that ASP Down not be used for
management blocking and ERR be used instead. For the other problems I
proposed that Notify be used to inform the ASP that the state of the AS has
changed. The Notify does not force the ASP to change the AS state because
the state is already changed on the SG.

>
>
> Feedback, flames welcome!
>
> Cheers,
>
>     Greg
>
> PS: I'm not ruling out any other protocol solutions - but lets agree
> on the requirement first.
>
>  -----Original Message-----
> From:   Kurt Kite [mailto:[email-masked]]
> Sent:   Saturday, April 21, 2001 12:31 PM
> To:     sigtran
> Subject:        Re: M3UA: Management Blocking at the SG
>
> Hi,
>
> Some of this has been discussed before, but I would not say that any
> consensus
> was reached. See below for some comments.
>
> Regards,
> Kurt
>
> Schwarzbauer Hanns Juergen wrote:
>
> > Folks,
> >
> > hopefully I didn't miss some old E-Mails in case the issue shown
> below has already been discussed.
> >
> > Chapter 4.3.3.1 "ASP-UP" contains a very short paragraph talking
> about the case where on
> > the SG a management action was taken, forcing the SG to respond to
> subsequent ASP-UP
> > messages with ASP-Down Ack as shown below:
> >             SG                            ASP
> >              |                             |
> >    management|                             |
> >    blocking  |                             |
> >    of ASP---->                             |
> >              |         ASP-UP              |
> >              |<----------------------------|
> >              |         ASP-Down Ack        |
> >              |---------------------------->|
> >              |                             |
> >
> > Question:
> > What should happen, if there are already aktive ASP's when this
> management action is taken?
> >
> > My proposal to handle this is shown below:
> >
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >    management|---------------------------->|
> >    blocking  |                             |
> >    of ASP---->                             |
> >              |     NOTIFY (ASP-blocked)    |
> >              |---------------------------->|
> >              |         ASP-Down            |
> >              |<----------------------------|
> >              |         ASP-Down Ack        |
> >              |---------------------------->|
> >              |                             |
> >
> > The proposed contents of NOTIFY message would be:
> > Status Type:            value: 2, "other" (already there)
> > Status Information:     value: 3, "ASP blocked (to be added)
>
> I believe that the draft intended to use the ASP-Down message to
> accomplish
> the above.
>
>             SG                            ASP
>              |                             |
>              |         ASP-Up              |
>              |<----------------------------|
>              |         ASP-Up Ack          |
>    management|---------------------------->|
>    blocking  |                             |
>    of ASP---->                             |
>              |                             |
>              |         ASP-Down            |
>              |---------------------------->|
>              |         ASP-Down Ack        |
>              |<----------------------------|
>              |                             |
>
> The ASP-Down content is:
> Reason: Management Blocking
>
> Reception of an ASP-Down with the above reason would force the ASP
> to move the ASP to a Down state and send an ASP-Down Ack.
> You will notice that the draft is careful to say that the ASP-Down "is
> used
> to indicate to a remote M3UA peer . . . ." It does not restrict the
> ASP-Down
> from being sent only from the ASP to the SG. However, this procedure
> is not
> explicitly described in the draft.
>
> >
> >
> > This Notify message would force the receiving ASP to initiate the
> > ASP-Down procedure. The SG might want to start a supervision timer
> > and upon its expiry could initiate the SCTP shutdown procedure.
> >
> > Now having a clean procedure to force an ASP to enter the ASP-Down
> state
> > initiated by the SG, we could alsowell ask why not to have the same
> > mechanism to handle blocking of Routing Context at the SG (some
> operators
> > might want to do this, intentionally or not).
> >
> > The proposed procedure is shown below:
> >
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >              |---------------------------->|
> >              |         ASP-Active(RC1)     |
> >              |<----------------------------|
> >              |         ASP-Active Ack(RC1) |
> >              |---------------------------->|
> >    management|                             |
> >    blocking  |                             |
> >    of RC1---->                             |
> >              |     NOTIFY (RC-blocked,RC1) |
> >              |---------------------------->|
> >              |         ASP-Inactive(RC1)   |
> >              |<----------------------------|
> >              |      ASP-Inactive ACK(RC1)  |
> >              |---------------------------->|
> >              |                             |
> >
> > The proposed contents of NOTIFY message would be:
> > Status Type:            value: 2, "other" (already there)
> > Status Information:     value: 4, "RC blocked (to be added)
>
> I raised the same question earlier. You can read the mails with
> subject "Static Configuration" for all of the details. My issue
> was that the operator wanted to remove an AS from the SG
> configuration data. The proposed solution was similar to the
> one you describe above.
>
>             SG                            ASP
>              |                             |
>              |         ASP-Up              |
>              |<----------------------------|
>              |         ASP-Up Ack          |
>              |---------------------------->|
>              |         ASP-Active(RC1)     |
>              |<----------------------------|
>              |         ASP-Active Ack(RC1) |
>              |---------------------------->|
>    management|                             |
>    removal   |                             |
>    of RC1---->                             |
>              |     NOTIFY (AS-Inactive,RC1)|
>              |---------------------------->|
>              |                             |
>
> The proposed contents of NOTIFY message would be:
> Status Type:            value: 1, "AS state change" (already there)
> Status Information:     value: 2, "AS-Inactive" (already there)
>
> The NOTIFY message would force the receiving ASP to mark the
> RC as Inactive. There is already a precedent for this with the NOTIFY
> message with the "Alternate ASP Active" status information. This
> solution eliminates a couple of messages and the need for a timer.
>
> >
> >
> > This Notify message would force the receiving ASP to initiate the
> > ASP-Inactive procedure for that RC. The SG might want to start a
> > supervision timer and upon its expiry could initiate the SCTP
> > shutdown procedure, thus however, bringing the whole ASP down.
> >
> > Two more scenarios should be considered:
> >
> > a) no ASP in Active state at all
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >              |---------------------------->|
> >    management|                             |
> >    blocking  |                             |
> >    of RC1---->                             |
> >              |     NOTIFY (RC-blocked,RC1) |
> >              |---------------------------->| do nothing, if no
> >              |                             | ASP-Active was sent
>
> The above scenario goes away if the NOTIFY forces the ASP
> to move the RC into the Inactive state as I described above.
>
> >
> >
> > b)race condition ASP-Active and NOTIFY
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >              |---------------------------->|
> >              |                             |
> >    management|              ASP-Active(RC1)|
> >    blocking  |           +-----------------|
> >    of RC1---->           |                 |
> >              |     NOTIFY|(RC-blocked,RC1) |
> >              |-----------|---------------->|
> >              |           |                 |
> >              |<----------+                 |
> >              |                             |
> >  respond with|      ASP-Inactive ACK(RC1)  |
> >  ASPIA       |---------------------------->|
> >              |                             |
> >
> > Resolving this race condition would require allowing to acknowledge
> an
> > ASP-Active message with an ASP-Inactive message. However, this is
> already
> > allowed for the ASP-Up as shown in the first figure.
>
> Yes, it is already allowed for the ASP-Up, but I think that makes the
> protocol
> more complicated and confusing than it needs to be. Why not just use
> the ERR
> message for these kinds of response. Why have an Ack message that can
> indicate
> both success and failure and the ERR message that can also indicate
> failure?
>
> I propose that ERR (new error "Management Blocked") be used in this
> case.
> I wouldn't mind using ERR for the ASP Up case as well. 8^).
>
> Regards,
> Kurt
>
> >
> >
> > looking forward hearing from you guys
> >
> > HannsJuergen
> >
> > SIEMENS AG
> > Information and Communication Networks
> > Wireline Network Communication
> > Carrier Switching Networks
> > ICN WN CS SE 51
> >
> > Tel:    +49 89 722 24236
> > Fax:    +49 89 722 48212
> > 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]
> ---
> 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: "Patel, Chirayu" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA draft 7 questions
Date: Wed, 2 May 2001 13:23:16 -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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

While going through draft 7 of M2UA, I came across the following issues
which I think need more clarification :

1. SCTP congestion in the SG. The draft suggests that M2UA should inform
MTP2 about LPO. Is this enough? Since MTP3 (on the ASP) is unaware of LPO it
is going to send data, which will result in removal of LPO state at the
remote end.

2. Congestion and Discard status. As per Q.704 3.8.2.1, the setting of the
congestion is implementation dependent. In light of this, shouldn't the
Congestion status be optional?

regards,
CP

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Wed, 25 Apr 2001 19:45:11 -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: Ken Morneault <[email-masked]>, "Patel, Chirayu"
<[email-masked]>
Subject: Re: M2UA draft 7 questions
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

"Patel, Chirayu" wrote:
> 
> Hi,
> 
> While going through draft 7 of M2UA, I came across the following issues
> which I think need more clarification :
> 
> 1. SCTP congestion in the SG. The draft suggests that M2UA should inform
> MTP2 about LPO. Is this enough? Since MTP3 (on the ASP) is unaware of LPO
it
> is going to send data, which will result in removal of LPO state at the
> remote end.

Sending of LPO is disputed by me and a number of others on this list.
I suggest to delete the 2 paragraphs in 1.5.5 that say LPO should be sent.

There is no precedent for sending LPO on congestion. In fact, the precedent
is to take the link down. MTP2 takes the link down if acknowledements are
withheld for longer than T7 or longer than T6 in the presence of SIB.

> 
> 2. Congestion and Discard status. As per Q.704 3.8.2.1, the setting of the
> congestion is implementation dependent. In light of this, shouldn't the
> Congestion status be optional?

3.8.2.1 requires that an indication of the level of congestion be given.
So the message sent by M2UA must convey a level. What is implementation
dependent is when to send the message and what criterion to use to determine
the level. This remains implementation dependent in M2UA.

One thing I would like to have changed is that implementations that do not
support multiple levels of congestion use LEVEL_NONE and LEVEL_3 rather than
LEVEL_NONE and LEVEL_1. If this is done, M2UA will be able to connect an
MTP2 implementation that does not support multiple levels with an MTP3
implementation that does.

> regards,
> CP

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Long, Hanping" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Backhauled message from inactive ASP
Date: Wed, 2 May 2001 17:44:17 -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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All:

Whenever a backhauled message comes from an inactive ASP, what should SG
handle this situation?

From the specs of UAs, such as IUA or M2UA, there is no corresponding error
type if I want to send a Error message to ASP.

Thanks for your attention!

hanping

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Barry Nagelberg <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: m3ua bakeoff test scenario 4
Date: Thu, 3 May 2001 09:24:20 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear Interop Team,

There are several problems with scenario 4 of the M3UA bakeoff test, some of
which point out weaknesses in the draft itself: See
http://standards.ericsson.net/m3ua-interop/DetPlan.html

1. The test setup says that "Each AS is handling traffic for its Routing
Context". A routing context is an index into the routing table at the SG.
When the ASP sends a routing context to the SG, it is telling the SG what
range of SS7 traffic it wants to receive coming FROM the SS7 network. In
other words, the routing context is a pseudo-SS7 address of the AS/ASP.

2. When the MTP3 layer at the SG sends a PAUSE/RESUME/STATUS primitive to
the M3UA layer at the SG, it includes one or more DPC's of the affected
destinations. These affected DPC's refer to signaling endpoints in the SS7
network, i.e. on the OPPOSITE side of the SG from the ASPs. These are DPCs
that the ASP wants to use to send messages INTO the SS7 network. There is no
connection between these affected DPC's and the routing contexts that were
sent by the ASP's in the ASPAC message. So when the test says that a
DUNA_req (i.e. PAUSE primitive) has "Routing Key 1", and therefore the DUNA
message must be routed to ASP1, this makes no sense. M3ua v5 and v6 state,
in Section 4.1.1 that:

"The SG M3UA determines the set of concerned ASPs to be informed based on
the SS7 network partition for which the primitive indication is relevant. In
this way, all ASPs configured to send/receive traffic within a particular
network appearance are informed.  If the SG operates within a single SS7
network appearance, then all ASPs are informed.  

Optionally, the SG M3UA may filter further based on the Affected Point Code
in the MTP-PAUSE, MTP-Resume, or MTP-Status indication primitives.  
In this way ASPs can be informed only of affected destinations to which they
actually communicate."

Because there is only a single network appearance in scenario 4, the only
requirement that must be tested is that both ASP1 and ASP2 receive a DUNA
message, with the same DPC's that were in the PAUSE primitive. This test
should be repeated for RESUME/DAVA and STATUS/SCON.

3. The draft weakness is in the "Optional" behaviour mentioned in the second
paragraph above. This assumes that the SG knows the DPC's to which each ASP
is sending messages. I suppose that this could be configured via a network
manager, but we are now assuming that configuration can also be done via the
Routing Key Management (RKM) Messages. I do not see any method in the RKM
messages via which the ASP can tell the SG to which SS7 DPCs the ASP wishes
to send messages. It cannot be the OPC field, because this is used to route
messages to the ASP (altough the draft is not clear on this).

Barry Nagelberg
Staff Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

---
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: Management Blocking at the SG
Date: Thu, 3 May 2001 12:26:18 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: M3UA: Management Blocking at the SG</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Responses below ...</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Kurt Kite [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 02, 2001 3:43
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re:
M3UA: Management Blocking at the SG</FONT> </P>

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

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

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Kurt</FONT>
</P>

<P><FONT SIZE=2>&quot;Sidebottom, Greg [BCNR:7M01:EXCH]&quot; wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Greetings,</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I'm not sure that what Hanns-Juergen and Kurt propose
as solutions</FONT> <BR><FONT SIZE=2>&gt; here is consistent with the
original problem.&nbsp; The original management</FONT> <BR><FONT SIZE=2>&gt;
blocking that I had in mind was simply to allow the SG to refuse an</FONT>
<BR><FONT SIZE=2>&gt; individual ASP-Up request, as a temporary ASP
lock-out, not as a</FONT> <BR><FONT SIZE=2>&gt; general mechanism to also
force any other ASPs that are currently</FONT> <BR><FONT SIZE=2>&gt;
&quot;inactive or active&quot; to go &quot;down&quot;.</FONT> </P>

<P><FONT SIZE=2>Yes, they are solutions to a new set of problems. In the
case of static</FONT> <BR><FONT SIZE=2>configuration, it is probably
reasonable to allow the configuration to</FONT> <BR><FONT SIZE=2>be changed
independently. So, it is possible that an AS definition to be</FONT>
<BR><FONT SIZE=2>removed from the SG after it has become Active.</FONT> </P>

<P><FONT SIZE=2>[Greg] Maybe I'm still missing the point but I'm not sure
why an Operator would want to remove an AS from a configuration while it is
still &quot;active&quot;.&nbsp; I see Operators of signalling networks
typically taking great pains in ensuring that traffic is removed from a link
or route before removing it from a configuration.&nbsp; I guess if the AS is
&quot;active&quot; but there is no traffic flowing (?) then a case can be
made.&nbsp; But it seems to me that there is configuration work required at
the ASP(s) to stop processing the traffic (there is after all underlying
circuits or packet flows to an MG that are being supported by the
signalling).&nbsp; Having the ASP send an ASP-Inactive to the SG after all
the bearer stuff is done seems to be a pretty small overhead.</FONT></P>

<P><FONT SIZE=2>OTOH I can see a case where here is a misbehaving ASP and
the SG wants to &quot;force&quot; it out of an AS.&nbsp; But this can be
done pretty easily - The SG can simply drop the association and then lock it
out (refusing new association or refusing the ASP-Up).</FONT></P>

<P><FONT SIZE=2>From a configuration view it is reasonable that for the
&quot;static&quot; case the AS/ASP configuration data is changed
independently at the SG and ASP.&nbsp; I'm just not sure that we need
protocol to allow the initiation of the configuration change from either
side.&nbsp; If people disagree, then we probably need some warnings (to
avoid traffic loss) in the text.&nbsp;&nbsp; I not sure about how to handle
the &quot;dynamic&quot; case though as the ASP seems to control the
configuration.&nbsp; </FONT></P> <BR>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The M3UA currently doesn't have a mechanism for the SG
to &quot;force&quot; a</FONT> <BR><FONT SIZE=2>&gt; change in the ASP or AS
state.&nbsp; Kurt's interpretation that this was</FONT> <BR><FONT
SIZE=2>&gt; subtly intended by the ASP-DOWN text was interesting - but this
was</FONT> <BR><FONT SIZE=2>&gt; not the real reason behind the text.&nbsp;
The text was like that to cover</FONT> <BR><FONT SIZE=2>&gt; the
point-to-point case where two ASPs are peers, with no SG.</FONT> </P>

<P><FONT SIZE=2>I was just looking for any solution that would not extend
the protocol.</FONT> <BR><FONT SIZE=2>8^)</FONT>
</P>

<P><FONT SIZE=2>[Greg] As an editor I thank you from the bottom of my
heart&nbsp; 2;^)</FONT> </P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The spec so far follows the assumption that the ASPs
(using inter-ASP</FONT> <BR><FONT SIZE=2>&gt; communication where necessary)
are the masters in charge of the</FONT> <BR><FONT SIZE=2>&gt; initiation of
ASP and AS state changes.&nbsp;&nbsp; The Notify message is more</FONT>
<BR><FONT SIZE=2>&gt; of an indication to an ASP of a change in the AS state
or an</FONT> <BR><FONT SIZE=2>&gt; indication of a change of ASP roles
within the AS.&nbsp; An ASP can compare</FONT> <BR><FONT SIZE=2>&gt; this
notification to their view of the ASP/AS state and could take</FONT>
<BR><FONT SIZE=2>&gt; action, but I thought it was clear that the ASPs are
not obligated.</FONT> <BR><FONT SIZE=2>&gt; Certainly for at least the
&quot;AS-Pending&quot; or &quot;Insufficient ASP Resources</FONT> <BR><FONT
SIZE=2>&gt; active in AS&quot; Notifies, it is clear in Section 4.3.3.6 that
&quot;the</FONT> <BR><FONT SIZE=2>&gt; Notify does not explicitly compel the
ASP(s) receiving the message to</FONT> <BR><FONT SIZE=2>&gt; become active.
The ASPs remain in control of what (and when) traffic</FONT> <BR><FONT
SIZE=2>&gt; action is taken.&quot;&nbsp;&nbsp; In this context, I have no
problem adding the new</FONT> <BR><FONT SIZE=2>&gt; Notifies that
Hanns-Juergen and/or Kurt suggests, with the continuing</FONT> <BR><FONT
SIZE=2>&gt; proviso that they are &quot;non-compelling&quot;</FONT> </P>

<P><FONT SIZE=2>I agree in general that the ASP normally dictates ASP and AS
state</FONT> <BR><FONT SIZE=2>changes. However, I would argue that the
Notify (Alternate ASP Active)</FONT> <BR><FONT SIZE=2>forces the ASP into
the Inactive state, albeit at due to another</FONT> <BR><FONT SIZE=2>ASP
sending an ASP Active for an AS in Over-ride mode.</FONT> </P>

<P><FONT SIZE=2>[Greg] In my view, it is really the ASP-Active (Over-ride)
from the alternate ASP that &quot;forces&quot; the ASP to
&quot;inactive&quot;.&nbsp; I'm not saying that for some applications
someone couldn't implement the Notify as a trigger to changes to the ASP's
state (i.e., the ASPs don't talk to each other directly and use the Notifies
to keep synch).&nbsp;&nbsp; In that case they are really bouncing state
information off the SG.&nbsp; </FONT></P>

<P><FONT SIZE=2>In any case, I think that certain actions on the SG, like an
operator</FONT> <BR><FONT SIZE=2>removing configuration data, should force
the ASP to change state. I do</FONT> <BR><FONT SIZE=2>not think that the SG
should ever be able to force the ASP to become</FONT> <BR><FONT
SIZE=2>Active for an AS, but it should be able to force the ASP to
become</FONT> <BR><FONT SIZE=2>Inactive. The ASP is then free to remain
Inactive or to become Active</FONT> <BR><FONT SIZE=2>again.</FONT>
</P>

<P><FONT SIZE=2>[Greg] Assuming that there is no traffic, I can agree.&nbsp;
Having the SG force an ASP to &quot;inactive&quot; and then having the ASP
bounce back as &quot;active&quot;, all while traffic is flowing is a no-no
to me.&nbsp; </FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; So, do we want to continue with the assumption that
the ASPs are the</FONT> <BR><FONT SIZE=2>&gt; masters for the initiation of
AS/ASP state changes or do we want to</FONT> <BR><FONT SIZE=2>&gt; add to
the SG the ability to force ASPs&nbsp; to &quot;down or
inactive&quot;.&nbsp; This</FONT> <BR><FONT SIZE=2>&gt; has been requested a
couple of times in the past but I thought the</FONT> <BR><FONT SIZE=2>&gt;
rough consensus then and now was that this was not needed.&nbsp;&nbsp; If
we</FONT> <BR><FONT SIZE=2>&gt; conclude that it is now needed, then we
should probably run with</FONT> <BR><FONT SIZE=2>&gt; Kurt's suggestions,
rather than using Notifies.</FONT> </P>

<P><FONT SIZE=2>If the SG cannot force the ASP to become Inactive then which
of the</FONT> <BR><FONT SIZE=2>following behaviors is appropriate when an
operator wants to remove an</FONT> <BR><FONT SIZE=2>AS that is already
active from the configuration data on the SG:</FONT> <BR><FONT SIZE=2>1) Do
not allow. The AS must be Inactive before it can be removed. This</FONT>
<BR><FONT SIZE=2>implies that the ASP must first Inactivate the ASP. This
behavior is</FONT> <BR><FONT SIZE=2>restrictive in my opinion.</FONT>
<BR><FONT SIZE=2>2) Allow. Notify (AS-Inactive) is sent to ASP. ASP is not
compelled to</FONT> <BR><FONT SIZE=2>become Inactive, so it still considers
itself Active. The SG will no</FONT> <BR><FONT SIZE=2>longer forward traffic
to the AS because it is not defined. I don't</FONT> <BR><FONT SIZE=2>think
that this is the correct behavior.</FONT> </P>

<P><FONT SIZE=2>[Greg] Well you have only two options, one in your view
restrictive and the other incorrect&nbsp; 2;^)</FONT> </P>

<P><FONT SIZE=2>How about 1.5) Only allow if underlying signalling traffic
is stopped (operator-determined)?&nbsp; Or 3) Add an ASP-Inactive (Force) or
DEREG (Force) message from SG instead?&nbsp; Option 3) has the cleanest
semantics but does require extension of the protocol - some new procedures
and potentially a new message (or modified ASP-Inactive/DEREG).&nbsp; But
this IMHO seems like a lot of work for a small problem.</FONT></P>

<P><FONT SIZE=2>BTW, the solutions I proposed actually use a combination of
ASP Down and</FONT> <BR><FONT SIZE=2>Notifys. As I indicated below I would
suggest that ASP Down not be used</FONT> <BR><FONT SIZE=2>for management
blocking and ERR be used instead. For the other problems</FONT> <BR><FONT
SIZE=2>I proposed that Notify be used to inform the ASP that the state of
the</FONT> <BR><FONT SIZE=2>AS has changed. The Notify does not force the
ASP to change the AS state</FONT> <BR><FONT SIZE=2>because the state is
already changed on the SG.</FONT> </P>
<BR>

<P><FONT SIZE=2>[Greg] I can agree to using an ERR instead of an ASP-Down
for the &quot;management blocking&quot;.&nbsp; It would be quite a small
change, and it is a little cleaner to me as this current ASP-Down shouldn't
have an ASP-Down Ack in return.&nbsp; I'll make the change unless people
object.</FONT></P>

<P><FONT SIZE=2>As for the Notify not forcing the ASP to change state - the
SG has changed the AS state and will be throwing out any traffic to the
AS.&nbsp; No applications are really going to work with signalling traffic
flowing only in one direction, so the SG action does really force the ASP to
change.&nbsp; If it doesn't there will be lots of application level bells
and alarms going off.</FONT></P>

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

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

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Feedback, flames welcome!</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Greg</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; PS: I'm not ruling out any other protocol solutions -
but lets agree</FONT> <BR><FONT SIZE=2>&gt; on the requirement first.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From:&nbsp;&nbsp; Kurt Kite [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>&gt; Sent:&nbsp;&nbsp; Saturday, April 21, 2001 12:31
PM</FONT> <BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re:
M3UA: Management Blocking at the SG</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Some of this has been discussed before, but I would
not say that any</FONT> <BR><FONT SIZE=2>&gt; consensus</FONT>
<BR><FONT SIZE=2>&gt; was reached. See below for some comments.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Kurt</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Schwarzbauer Hanns Juergen wrote:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Folks,</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; hopefully I didn't miss some old E-Mails in case
the issue shown</FONT> <BR><FONT SIZE=2>&gt; below has already been
discussed.</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Chapter 4.3.3.1 &quot;ASP-UP&quot; contains a
very short paragraph talking</FONT> <BR><FONT SIZE=2>&gt; about the case
where on</FONT> <BR><FONT SIZE=2>&gt; &gt; the SG a management action was
taken, forcing the SG to respond to</FONT> <BR><FONT SIZE=2>&gt; subsequent
ASP-UP</FONT> <BR><FONT SIZE=2>&gt; &gt; messages with ASP-Down Ack as shown
below:</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-UP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Question:</FONT> <BR><FONT SIZE=2>&gt; &gt; What
should happen, if there are already aktive ASP's when this</FONT> <BR><FONT
SIZE=2>&gt; management action is taken?</FONT> <BR><FONT SIZE=2>&gt;
&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; My proposal to handle this is shown below:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
management|----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (ASP-blocked)&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Down&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The proposed contents of NOTIFY message would
be:</FONT> <BR><FONT SIZE=2>&gt; &gt; Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 2, &quot;other&quot; (already there)</FONT> <BR><FONT SIZE=2>&gt;
&gt; Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 3, &quot;ASP blocked
(to be added)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I believe that the draft intended to use the ASP-Down
message to</FONT> <BR><FONT SIZE=2>&gt; accomplish</FONT> <BR><FONT
SIZE=2>&gt; the above.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
ASP----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Down&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Down
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The ASP-Down content is:</FONT> <BR><FONT SIZE=2>&gt;
Reason: Management Blocking</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Reception of an ASP-Down with the above reason would
force the ASP</FONT> <BR><FONT SIZE=2>&gt; to move the ASP to a Down state
and send an ASP-Down Ack.</FONT> <BR><FONT SIZE=2>&gt; You will notice that
the draft is careful to say that the ASP-Down &quot;is</FONT> <BR><FONT
SIZE=2>&gt; used</FONT>
<BR><FONT SIZE=2>&gt; to indicate to a remote M3UA peer . . . .&quot; It
does not restrict the</FONT> <BR><FONT SIZE=2>&gt; ASP-Down</FONT>
<BR><FONT SIZE=2>&gt; from being sent only from the ASP to the SG. However,
this procedure</FONT> <BR><FONT SIZE=2>&gt; is not</FONT>
<BR><FONT SIZE=2>&gt; explicitly described in the draft.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; This Notify message would force the receiving ASP
to initiate the</FONT> <BR><FONT SIZE=2>&gt; &gt; ASP-Down procedure. The SG
might want to start a supervision timer</FONT> <BR><FONT SIZE=2>&gt; &gt;
and upon its expiry could initiate the SCTP shutdown procedure.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Now having a clean procedure to force an ASP to
enter the ASP-Down</FONT> <BR><FONT SIZE=2>&gt; state</FONT>
<BR><FONT SIZE=2>&gt; &gt; initiated by the SG, we could alsowell ask why
not to have the same</FONT> <BR><FONT SIZE=2>&gt; &gt; mechanism to handle
blocking of Routing Context at the SG (some</FONT> <BR><FONT SIZE=2>&gt;
operators</FONT>
<BR><FONT SIZE=2>&gt; &gt; might want to do this, intentionally or
not).</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The proposed procedure is shown below:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Active(RC1)&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Active Ack(RC1)
|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (RC-blocked,RC1) |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Inactive(RC1)&nbsp;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Inactive ACK(RC1)&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The proposed contents of NOTIFY message would
be:</FONT> <BR><FONT SIZE=2>&gt; &gt; Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 2, &quot;other&quot; (already there)</FONT> <BR><FONT SIZE=2>&gt;
&gt; Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 4, &quot;RC blocked
(to be added)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I raised the same question earlier. You can read the
mails with</FONT> <BR><FONT SIZE=2>&gt; subject &quot;Static
Configuration&quot; for all of the details. My issue</FONT> <BR><FONT
SIZE=2>&gt; was that the operator wanted to remove an AS from the SG</FONT>
<BR><FONT SIZE=2>&gt; configuration data. The proposed solution was similar
to the</FONT> <BR><FONT SIZE=2>&gt; one you describe above.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Active(RC1)&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&lt;----------------------------|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Active
Ack(RC1) |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
removal&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; |</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (AS-Inactive,RC1)|</FONT>
<BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; |----------------------------&gt;|</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The proposed contents of NOTIFY message would
be:</FONT> <BR><FONT SIZE=2>&gt; Status
Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value: 1, &quot;AS state change&quot; (already there)</FONT> <BR><FONT
SIZE=2>&gt; Status Information:&nbsp;&nbsp;&nbsp;&nbsp; value: 2,
&quot;AS-Inactive&quot; (already there)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The NOTIFY message would force the receiving ASP to
mark the</FONT> <BR><FONT SIZE=2>&gt; RC as Inactive. There is already a
precedent for this with the NOTIFY</FONT> <BR><FONT SIZE=2>&gt; message with
the &quot;Alternate ASP Active&quot; status information. This</FONT>
<BR><FONT SIZE=2>&gt; solution eliminates a couple of messages and the need
for a timer.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; This Notify message would force the receiving ASP
to initiate the</FONT> <BR><FONT SIZE=2>&gt; &gt; ASP-Inactive procedure for
that RC. The SG might want to start a</FONT> <BR><FONT SIZE=2>&gt; &gt;
supervision timer and upon its expiry could initiate the SCTP</FONT>
<BR><FONT SIZE=2>&gt; &gt; shutdown procedure, thus however, bringing the
whole ASP down.</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Two more scenarios should be considered:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; a) no ASP in Active state at all</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;
management|&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; blocking&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY (RC-blocked,RC1) |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;| do nothing, if no</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&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; | ASP-Active was sent</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The above scenario goes away if the NOTIFY forces the
ASP</FONT> <BR><FONT SIZE=2>&gt; to move the RC into the Inactive state as I
described above.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; b)race condition ASP-Active and NOTIFY</FONT>
<BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; ASP</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ASP-Up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&lt;----------------------------|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Up
Ack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;
management|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; ASP-Active(RC1)|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp; blocking&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------|</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; of
RC1----&gt;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; NOTIFY|(RC-blocked,RC1) |</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; |-----------|----------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;
|&lt;----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp; respond
with|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASP-Inactive ACK(RC1)&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; ASPIA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|----------------------------&gt;|</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&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; |</FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Resolving this race condition would require
allowing to acknowledge</FONT> <BR><FONT SIZE=2>&gt; an</FONT>
<BR><FONT SIZE=2>&gt; &gt; ASP-Active message with an ASP-Inactive message.
However, this is</FONT> <BR><FONT SIZE=2>&gt; already</FONT>
<BR><FONT SIZE=2>&gt; &gt; allowed for the ASP-Up as shown in the first
figure.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Yes, it is already allowed for the ASP-Up, but I think
that makes the</FONT> <BR><FONT SIZE=2>&gt; protocol</FONT>
<BR><FONT SIZE=2>&gt; more complicated and confusing than it needs to be.
Why not just use</FONT> <BR><FONT SIZE=2>&gt; the ERR</FONT>
<BR><FONT SIZE=2>&gt; message for these kinds of response. Why have an Ack
message that can</FONT> <BR><FONT SIZE=2>&gt; indicate</FONT>
<BR><FONT SIZE=2>&gt; both success and failure and the ERR message that can
also indicate</FONT> <BR><FONT SIZE=2>&gt; failure?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I propose that ERR (new error &quot;Management
Blocked&quot;) be used in this</FONT> <BR><FONT SIZE=2>&gt; case.</FONT>
<BR><FONT SIZE=2>&gt; I wouldn't mind using ERR for the ASP Up case as well.
8^).</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Kurt</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; looking forward hearing from you guys</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; HannsJuergen</FONT> <BR><FONT SIZE=2>&gt;
&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; SIEMENS AG</FONT> <BR><FONT SIZE=2>&gt; &gt;
Information and Communication Networks</FONT> <BR><FONT SIZE=2>&gt; &gt;
Wireline Network Communication</FONT> <BR><FONT SIZE=2>&gt; &gt; Carrier
Switching Networks</FONT> <BR><FONT SIZE=2>&gt; &gt; ICN WN CS SE 51</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel:&nbsp;&nbsp;&nbsp; +49 89 722 24236</FONT>
<BR><FONT SIZE=2>&gt; &gt; Fax:&nbsp;&nbsp;&nbsp; +49 89 722 48212</FONT>
<BR><FONT SIZE=2>&gt; &gt; E-mail
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; ---</FONT>
<BR><FONT SIZE=2>&gt; &gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt; To unsubscribe
send a blank email to</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:</FONT>
<BR><FONT SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; To unsubscribe send a blank email to</FONT> <BR><FONT
SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send a
blank email to</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> </P>
<BR>
<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>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Ken Morneault <[email-masked]>, "Patel, Chirayu"
<[email-masked]>
Subject: RE: M2UA draft 7 questions
Date: Thu, 3 May 2001 12:50:51 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: M2UA draft 7 questions</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Question below ..</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Jacob Heitz [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, April 25, 2001 10:45 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Ken Morneault; Patel, Chirayu</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M2UA
draft 7 questions</FONT> </P>

<P><FONT SIZE=2>&quot;Patel, Chirayu&quot; wrote:</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; While going through draft 7 of M2UA, I came across the
following issues</FONT> <BR><FONT SIZE=2>&gt; which I think need more
clarification :</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1. SCTP congestion in the SG. The draft suggests that
M2UA should inform</FONT> <BR><FONT SIZE=2>&gt; MTP2 about LPO. Is this
enough? Since MTP3 (on the ASP) is unaware of LPO it</FONT> <BR><FONT
SIZE=2>&gt; is going to send data, which will result in removal of LPO state
at the</FONT> <BR><FONT SIZE=2>&gt; remote end.</FONT> </P>

<P><FONT SIZE=2>Sending of LPO is disputed by me and a number of others on
this list.</FONT> <BR><FONT SIZE=2>I suggest to delete the 2 paragraphs in
1.5.5 that say LPO should be sent.</FONT> </P>

<P><FONT SIZE=2>There is no precedent for sending LPO on congestion. In
fact, the</FONT> <BR><FONT SIZE=2>precedent is to take the link down. MTP2
takes the link down if acknowledements</FONT> <BR><FONT SIZE=2>are withheld
for longer than T7 or longer than T6 in the presence of SIB.</FONT> </P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2. Congestion and Discard status. As per Q.704
3.8.2.1, the setting of the</FONT> <BR><FONT SIZE=2>&gt; congestion is
implementation dependent. In light of this, shouldn't the</FONT> <BR><FONT
SIZE=2>&gt; Congestion status be optional?</FONT> </P>

<P><FONT SIZE=2>3.8.2.1 requires that an indication of the level of
congestion be given.</FONT> <BR><FONT SIZE=2>So the message sent by M2UA
must convey a level. What is implementation</FONT> <BR><FONT
SIZE=2>dependent is when to send the message and what criterion to use
to</FONT> <BR><FONT SIZE=2>determine the level. This remains implementation
dependent in M2UA.</FONT> </P>

<P><FONT SIZE=2>One thing I would like to have changed is that
implementations that do</FONT> <BR><FONT SIZE=2>not support multiple levels
of congestion use LEVEL_NONE and LEVEL_3</FONT> <BR><FONT SIZE=2>rather than
LEVEL_NONE and LEVEL_1. If this is done, M2UA will be able</FONT> <BR><FONT
SIZE=2>to connect an MTP2 implementation that does not support multiple
levels </FONT> <BR><FONT SIZE=2>with an MTP3 implementation that
does.</FONT> </P>

<P><FONT SIZE=2>[Greg] Interesting - can you describe this in more
detail?&nbsp; Are you saying that with this change an MTP3 layer could sit
on two M2UAs with different congestion methods and seamlessly make this work
in a single MTP3 layer?&nbsp; I'm skeptical but maybe I just need more
details.&nbsp; It seems to me that these indications have an impact on the
route congestion states in MTP3, how the MTP3 processes congestion
information and what is passed to the MTP3 User.&nbsp;&nbsp;&nbsp;
</FONT></P>

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

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Greg</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: Thu, 3 May 2001 10:59:03 -0700 (PDT)
From: Mailing List <[email-masked]>
Subject: How is the voice truck setup in SS7 network?
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web14304.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: web14304.mail.yahoo.com [216.136.173.80]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi:

I understand that the voice truck setup should be independent to the SS7
network.  However, I am just wondering whether the route that SS7 signals go
through (the STPs) has anything at all to do with the voice truck route (ATM
switches probably)?  

Or they could be totally different routes around the world (like SS7 across
one side of the world while voice across the other side of the world)?

If so, do I need a routing table for the voice trunk, in addition to the
routing table for the SS7 network?

Thanks very much in advance,

Patrick.

__________________________________________________ Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---
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: How is the voice truck setup in SS7 network?
Date: Thu, 3 May 2001 14:34:44 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: How is the voice truck setup in SS7 network?</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>The signalling and trunking tables are independent,
provisioned by the Network Operators.&nbsp; An Operator could design their
SS7 network so that the same routes are used in some cases (e.g., fully
associated routes) but they don't have to. </FONT></P>

<P><FONT SIZE=2>Keep on &quot;trunking&quot;</FONT> </P>

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

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Mailing List [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 03, 2001 1:59
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How is
the voice truck setup in SS7 network?</FONT> </P>

<P><FONT SIZE=2>Hi:</FONT>
</P>

<P><FONT SIZE=2>I understand that the voice truck setup should be</FONT>
<BR><FONT SIZE=2>independent to the SS7 network.&nbsp; However, I am
just</FONT> <BR><FONT SIZE=2>wondering whether the route that SS7 signals
go</FONT> <BR><FONT SIZE=2>through (the STPs) has anything at all to do with
the</FONT> <BR><FONT SIZE=2>voice truck route (ATM switches probably)?&nbsp;
</FONT> </P>

<P><FONT SIZE=2>Or they could be totally different routes around the</FONT>
<BR><FONT SIZE=2>world (like SS7 across one side of the world while</FONT>
<BR><FONT SIZE=2>voice across the other side of the world)?</FONT> </P>

<P><FONT SIZE=2>If so, do I need a routing table for the voice trunk,</FONT>
<BR><FONT SIZE=2>in addition to the routing table for the SS7
network?</FONT> </P>

<P><FONT SIZE=2>Thanks very much in advance,</FONT> </P>

<P><FONT SIZE=2>Patrick.</FONT>
</P>

<P><FONT SIZE=2>__________________________________________________</FONT>
<BR><FONT SIZE=2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=2>Yahoo! Auctions - buy the things you want at great
prices</FONT> <BR><FONT SIZE=2><A HREF="http://auctions.yahoo.com/"
TARGET="_blank">http://auctions.yahoo.com/</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: Thu, 03 May 2001 14:09:43 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: How is the voice truck setup in SS7 network?
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Patrick,

	Yes, the signallling routing tables and the trunk routing tables are
separate from each other.  The signalling links and the trunks are also
diverse from each other.  This is especially true for quasi-associated
signalling (using STPs).  Let's say that you're making a local call from
point a to point b and that a and b reside on different end-offices a' and
b'.  In the simplest case, there would be a trunk from a' to b'. 
The signalling path from a' would consist of an even number of links divided
evenly between a mated pair of STPs.  These signalling paths would be
physically diverse.  In many common cases, these paths are so physically
diverse that they run out opposite sides of the end office.
Again, making it simple, let's say the STP pair also has direct links to
end-office b'.  b' would also have the a physically diverse arrangement to
the STP.  The signalling from a' to b' would be load shared (with other
signalling traffic) over the link sets to the mated STP pair and delivered
diversly to b'.  The routing management for the signalling would detect link
failures and reroute according to the signalling routing tables.
	Going back to the trunk.  There could be a lower priority trunking
route through a local tandem.  The orignating end-office could detect that
the primary route is down, and route through the tandem to get to b'.  The
tandem would also have diverse signalling links and its own routing tables
for both signalling and trunks.
	I better stop here.  Hope this helps and that I didn't overkill the
answer.

Jeff

Mailing List wrote:
> 
> Hi:
> 
> I understand that the voice truck setup should be
> independent to the SS7 network.  However, I am just
> wondering whether the route that SS7 signals go
> through (the STPs) has anything at all to do with the
> voice truck route (ATM switches probably)?
> 
> Or they could be totally different routes around the
> world (like SS7 across one side of the world while
> voice across the other side of the world)?
> 
> If so, do I need a routing table for the voice trunk,
> in addition to the routing table for the SS7 network?
> 
> Thanks very much in advance,
> 
> Patrick.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\Jeff.Copley4.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 3 May 2001 14:12:52 -0700 (PDT)
From: Mailing List <[email-masked]>
Subject: RE: How is the voice truck setup in SS7 network?
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web14307.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: web14307.mail.yahoo.com [216.136.173.83]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Thanks Greg.

Just to clarify a bit more, would that be appropriate to say that:

the SS7 routing is done in the routing table inside the MTP3 layer, while
the voice trunk routing is done in the routing table inside the ISUP layer?

Thanks again.

Patrick.

--- "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]> wrote:
> Hi Patrick,
> 
> The signalling and trunking tables are independent,
> provisioned by the
> Network Operators.  An Operator could design their
> SS7 network so that the
> same routes are used in some cases (e.g., fully
> associated routes) but they
> don't have to. 
> 
> Keep on "trunking"
> 
>     Greg  
> 
>  -----Original Message-----
> From: 	Mailing List
> [mailto:[email-masked]] 
> Sent:	Thursday, May 03, 2001 1:59 PM
> To:	sigtran
> Subject:	How is the voice truck setup in SS7
> network?
> 
> Hi:
> 
> I understand that the voice truck setup should be
> independent to the SS7 network.  However, I am just
> wondering whether the route that SS7 signals go
> through (the STPs) has anything at all to do with
> the
> voice truck route (ATM switches probably)?  
> 
> Or they could be totally different routes around the
> world (like SS7 across one side of the world while
> voice across the other side of the world)?
> 
> If so, do I need a routing table for the voice
> trunk,
> in addition to the routing table for the SS7
> network?
> 
> Thanks very much in advance,
> 
> Patrick.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great
> prices
> http://auctions.yahoo.com/
> 
> 
> ---
> 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]
> 

__________________________________________________ Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Miriyala Srinivas-FSM016 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: SG/SUA
Date: Thu, 3 May 2001 16:31:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate3.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate3.mot.com [144.189.100.103]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello All,
 
Is there anything in the SUA draft that precludes to use SG to connect two
SUA nodes (ASP-SGP-ASP). What I mean is when SG gets a SUA message with  
- Route On GT : GT + SSN
 
After perform the address mapping (GTT like service) can the result be
another IP node.

Regards
Srini

---
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: Backhauled message from inactive ASP
Date: Thu, 3 May 2001 17:53:44 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: Backhauled message from inactive ASP</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Greetings Hanping ...</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Long, Hanping [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 02, 2001 8:44 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Backhauled message
from inactive ASP</FONT> </P>

<P><FONT SIZE=2>Hi All:</FONT>
</P>

<P><FONT SIZE=2>Whenever a backhauled message comes from an inactive ASP,
what should SG</FONT> <BR><FONT SIZE=2>handle this situation?</FONT> </P>

<P><FONT SIZE=2>From the specs of UAs, such as IUA or M2UA, there is no
corresponding error</FONT> <BR><FONT SIZE=2>type if I want to send a Error
message to ASP.</FONT> </P>

<P><FONT SIZE=2>Thanks for your attention!</FONT> </P>

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

<P><FONT SIZE=2>[Greg] I'm glad you asked this question - I was under the
mistaken impression that the M3UA text covered this off.&nbsp;&nbsp; I think
the unwritten (!) agreement to date was that if an SG receives Data traffic
from an inactive ASP, it should discard it silently.&nbsp; So we should add
a statement in the ASP-Active procedures like&quot; </FONT></P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; &quot;If the SG receives any Data
messages from an ASP in the </FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;inactive&quot; state, the SG
should discard them.&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> </P>

<P><FONT SIZE=2>If we want to add an Error message for this case, we could
use Error (Unexpected Message).&nbsp; But it may not be a good idea to
respond to every Data message.&nbsp; So how about &quot;The SG MAY respond
to the ASP with an Error (Unexpected Message).</FONT></P>

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

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Greg</FONT> </P>
<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>
From: Barry Nagelberg <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Backhauled message from inactive ASP
Date: Thu, 3 May 2001 18:00:29 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

Your first impression was correct. 

Section 4.3.3.4 states of m3ua v6 "If the SG or IPSP receives any Data
messages before an ASPAC is received, the SG or IPSP should discard them."

The underlying assumption here is that if an ASP goes inactive, then it is
considered by the SG to not have sent an ASPAC.

Barry Nagelberg
Staff Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 5:54 PM
To: sigtran
Subject: RE: Backhauled message from inactive ASP

Greetings Hanping ... 
 -----Original Message----- 
From:   Long, Hanping [mailto:[email-masked]] Sent:   Wednesday, May
02, 2001 8:44 PM To:     sigtran 
Subject:        Backhauled message from inactive ASP Hi All: 
Whenever a backhauled message comes from an inactive ASP, what should SG
handle this situation? 
From the specs of UAs, such as IUA or M2UA, there is no corresponding error
type if I want to send a Error message to ASP. 
Thanks for your attention! 
hanping 
[Greg] I'm glad you asked this question - I was under the mistaken
impression that the M3UA text covered this off.   I think the unwritten (!)
agreement to date was that if an SG receives Data traffic from an inactive
ASP, it should discard it silently.  So we should add a statement in the
ASP-Active procedures like" 
     "If the SG receives any Data messages from an ASP in the 
      "inactive" state, the SG should discard them." If we want to add an
Error message for this case, we could use Error (Unexpected Message).  But
it may not be a good idea to respond to every Data message.  So how about
"The SG MAY respond to the ASP with an Error (Unexpected Message).
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]
Sender: [email-masked]
From: Uma Ramanathan <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: MIB for M2PA
Date: Thu, 3 May 2001 16:47:54 -0700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: sphmraaa.compuserve.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [149.174.177.156]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi

Is there a MIB currently defined for M2PA ?

If not, are there any plans to define one in the near future ?

Thanks
R. Uma
Ulticom Inc.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 03 May 2001 21:21:29 -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]>
Subject: Re: M2UA draft 7 questions
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> "Sidebottom, Greg [BCNR:7M01:EXCH]" wrote:
> 
> Hi Jacob,
> 
> Question below ..
> 
>  -----Original Message-----
> From:   Jacob Heitz [mailto:[email-masked]]
> Sent:   Wednesday, April 25, 2001 10:45 PM
> To:     sigtran
> Cc:     Ken Morneault; Patel, Chirayu
> Subject:        Re: M2UA draft 7 questions
> 
> "Patel, Chirayu" wrote:
> >
> > Hi,
> >
> > While going through draft 7 of M2UA, I came across the following issues
> > which I think need more clarification :
> >
> > 1. SCTP congestion in the SG. The draft suggests that M2UA should inform
> > MTP2 about LPO. Is this enough? Since MTP3 (on the ASP) is unaware of
LPO it
> > is going to send data, which will result in removal of LPO state at the
> > remote end.
> 
> Sending of LPO is disputed by me and a number of others on this list.
> I suggest to delete the 2 paragraphs in 1.5.5 that say LPO should be sent.
> 
> There is no precedent for sending LPO on congestion. In fact, the
> precedent is to take the link down. MTP2 takes the link down if
acknowledements
> are withheld for longer than T7 or longer than T6 in the presence of SIB.
> 
> >
> > 2. Congestion and Discard status. As per Q.704 3.8.2.1, the setting of
the
> > congestion is implementation dependent. In light of this, shouldn't the
> > Congestion status be optional?
> 
> 3.8.2.1 requires that an indication of the level of congestion be given.
> So the message sent by M2UA must convey a level. What is implementation
> dependent is when to send the message and what criterion to use to
> determine the level. This remains implementation dependent in M2UA.
> 
> One thing I would like to have changed is that implementations that do
> not support multiple levels of congestion use LEVEL_NONE and LEVEL_3
> rather than LEVEL_NONE and LEVEL_1. If this is done, M2UA will be able
> to connect an MTP2 implementation that does not support multiple levels
> with an MTP3 implementation that does.
> 
> [Greg] Interesting - can you describe this in more detail?  Are you saying
that with this change an MTP3 layer could sit on two M2UAs with different
congestion methods and seamlessly make this work in a single MTP3 layer?
I'm skeptical but maybe I just need more details.  It seems to me that these
indications have an impact on the route congestion states in MTP3, how the
MTP3 processes congestion information and what is passed to the MTP3 User.
> Thanks,
>     Greg

When both the MTP2 and the MTP3 do not support multiple levels, there is no
problem with using LEVEL_3 instead of LEVEL_1.

When MTP2 becomes congested, it wants MTP3 to stop. If MTP2 only supports 2
levels and MTP3 supports multiple, LEVEL_3 will be more effective in slowing
down MTP3 than LEVEL_1 will be. LEVEL_1 may not slow it down enough. I
suggest it set both the congestion status and the discard status to LEVEL_3.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 04 May 2001 00:30:21 -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: M3UA: Management Blocking at the SG
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]>

Hi Greg,

More responses below.

/Kurt

"Sidebottom, Greg [BCNR:7M01:EXCH]" wrote:

>
>
> Hi Kurt,
>
> Responses below ...
>
>  -----Original Message-----
> From:   Kurt Kite [mailto:[email-masked]]
> Sent:   Wednesday, May 02, 2001 3:43 PM
> To:     sigtran
> Subject:        Re: M3UA: Management Blocking at the SG
>
> Hi,
>
> See comments below please.
>
> Regards,
> Kurt
>
> "Sidebottom, Greg [BCNR:7M01:EXCH]" wrote:
>
> >
> >
> > Greetings,
> >
> > I'm not sure that what Hanns-Juergen and Kurt propose as solutions
> > here is consistent with the original problem.  The original
> management
> > blocking that I had in mind was simply to allow the SG to refuse an
> > individual ASP-Up request, as a temporary ASP lock-out, not as a
> > general mechanism to also force any other ASPs that are currently
> > "inactive or active" to go "down".
>
> Yes, they are solutions to a new set of problems. In the case of
> static
> configuration, it is probably reasonable to allow the configuration to
>
> be changed independently. So, it is possible that an AS definition to
> be
> removed from the SG after it has become Active.
>
> [Greg] Maybe I'm still missing the point but I'm not sure why an
> Operator would want to remove an AS from a configuration while it is
> still "active".  I see Operators of signalling networks typically
> taking great pains in ensuring that traffic is removed from a link or
> route before removing it from a configuration.  I guess if the AS is
> "active" but there is no traffic flowing (?) then a case can be made.
> But it seems to me that there is configuration work required at the
> ASP(s) to stop processing the traffic (there is after all underlying
> circuits or packet flows to an MG that are being supported by the
> signalling).  Having the ASP send an ASP-Inactive to the SG after all
> the bearer stuff is done seems to be a pretty small overhead.

I agree that the correct procedure would be to remove the AS from the ASP
first (after making it Inactive). I also agree that it would be much simpler
to simply not allow the AS to be removed while it is Active.
I am just raising the issue of whether it should be allowed or not. I would
be perfectly happy if the protocol indicated that this is not supported.

>
>
> OTOH I can see a case where here is a misbehaving ASP and the SG wants
> to "force" it out of an AS.  But this can be done pretty easily - The
> SG can simply drop the association and then lock it out (refusing new
> association or refusing the ASP-Up).

I agree.

>
>
> From a configuration view it is reasonable that for the "static" case
> the AS/ASP configuration data is changed independently at the SG and
> ASP.  I'm just not sure that we need protocol to allow the initiation
> of the configuration change from either side.  If people disagree,
> then we probably need some warnings (to avoid traffic loss) in the
> text.   I not sure about how to handle the "dynamic" case though as
> the ASP seems to control the configuration.

>
>
> >
> >
> > The M3UA currently doesn't have a mechanism for the SG to "force" a
> > change in the ASP or AS state.  Kurt's interpretation that this was
> > subtly intended by the ASP-DOWN text was interesting - but this was
> > not the real reason behind the text.  The text was like that to
> cover
> > the point-to-point case where two ASPs are peers, with no SG.
>
> I was just looking for any solution that would not extend the
> protocol.
> 8^)
>
> [Greg] As an editor I thank you from the bottom of my heart  2;^)
>
> >
> >
> > The spec so far follows the assumption that the ASPs (using
> inter-ASP
> > communication where necessary) are the masters in charge of the
> > initiation of ASP and AS state changes.   The Notify message is more
>
> > of an indication to an ASP of a change in the AS state or an
> > indication of a change of ASP roles within the AS.  An ASP can
> compare
> > this notification to their view of the ASP/AS state and could take
> > action, but I thought it was clear that the ASPs are not obligated.
> > Certainly for at least the "AS-Pending" or "Insufficient ASP
> Resources
> > active in AS" Notifies, it is clear in Section 4.3.3.6 that "the
> > Notify does not explicitly compel the ASP(s) receiving the message
> to
> > become active. The ASPs remain in control of what (and when) traffic
>
> > action is taken."   In this context, I have no problem adding the
> new
> > Notifies that Hanns-Juergen and/or Kurt suggests, with the
> continuing
> > proviso that they are "non-compelling"
>
> I agree in general that the ASP normally dictates ASP and AS state
> changes. However, I would argue that the Notify (Alternate ASP Active)
>
> forces the ASP into the Inactive state, albeit at due to another
> ASP sending an ASP Active for an AS in Over-ride mode.
>
> [Greg] In my view, it is really the ASP-Active (Over-ride) from the
> alternate ASP that "forces" the ASP to "inactive".  I'm not saying
> that for some applications someone couldn't implement the Notify as a
> trigger to changes to the ASP's state (i.e., the ASPs don't talk to
> each other directly and use the Notifies to keep synch).   In that
> case they are really bouncing state information off the SG.

I can live with that view. 8)

>
>
> In any case, I think that certain actions on the SG, like an operator
> removing configuration data, should force the ASP to change state. I
> do
> not think that the SG should ever be able to force the ASP to become
> Active for an AS, but it should be able to force the ASP to become
> Inactive. The ASP is then free to remain Inactive or to become Active
> again.
>
> [Greg] Assuming that there is no traffic, I can agree.  Having the SG
> force an ASP to "inactive" and then having the ASP bounce back as
> "active", all while traffic is flowing is a no-no to me.

In the situation I was thinking of (i.e., removal of AS from SG), the ASP
would never become active again unless the AS was configured on the SG
again.

>
>
> >
> >
> > So, do we want to continue with the assumption that the ASPs are the
>
> > masters for the initiation of AS/ASP state changes or do we want to
> > add to the SG the ability to force ASPs  to "down or inactive".
> This
> > has been requested a couple of times in the past but I thought the
> > rough consensus then and now was that this was not needed.   If we
> > conclude that it is now needed, then we should probably run with
> > Kurt's suggestions, rather than using Notifies.
>
> If the SG cannot force the ASP to become Inactive then which of the
> following behaviors is appropriate when an operator wants to remove an
>
> AS that is already active from the configuration data on the SG:
> 1) Do not allow. The AS must be Inactive before it can be removed.
> This
> implies that the ASP must first Inactivate the ASP. This behavior is
> restrictive in my opinion.
> 2) Allow. Notify (AS-Inactive) is sent to ASP. ASP is not compelled to
>
> become Inactive, so it still considers itself Active. The SG will no
> longer forward traffic to the AS because it is not defined. I don't
> think that this is the correct behavior.
>
> [Greg] Well you have only two options, one in your view restrictive
> and the other incorrect  2;^)

Hence, I appeal to the collective wisdom of the mailing list and am rewarded
handsomely! 8^)

>
>
> How about 1.5) Only allow if underlying signalling traffic is stopped
> (operator-determined)?  Or 3) Add an ASP-Inactive (Force) or DEREG
> (Force) message from SG instead?  Option 3) has the cleanest semantics
> but does require extension of the protocol - some new procedures and
> potentially a new message (or modified ASP-Inactive/DEREG).  But this
> IMHO seems like a lot of work for a small problem.

1.5. Still requires some mechanism to know that the AS has been removed and
it will not be receiving any traffic for the AS.

As I indicated before I am ok with option 1.

>
>
> BTW, the solutions I proposed actually use a combination of ASP Down
> and
> Notifys. As I indicated below I would suggest that ASP Down not be
> used
> for management blocking and ERR be used instead. For the other
> problems
> I proposed that Notify be used to inform the ASP that the state of the
>
> AS has changed. The Notify does not force the ASP to change the AS
> state
> because the state is already changed on the SG.
>
> [Greg] I can agree to using an ERR instead of an ASP-Down for the
> "management blocking".  It would be quite a small change, and it is a
> little cleaner to me as this current ASP-Down shouldn't have an
> ASP-Down Ack in return.  I'll make the change unless people object.
>
> As for the Notify not forcing the ASP to change state - the SG has
> changed the AS state and will be throwing out any traffic to the AS.
> No applications are really going to work with signalling traffic
> flowing only in one direction, so the SG action does really force the
> ASP to change.  If it doesn't there will be lots of application level
> bells and alarms going off.
>
> Cheers,
>
>    Greg
>
> >
> >
> > Feedback, flames welcome!
> >
> > Cheers,
> >
> >     Greg
> >
> > PS: I'm not ruling out any other protocol solutions - but lets agree
>
> > on the requirement first.
> >
> >  -----Original Message-----
> > From:   Kurt Kite [mailto:[email-masked]]
> > Sent:   Saturday, April 21, 2001 12:31 PM
> > To:     sigtran
> > Subject:        Re: M3UA: Management Blocking at the SG
> >
> > Hi,
> >
> > Some of this has been discussed before, but I would not say that any
>
> > consensus
> > was reached. See below for some comments.
> >
> > Regards,
> > Kurt
> >
> > Schwarzbauer Hanns Juergen wrote:
> >
> > > Folks,
> > >
> > > hopefully I didn't miss some old E-Mails in case the issue shown
> > below has already been discussed.
> > >
> > > Chapter 4.3.3.1 "ASP-UP" contains a very short paragraph talking
> > about the case where on
> > > the SG a management action was taken, forcing the SG to respond to
>
> > subsequent ASP-UP
> > > messages with ASP-Down Ack as shown below:
> > >             SG                            ASP
> > >              |                             |
> > >    management|                             |
> > >    blocking  |                             |
> > >    of ASP---->                             |
> > >              |         ASP-UP              |
> > >              |<----------------------------|
> > >              |         ASP-Down Ack        |
> > >              |---------------------------->|
> > >              |                             |
> > >
> > > Question:
> > > What should happen, if there are already aktive ASP's when this
> > management action is taken?
> > >
> > > My proposal to handle this is shown below:
> > >
> > >             SG                            ASP
> > >              |                             |
> > >              |         ASP-Up              |
> > >              |<----------------------------|
> > >              |         ASP-Up Ack          |
> > >    management|---------------------------->|
> > >    blocking  |                             |
> > >    of ASP---->                             |
> > >              |     NOTIFY (ASP-blocked)    |
> > >              |---------------------------->|
> > >              |         ASP-Down            |
> > >              |<----------------------------|
> > >              |         ASP-Down Ack        |
> > >              |---------------------------->|
> > >              |                             |
> > >
> > > The proposed contents of NOTIFY message would be:
> > > Status Type:            value: 2, "other" (already there)
> > > Status Information:     value: 3, "ASP blocked (to be added)
> >
> > I believe that the draft intended to use the ASP-Down message to
> > accomplish
> > the above.
> >
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >    management|---------------------------->|
> >    blocking  |                             |
> >    of ASP---->                             |
> >              |                             |
> >              |         ASP-Down            |
> >              |---------------------------->|
> >              |         ASP-Down Ack        |
> >              |<----------------------------|
> >              |                             |
> >
> > The ASP-Down content is:
> > Reason: Management Blocking
> >
> > Reception of an ASP-Down with the above reason would force the ASP
> > to move the ASP to a Down state and send an ASP-Down Ack.
> > You will notice that the draft is careful to say that the ASP-Down
> "is
> > used
> > to indicate to a remote M3UA peer . . . ." It does not restrict the
> > ASP-Down
> > from being sent only from the ASP to the SG. However, this procedure
>
> > is not
> > explicitly described in the draft.
> >
> > >
> > >
> > > This Notify message would force the receiving ASP to initiate the
> > > ASP-Down procedure. The SG might want to start a supervision timer
>
> > > and upon its expiry could initiate the SCTP shutdown procedure.
> > >
> > > Now having a clean procedure to force an ASP to enter the ASP-Down
>
> > state
> > > initiated by the SG, we could alsowell ask why not to have the
> same
> > > mechanism to handle blocking of Routing Context at the SG (some
> > operators
> > > might want to do this, intentionally or not).
> > >
> > > The proposed procedure is shown below:
> > >
> > >             SG                            ASP
> > >              |                             |
> > >              |         ASP-Up              |
> > >              |<----------------------------|
> > >              |         ASP-Up Ack          |
> > >              |---------------------------->|
> > >              |         ASP-Active(RC1)     |
> > >              |<----------------------------|
> > >              |         ASP-Active Ack(RC1) |
> > >              |---------------------------->|
> > >    management|                             |
> > >    blocking  |                             |
> > >    of RC1---->                             |
> > >              |     NOTIFY (RC-blocked,RC1) |
> > >              |---------------------------->|
> > >              |         ASP-Inactive(RC1)   |
> > >              |<----------------------------|
> > >              |      ASP-Inactive ACK(RC1)  |
> > >              |---------------------------->|
> > >              |                             |
> > >
> > > The proposed contents of NOTIFY message would be:
> > > Status Type:            value: 2, "other" (already there)
> > > Status Information:     value: 4, "RC blocked (to be added)
> >
> > I raised the same question earlier. You can read the mails with
> > subject "Static Configuration" for all of the details. My issue
> > was that the operator wanted to remove an AS from the SG
> > configuration data. The proposed solution was similar to the
> > one you describe above.
> >
> >             SG                            ASP
> >              |                             |
> >              |         ASP-Up              |
> >              |<----------------------------|
> >              |         ASP-Up Ack          |
> >              |---------------------------->|
> >              |         ASP-Active(RC1)     |
> >              |<----------------------------|
> >              |         ASP-Active Ack(RC1) |
> >              |---------------------------->|
> >    management|                             |
> >    removal   |                             |
> >    of RC1---->                             |
> >              |     NOTIFY (AS-Inactive,RC1)|
> >              |---------------------------->|
> >              |                             |
> >
> > The proposed contents of NOTIFY message would be:
> > Status Type:            value: 1, "AS state change" (already there)
> > Status Information:     value: 2, "AS-Inactive" (already there)
> >
> > The NOTIFY message would force the receiving ASP to mark the
> > RC as Inactive. There is already a precedent for this with the
> NOTIFY
> > message with the "Alternate ASP Active" status information. This
> > solution eliminates a couple of messages and the need for a timer.
> >
> > >
> > >
> > > This Notify message would force the receiving ASP to initiate the
> > > ASP-Inactive procedure for that RC. The SG might want to start a
> > > supervision timer and upon its expiry could initiate the SCTP
> > > shutdown procedure, thus however, bringing the whole ASP down.
> > >
> > > Two more scenarios should be considered:
> > >
> > > a) no ASP in Active state at all
> > >             SG                            ASP
> > >              |                             |
> > >              |         ASP-Up              |
> > >              |<----------------------------|
> > >              |         ASP-Up Ack          |
> > >              |---------------------------->|
> > >    management|                             |
> > >    blocking  |                             |
> > >    of RC1---->                             |
> > >              |     NOTIFY (RC-blocked,RC1) |
> > >              |---------------------------->| do nothing, if no
> > >              |                             | ASP-Active was sent
> >
> > The above scenario goes away if the NOTIFY forces the ASP
> > to move the RC into the Inactive state as I described above.
> >
> > >
> > >
> > > b)race condition ASP-Active and NOTIFY
> > >             SG                            ASP
> > >              |                             |
> > >              |         ASP-Up              |
> > >              |<----------------------------|
> > >              |         ASP-Up Ack          |
> > >              |---------------------------->|
> > >              |                             |
> > >    management|              ASP-Active(RC1)|
> > >    blocking  |           +-----------------|
> > >    of RC1---->           |                 |
> > >              |     NOTIFY|(RC-blocked,RC1) |
> > >              |-----------|---------------->|
> > >              |           |                 |
> > >              |<----------+                 |
> > >              |                             |
> > >  respond with|      ASP-Inactive ACK(RC1)  |
> > >  ASPIA       |---------------------------->|
> > >              |                             |
> > >
> > > Resolving this race condition would require allowing to
> acknowledge
> > an
> > > ASP-Active message with an ASP-Inactive message. However, this is
> > already
> > > allowed for the ASP-Up as shown in the first figure.
> >
> > Yes, it is already allowed for the ASP-Up, but I think that makes
> the
> > protocol
> > more complicated and confusing than it needs to be. Why not just use
>
> > the ERR
> > message for these kinds of response. Why have an Ack message that
> can
> > indicate
> > both success and failure and the ERR message that can also indicate
> > failure?
> >
> > I propose that ERR (new error "Management Blocked") be used in this
> > case.
> > I wouldn't mind using ERR for the ASP Up case as well. 8^).
> >
> > Regards,
> > Kurt
> >
> > >
> > >
> > > looking forward hearing from you guys
> > >
> > > HannsJuergen
> > >
> > > SIEMENS AG
> > > Information and Communication Networks
> > > Wireline Network Communication
> > > Carrier Switching Networks
> > > ICN WN CS SE 51
> > >
> > > Tel:    +49 89 722 24236
> > > Fax:    +49 89 722 48212
> > > 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]
> > ---
> > 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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SG/SUA
Date: Fri, 4 May 2001 10:01:17 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello Srini,

Yes, this is possible. This scenario is even feasible without GTT : when you
configure the ASPs as handling traffic for SCCP-users (specific SSNs), you
can just route on SSN !

____________________________

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

-----Original Message-----
From: Miriyala Srinivas-FSM016 [mailto:[email-masked]] Sent: donderdag
3 mei 2001 23:32
To: sigtran
Subject: SG/SUA

Hello All,
 
Is there anything in the SUA draft that precludes to use SG to connect two
SUA nodes (ASP-SGP-ASP). What I mean is when SG gets a SUA message with  
- Route On GT : GT + SSN
 
After perform the address mapping (GTT like service) can the result be
another IP node.

Regards
Srini

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

-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti- spam
software. Please contact your email administrator if you have any questions
about this message. MailShield product info: www.mailshield.com

---
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: Backhauled message from inactive ASP
Date: Fri, 4 May 2001 10:56:33 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: Backhauled message from inactive ASP</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Barry Nagelberg [<A
HREF="mailto:[email-masked]">mailto:[email-masked]
</A>] </FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 03, 2001 6:00
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE:
Backhauled message from inactive ASP</FONT> </P>

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

<P><FONT SIZE=2>Your first impression was correct. </FONT> </P>

<P><FONT SIZE=2>Section 4.3.3.4 states of m3ua v6 &quot;If the SG or IPSP
receives any Data</FONT> <BR><FONT SIZE=2>messages before an ASPAC is
received, the SG or IPSP should discard them.&quot;</FONT> </P>

<P><FONT SIZE=2>The underlying assumption here is that if an ASP goes
inactive, then it is</FONT> <BR><FONT SIZE=2>considered by the SG to not
have sent an ASPAC.</FONT> </P>

<P><FONT SIZE=2>[Greg] Thanks for finding it Barry.&nbsp; I've been staring
at the text too much doing the Issue7 changes - I probably need more
coffee!&nbsp;&nbsp; So I think the current text is fine, the only question
left is whether we want to add an Error message (i.e., &quot;The SG MAY
respond to the ASP with an Error (Unexpected Message&quot;)).</FONT></P>

<P><FONT SIZE=2>Greg</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Barry Nagelberg</FONT>
<BR><FONT SIZE=2>Staff Software Engineer</FONT> <BR><FONT SIZE=2>RadiSys,
Corp.</FONT>
<BR><FONT SIZE=2>Signaling Products Design Center</FONT> <BR><FONT
SIZE=2>[email-masked]</FONT> <BR><FONT SIZE=2>+1-856-642-9229
x237</FONT> </P>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
Sidebottom, Greg [BCNR:7M01:EXCH] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]
</A>]</FONT> <BR><FONT SIZE=2>Sent: Thursday, May 03, 2001 5:54 PM</FONT>
<BR><FONT SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: RE: Backhauled message from inactive ASP</FONT>
</P>
<BR>

<P><FONT SIZE=2>Greetings Hanping ... </FONT> <BR><FONT
SIZE=2>&nbsp;-----Original Message----- </FONT> <BR><FONT
SIZE=2>From:&nbsp;&nbsp; Long, Hanping [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 02, 2001 8:44 PM </FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran </FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Backhauled message
from inactive ASP </FONT> <BR><FONT SIZE=2>Hi All: </FONT>
<BR><FONT SIZE=2>Whenever a backhauled message comes from an inactive ASP,
what should SG </FONT> <BR><FONT SIZE=2>handle this situation? </FONT>
<BR><FONT SIZE=2>From the specs of UAs, such as IUA or M2UA, there is no
corresponding error </FONT> <BR><FONT SIZE=2>type if I want to send a Error
message to ASP. </FONT> <BR><FONT SIZE=2>Thanks for your attention! </FONT>
<BR><FONT SIZE=2>hanping </FONT>
<BR><FONT SIZE=2>[Greg] I'm glad you asked this question - I was under the
mistaken</FONT> <BR><FONT SIZE=2>impression that the M3UA text covered this
off.&nbsp;&nbsp; I think the unwritten (!)</FONT> <BR><FONT SIZE=2>agreement
to date was that if an SG receives Data traffic from an inactive</FONT>
<BR><FONT SIZE=2>ASP, it should discard it silently.&nbsp; So we should add
a statement in the</FONT> <BR><FONT SIZE=2>ASP-Active procedures like&quot;
</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; &quot;If the SG receives
any Data messages from an ASP in the </FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;inactive&quot; state, the SG
should discard them.&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>If we want to add an Error message for this case, we could use
Error</FONT> <BR><FONT SIZE=2>(Unexpected Message).&nbsp; But it may not be
a good idea to respond to every</FONT> <BR><FONT SIZE=2>Data message.&nbsp;
So how about &quot;The SG MAY respond to the ASP with an Error</FONT>
<BR><FONT SIZE=2>(Unexpected Message).</FONT> <BR><FONT SIZE=2>Thanks,
</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Greg </FONT> </P>

<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</FONT> <BR><FONT
SIZE=2>[email-masked] </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>
To: "sigtran" <[email-masked]>
Date: Fri, 04 May 2001 08:50:55 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Fwd: [Tsvwg] SCTP and checksums
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

--

--------- Forwarded Message ---------

DATE: Fri, 04 May 2001 09:10:00
From: Randall Stewart <[email-masked]>
To: [email-masked]
Cc:Lyndon Ong <[email-masked]>
Dear All:

I have just completed my study of the performance of various sums and such.
I had some interesting results, to say the least :)

Here is a summary of my findings, I can provide details for any who would
like (in the form of a starOffice spreadsheet or a email with the results a
bit less raw).

Summary:
----------------------------------------------------------------- CRC-32 -
Varies widly based on caching and type of algorithm and
         size of arrays. Generaly I saw anywhere from 3us - 128us
         per call on a PI running the receive side of my tests.

Adler-32 - Tended to take between 2-91 us on my PI. Not sure why the
           wide variance. Most of the results were around 60-70us
           per call.

ModAdler - Tended to be slightly faster than Adler-32 (as expected)
           ranging in the 40-60us per call range.

Fletcher - Was faster than either adler32 variant (using only 16 bit
           fletcher) ranged anywhere from 15us - 50us per call during
           my various test runs... but for the most part consistently
           lower time frames than either adler.

TCP32 - This was put forward in some early discussion by Craig Partridge so
        I whipped up something along the lines of the IP sum only adding
        32 bits at a time. 1's compliment at the end and of course all
        of the wraps carried back in. I did this assuming a 32 bit 
        adder so that each addition needed to check for wrap and maintain
        a wrap counter which was folded in at the end. This tended to
        always be slightly fast than Fletcher somewhere between 3-15us
        in all cases with no inconsistent results. 

Now after looking at these results I have reached the following conclusion:

A) CRC-32 is to variable and will I think result in to much work for 
   small devices. If one assumes a device with a small cache you are looking
   most likely in the higher end of my results and in the worse case it can
   get pretty bad. 

B) Fletcher seems to do much better than Modifed adler in terms of
performance
   due to the smaller number of instructions needed to execute it. 

C) TCP32 did best of all but is completely new. I am hesitant to go down
   a path of a unknown-unexplored checksum that has not been studied very
   well. Been there, done that, did not like the results :)

So I think the bottom line is we should shift SCTP into a 16 bit Fletcher
algorithm
which will:

1) Improve performance
2) Provide better checksum protection
3) Has been studied enough and is actually an alternative that
   TCP can use (but it seems does not).

I will begin working on the RFC2960Bis document today. I will try to have it
out next week... I am thinking on  (urged by Lyndon) incorperating all of
the findings of the
bakeoff draft in this (except the last bakeoff... I need to write a seperate
ID on this one so that I can get some help from the IPv6 community on the 
only issue found... address scoping in V6 :>)

Anyway please comment to me ... throw things etc... it is helpful if you
make
sure I am copied .. since I still have the northpoint flu and my normal IETF
email is delayed quite a bit being batched once or so every day...

Comments and opinions would be most helpful...

PS: Lyndon can you please forward this to the sigtran wg since it won't take
    my posts from my non-subscribed cisco account... thanks

Thanks

R
-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

_______________________________________________ tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

--------- End Forwarded Message ---------

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti- spam
software. Please contact your email administrator if you have any questions
about this message. MailShield product info: www.mailshield.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SG/SUA
Date: Fri, 4 May 2001 13:30:10 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate4.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate4.mot.com [144.189.100.102]
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 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.19">
<TITLE>RE: SG/SUA</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>Therefore, the definition of SG in SUA spec. need to be
revised.</FONT> </P>

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Friday, May 04, 2001 1:01
AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt;
Subject: RE: SG/SUA</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello Srini,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yes, this is possible. This scenario is even feasible
without </FONT> <BR><FONT SIZE=2>&gt; GTT : when you</FONT> <BR><FONT
SIZE=2>&gt; configure the ASPs as handling traffic for SCCP-users </FONT>
<BR><FONT SIZE=2>&gt; (specific SSNs), you</FONT> <BR><FONT SIZE=2>&gt; can
just route on SSN !</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ____________________________</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gery Verwimp</FONT> <BR><FONT SIZE=2>&gt; &gt; SIEMENS
ATEA</FONT> <BR><FONT SIZE=2>&gt; &gt; ICN D CS D5</FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel. : +32 14 25 3424</FONT> <BR><FONT
SIZE=2>&gt; Fax : +32 14 25 3212</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>&gt;
____________________________________</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: Miriyala Srinivas-FSM016 [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: donderdag 3 mei 2001 23:32</FONT> <BR><FONT
SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: SG/SUA</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello All,</FONT> <BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Is there anything in the SUA draft that precludes to
use SG </FONT> <BR><FONT SIZE=2>&gt; to connect two</FONT> <BR><FONT
SIZE=2>&gt; SUA nodes (ASP-SGP-ASP). What I mean is when SG gets a SUA
</FONT> <BR><FONT SIZE=2>&gt; message with</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; - Route On GT : GT + SSN</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; After perform the address mapping (GTT like service)
can the result be</FONT> <BR><FONT SIZE=2>&gt; another IP node.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Regards</FONT>
<BR><FONT SIZE=2>&gt; Srini</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as: </FONT>
<BR><FONT SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; To unsubscribe send a blank email to</FONT> <BR><FONT
SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; -----------</FONT> <BR><FONT SIZE=2>&gt; This email
server is running an evaluation copy of the </FONT> <BR><FONT SIZE=2>&gt;
MailShield anti-</FONT> <BR><FONT SIZE=2>&gt; spam software. Please contact
your email administrator if you have any</FONT> <BR><FONT SIZE=2>&gt;
questions about this message. MailShield product info: </FONT> <BR><FONT
SIZE=2>www.mailshield.com</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>
From: [email-masked]
Date: 5 May 2001 10:31:58 +0900
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
X-SMTP-HELO: cm612.mail.goo.ne.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: cm612.goo.ne.jp [210.150.25.76]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Gery,

>  We\'re talking about redundancy on three different levels, I think :

my view is little bit different.

>  - network redundancy : redundancy of routes between SG and ASP, that\'s
why
>  we have the SCTP multihoming feature, no ? So whether the physical

yes, if you are saying about IP network redundancy.
and there can be SS7 network redundancy provided by multiple SG.

>  interfaces are all connected to a single SGP or more SGP\'s is
transparent
>  for an ASP. And this is the main reason for having multiple SGPs at an SG
as

no, if you are saying about an association.
there can be just one association between an SGP and an ASP.

>  well, or am I missing something here ? (Multiple routes, handled by
multiple

i think multiple SGP in an SG makes sense following cases;  a. to make M3UA
over TCP redundant from IP network point of view  b. to make SG redundant
from platform/host environment point of view and also multiple SG makes
another redundancy from SS7 point of view.

>  processors on the SG-host to avoid single points of failure). A single SG
>  only has a single management view of it\'s SCTP associations, and each
SGP is
>  responsible of informing layer management of it\'s part of the view
(status
>  of physical connections).
> 
>  - platform/host redundancy : that\'s why we may want to connect an ASP to
2
>  SGs (2 SCTP associations) in case an entire SG breaks down (no matter how

again, `2 SCTP associations\' means the ASP is connected to 2 SGPs not SGs.

IMO, what we are talking about is this confusion about multiple SGP in an SG
and multiple SG.

>  many SGPs it has, there might always be central errors or an earthquake
or
>  whatever). And also, for ANY kind of traffic, there has to be more than 1
>  ASP available to each SG.
> 
>  - application redundancy : that\'s why we have multiple ASPs in an AS to
>  handle a PARTICULAR portion of the traffic.
> 
>  At least from a functional point of view, an SGP doesn\'t add anything.
An
>  ASP does, while it may be configured to support multiple AS\'s ! I don\'t
see
>  an SGP servicing more than one SG ??? So I think it\'s wrong to search
for a
>  parallel between the two.

what do you mean by `functional point of view\'?

in my understanding, SG/SGP are different level entity as;
  SGP: an endpoint of an association
  SG:  a gateway from/to SS7 network

-- 
Kazuo Watanabe

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Deepa Tonse <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2PA query
Date: Mon, 7 May 2001 14:49:49 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi

Will there be M2PA interaction with layer manger be defined in the near
future,
in the next version of the draft?

Thanks,
Deepa
RADISYS Coropration

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Mon, 7 May 2001 20:57:02 +0200 (MEST)
From: ecejoz <[email-masked]>
Reply-To: [email-masked]
Subject: First M3UA Interop Test
To: "sigtran" <[email-masked]>
Cc: [email-masked], 
    "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>, 
    [email-masked]
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

  Hi,
  
  The first Interop Test of M3UA is running in Madrid, from Monday 7th till
Friday 11th, hosted by Ericsson.
  
  16 companies and 33 participants are involved in the event.
  
  We tested the simple 1+0 case succesfully and the following issues were
found:
  
  - the handling of the ASPUP and preconfigured  or dynamic configured SG.
  
  - the handling of the Notify messages needs clarification. 
  
  This issues will be covered in the 7th version of the ID.

  A detailed report will be send at the end of the week, we keep you
informed about the ongoing testing.

  Best Regards
  
  /Interop Coordination Team
  
  	- Barry Nagelberg
  	- Kurt Kite
  	- Jaime Olivares
  	- Heinz Prantner
  	- Michael Tuexen

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Zhang Yi <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M3UA Sample Configuration question
Date: Tue, 8 May 2001 11:51:02 +0800
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-SMTP-HELO: smtp.huawei.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.96.135.132]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML>
<HEAD>

<META content=text/html;charset=gb2312 http-equiv=Content-Type> <META
content='"MSHTML 4.72.3110.7"' name=GENERATOR> </HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 face="Times New Roman" size=4>Hi, all,</FONT></DIV>
<DIV><FONT color=#000000 face="Times New Roman"
size=4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In M3UA draft 06, the M3UA endpoint to
endpoint configuration is described at section 1.5.2 as Example 2: SCCP
Transport between IPSPs. But there is no further description to how the two
M3UA instance present in two IPSPs set up their communication. It looks that
the AS, ASP status management procedure (described in section 4.3) is not
applicable in this case. </FONT></DIV>
<DIV><FONT color=#000000 face="Times New Roman"
size=4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So, what's procedure shall be
used for two IPSPs? Shall only association status between two IPSPs be taken
into consideration? </FONT></DIV>
<DIV><FONT color=#000000 face="Times New Roman" size=4></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 face="Times New Roman" size=4>Yours</FONT></DIV>
<DIV><FONT color=#000000 face="Times New Roman" size=4>ZhangYi</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

</x-html>

Attachment Converted: "c:\program files\qualcomm\eudora pro\attach\Zhang
yi.vcf" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Subject: Re: [Tsvwg] RFC2960bis
Date: Tue, 08 May 2001 14:59:07 +0900
From: FUKUMOTO Atsushi <[email-masked]>
X-SMTP-HELO: tsbgw.wide.toshiba.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tsbgw.wide.toshiba.co.jp [202.249.10.123]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

One question I have regarding SCTP spec is: Suppose a node A is configured
with two addresses (address A1 and A2), and it received an INIT chunk in a
packet with destination address A1.  When sending INIT-ACK, MAY I use
address A2 as source address of packet, or MUST I use A1?  There are some
discussion in bake-off draft about the choise of source address, but
INIT-ACK seems to be special case since the initiating node will lack the
knowledge of the responding node.

					FUKUMOTO Atsushi
					[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, 08 May 2001 08:15:26 -0500
From: Randall Stewart <[email-masked]>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [Tsvwg] RFC2960bis
X-SMTP-HELO: sj-msg-core-1.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ok,

With some leaps and bounds ... and a bit of ftp mixed in... I now get in a
postion where I can do a reply all :) (Today though is the day that I have a
FOC on my replacment DSL service... whatever that means :-/)

FUKUMOTO Atsushi wrote:
> 
> One question I have regarding SCTP spec is: Suppose a node A is
> configured with two addresses (address A1 and A2), and it received an
> INIT chunk in a packet with destination address A1.  When sending
> INIT-ACK, MAY I use address A2 as source address of packet, or MUST I
> use A1?  There are some discussion in bake-off draft about the choise
> of source address, but INIT-ACK seems to be special case since the
> initiating node will lack the knowledge of the responding node.
> 

Yes, INIT-ACK processing is a special case. We have discussed this before
on the list and I thought we had it pretty clear in RFC2960. If you receive
a packet with an INIT-ACK you must not only look at the source address of
the packet (to find the association), but you must also look at the
addresses listed within the TLV  parameters inside the INIT-ACK. This is
exactly as you state, because the source address may or may NOT be the same
that you sent the INIT to, and you as yet, do not have the information
of the INIT-ACK. In the reference implementation there is a special
find-association()
surprising-ly called SCTPspecialFindAssociation() ... it is only called when
an
INIT OR INIT-ACK arrives... remember you have the same case that can occur
with
a race ... i.e. ... I send off an INIT to you... and at the same time you
send me an INIT... in order to find this case both the processing of the
INIT
AND the INIT-ACK must use this special lookup to find the association.

The special find... mundanely parses through the TLV's in the INIT (or
INIT-ACK)
and if it finds a address parameter it does an appropriate lookup on the
address... until
it finds an association.. have a look in sctputil.c and you will find it but
it is a quite boring function really :>

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Apparently-From: <[email-masked]>
From: Patrick Lam <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: How do I setup and ATM connection for the voice trunk?
Date: Tue, 8 May 2001 23:35:42 -0700
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: smtp011.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp011.mail.yahoo.com [216.136.173.31]
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.4522.1800" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi all:</FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>Regarding to the
voice trunk setup in an SS7/ATM network, I have the following few
questions:</FONT></DIV> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>1.&nbsp; In SS7/ISUP, where should I place the
ATM address of the source SSP?</FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>2.&nbsp; Should the
voice trunk be setup before or after the call has been setup?&nbsp; I mean,
after&nbsp;the source SSP&nbsp;sends IAM, is it supposed to setup the UNI
with the ATM network?&nbsp; Or should the destination SSP setup the ATM
path, because now it's got the ATM address of the source SSP?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>Thanks very much in advance,</FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>Patrick.</FONT></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-Apparently-From: <[email-masked]>
From: Patrick Lam <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Any suggestion on SS7 stack?
Date: Tue, 8 May 2001 23:38:39 -0700
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: smtp012.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp012.mail.yahoo.com [216.136.173.32]
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.4522.1800" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi all:</FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>Just wondering if
anyone has any suggestion on the commercial SS7 stacks out there?&nbsp; I am
looking for something that has high reliability (and hopefully performance
as well, but reliability is more important).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>Thanks very much in advance,</FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>Patrick.</FONT></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>
Subject: Re: Any suggestion on SS7 stack?
To: "sigtran" <[email-masked]>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
From: "Prasad S. Ganti" <[email-masked]>
Date: Wed, 9 May 2001 08:45:08 -0400
X-MIMETrack: Serialize by Router on notes340/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 05/09/2001 08:45:08 AM
X-SMTP-HELO: dnsmx1rrc.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [128.96.20.41]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Patrick,

I can suggest Trillium Digital Systems.  Please try their website
trillium.com. It is an Intel company now. We are using some of their other
stacks. Generally, robust and reliable.

Thanks,
Prasad

                    Patrick Lam

                    <allmailinglist@        To:     "sigtran"
<[email-masked]>                      
                    yahoo.com>              cc:     (bcc: Prasad S.
Ganti/Telcordia)                                  
                                            Subject:     Any suggestion on
SS7 stack?                                 
                    05/09/01 02:38

                    AM

                    Please respond

                    to sigtran

Hi all:

Just wondering if anyone has any suggestion on the commercial SS7 stacks out
there?  I am looking for something that has high reliability (and hopefully
performance as well, but reliability is more important).

Thanks very much in advance,

Patrick.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] Attachment Converted:
"c:\program files\qualcomm\eudora pro\attach\att1.htm" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
From: Steve Northridge <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Any suggestion on SS7 stack?
Date: Wed, 9 May 2001 09:04:21 -0400
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: spdmraab.compuserve.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ds-img-rel-2.compuserve.com [149.174.206.155]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Patrick,

Please include your personal e-mail address so that commercial messages can
be excluded from this board. Please contact me via my e-mail address below
to discuss the topic further.

Thanks,

Steve Northridge
Ulticom
[email-masked]

-----Original Message-----
From: Prasad S. Ganti [mailto:[email-masked]] Sent: Wednesday, May 09,
2001 8:45 AM
To: sigtran
Subject: Re: Any suggestion on SS7 stack?

Patrick,

I can suggest Trillium Digital Systems.  Please try their website
trillium.com. It is an Intel company now. We are using some of their other
stacks. Generally, robust and reliable.

Thanks,
Prasad

                    Patrick Lam
                    <allmailinglist@        To:     "sigtran"
<[email-masked]>
                    yahoo.com>              cc:     (bcc: Prasad S.
Ganti/Telcordia)
                                            Subject:     Any suggestion on
SS7 stack?
                    05/09/01 02:38
                    AM
                    Please respond
                    to sigtran

Hi all:

Just wondering if anyone has any suggestion on the commercial SS7 stacks out
there?  I am looking for something that has high reliability (and hopefully
performance as well, but reliability is more important).

Thanks very much in advance,

Patrick.

---
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]
To: "sigtran" <[email-masked]>
Date: Wed, 09 May 2001 08:31:19 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: Any suggestion on SS7 stack?
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.185.123.82]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Let's keep these discussions off the list, please, it's not intended as a
forum for vendor comparisons.  As has been noted, people can reply to
Patrick offline rather than on the list.

Cheers,

L. Ong 
--

On Tue, 8 May 2001 23:38:39    Patrick Lam wrote:
>Hi all:
>
>Just wondering if anyone has any suggestion on the commercial SS7 stacks
out there?  I am looking for something that has high reliability (and
hopefully performance as well, but reliability is more important).
>
>Thanks very much in advance,
>
>Patrick.
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
[email-masked]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Balani, Sandeep" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA Question ..
Date: Wed, 9 May 2001 10:26:47 -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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi All, 
   I have a question about M2UA. 
It is possible to have a subset of interface-id's in an ASP-ACTIVE messages
from ASP to SG.
I was wondering could anyone please tell me why an ASP might want to do such
a thing ? 

For ex :
                          [ SG ]
[ASP]

           IID1 -----
                        AS-1 ----------------- ASP1
<------------------------      ASP
           IID2 -----                          |       ASP-ACT (with IID1
and IID3)
                                               |
                                               |
           IID3 ------                         |
                        AS-2-------------------|
   
           IID4 ------

According to figure above if IID-1 and IID2 belong to AS-1 and IID3, IID4
belong to AS-2. Now the ASP is sending ASP-ACT to SG with IID-1 and IID-3,
which will mark the AS-1 and AS-2 both active for ASP1. 
My question is why would ASP want to include a subset of IID's ? Can an ASP
intentionally be allowed to include a subsetof IID's in ASP-ATIVE messages ?
Or it should just be considered an accidental case ?

Thanks
Sandeep  

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 9 May 2001 12:30:45 -0700 (PDT)
From: Kacheong Poon <[email-masked]>
Reply-To: [email-masked]
Subject: RE: [Tsvwg] RFC2960bis ... heads up Steve
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]>
List-Unsubscribe: <mailto:[email-masked]>

> Well, could we just ping some people on this subject (form even
> a mini-design team) to work this out for the BIS draft.  As 
> SCTP & IPv6 will be seeing deployment in the 2nd half of the 
> year, I think we should at least get a good solution for this 
> soon.

Talking about selecting the correct set of addresses in the INIT/INIT_ACK
chunk, I don't think we have a good idea about what to do with v4 addresses,
let alone v6...  I remembered we had a brief discussion about this some time
back.  But I don't think anyone has come up with a good solution.  And it
seems to me that this kind of address selection will necessarily involve
site policy.

Just for an imaginary example, every machines in a company has 2 IPv4
addresses, each from a different ISP.  So the policy may be that talking to
another site of that company should not use addresses from ISP x because of,
say, security and cost.  I think people can come up with all sorts of other
examples which a policy is required.

This leads me to think that whether it is appropriate to include this kind
of discussion in the 2960bis.  The concern is that it is not really a
protocol issue.  It becomes an implementation or system administration
issue.  And I don't thinkt it is a good idea to include this kind of
dicussion in a protocol standard.

On the other hand, if we know of something that definitely should not be
done, we may consider it putting in 2960bis.  For example, if the INIT chunk
does not have a link local address, SCTP should not include any link local
addresses in the reply.
But the reverse may not be straight forward.  Should SCTP return link local
address if the INIT chunk has a link local address?
This is tricky.  It makes perfect sense in some cases but not in other.

So I'd suggest not putting this kind of discussion in the bis, but have
another document discussing this issue.

							K. Poon.
							[email-masked]

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 09 May 2001 18:47:36 -0500
From: salerno <[email-masked]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010131 
            Netscape6/6.01
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Any suggestion on SS7 stack?
X-SMTP-HELO: chuckie.dgms.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [38.150.156.4]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<html><head></head><body>Patrick,<br>
<br>
&nbsp; Please email me directly,&nbsp; we offer SS7 but I would prefer to
take this offline of the mailing list.<br> You can contact me at <a
class="moz-txt-link-abbreviated"
href="mailto:[email-masked]">[email-masked]</a><br> <br>
thanks<br>
 &nbsp;&nbsp; pete<br>
<br>
Patrick Lam wrote:<br>
<blockquote type="cite"
cite="mid:LYRIS-1649-1545-2001.05.09-02.47.00--pete.salerno%23DGMS.COM@lyris
.nortelnetworks.com">
  <div><font face="Arial" size="2">Hi all:</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">Just wondering if anyone has any
suggestion on the commercial SS7 stacks out there?&nbsp; I am looking for
something that has high reliability (and hopefully performance as well, but
reliability is more important).</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">Thanks very much in advance,</font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2">Patrick.</font></div>

---<br>

You are currently subscribed to sigtran as: <a
class="moz-txt-link-abbreviated"
href="mailto:[email-masked]">[email-masked]</a><br>

To unsubscribe send a blank email to <a class="moz-txt-link-abbreviated"
href="mailto:[email-masked]">leave-sigtran-214
[email-masked]</a> </blockquote>
  <br>
  <pre class="moz-signature">-- 
 
Pete Salerno 
847.550.8679 

  /  /
 /  /  / -/- . __  __  _ _ 
/__/  /  /  / /_  /_/ / / /
</pre>
  <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: Wed, 9 May 2001 23:34:03 -0400 (EDT)
From: Jim Bound <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], 
    [email-masked], [email-masked]
Subject: Re: [Tsvwg] RFC2960bis ... heads up Steve
X-SMTP-HELO: mail.users.bit-net.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [208.146.132.4]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Randy,

Comments enclosed.

This was forwarded to me and not on this list for now as I trust
you:---)....

> [email-masked] wrote:
> 
> > 
> > > These are the main clarifications found in the bakeoffs (the
> > > latest bakeoff did not identify further issues except one
> > > regarding IPv6 that will take more work).
> > 
> > I strongly suggest that we try to get the support for IPv6 right
> > in the BIS draft, for a very practical reason.  SCTP is a protocol
> > that will be deployed in many 3GPP networks, which are scheduled
> > for later this year.  IPv6 is also a key component of this.  I
> > think the time is now do this right.
> > 
> > I'll gladly pitch in on this, and might even have some resources
> > to play around with different proposals in the lab here, if needed.
> > I can also ping the IPv6-heavyweights around here to comment on
> > solutions.
> > 
> > What I would need, however, is a brief summary of the problems
> > & possible solutions.  I have a general idea of what they are ...
> 
> John:
> 
> The problem is not for lack of solutions :> 
> 
> What is at issue is address selection and scoping.. i.e. what
> addresses do you put in the INIT and INIT-ACK?
> 
> One agreement we reached is:
> 
> * You never place a Link-Local address within an INIT or INIT-ACK. The
>   reason being is that you MUST receive a packet in the FROM field of
>   the IP address to really know what interface the Link-Local belongs
>   to. So the only way to get an association to include Link-Local
>   addresses is to send an INIT TO a Link-Local address and 
> then respond
>   back TO the sender of the INIT of course using the link-local. The
> rules for
>   IP address selection will cause you to add the Link-Local to the
> association.
 
We should permit link-local addresses just like we do for TCP.  Each
link-local and site-local will have a sin6_scope_ID or identifier.
Both ends of the SCTP connection will have an identifier for the link-local
address.  In IPv6 the base API permits one to identify the interface based
on the scope and identifier.  With this why should not link-locals be
permitted by SCTP?

But an implementation of IPv6 would have to support the idea of scoping
within their IP kernel stack.  Most do not today that are product but all
had to deal with this to get it to work.  

> The problem we have is with Site-Local addresses....
> 
> Two methods showed up in the composing of a INIT:
> 
> A) Scope the addresses so that if I am sending to a Site-Local,
>    include all of my Site-Local and Global addresses... If I am
>    sending to a Global address, only send the global addresses I hold
>    in the INIT.
 
This is the correct behavior but it really should be up to each
implementation but this is the default I would have implemented.

> or
> 
> B) Always send your Site-Local and Global addresses to a peer.
 
This is a waste and the risk of the other peers site-local not being in your
site will be very high for the first real uses of SCTP.
> 
> Of course the response with an INIT-ACK had similar rules:
> 
> 1) Scope the addresses based on if a Site-Local was included in
>    the INIT... if so include your Site-Local address.
 
This is the correct response.

> or
> 
> 2) Always send your site-Local and Global addresses in the INIT-ACK.
 
Same response as to B.

> 
> Method B/2 is simpler, and takes less work. It depends on the
> HeartBeat to detect that a Site-Local address is NOT reachable
> from two seperate sites. 
> 
> Its down side is what happens if I send you an INIT with my site
> local (from cisco to nokia... i.e. not the same site) but I list
> my site-local addresses. You pick them up and send me back your
> site-local
> addresses. But then somewhere on my site someone has used your
> site-local address,
> guess what happens on my first HB to "your site-local" address? I get
> an OOTB abort knocking down the association..
 
Also site-local dst addresses will not be permitted to leave the site they
are located in by the Ipv6 Routers is current thinking.

> Method A/1 has the decided advantage of preventing the above bad
> behavior at
> the expense of another problem. Lets say I send a INIT to Steve
> Deering's machine.
> ...(see Steve, not only do I want your opinion.. I also want your
> machine :->)...
> I specify his global address since that is all I know.. but we are on
> the same
> site. Now I do have a redundant network as well, but it is site local
> only with
> no global scope. Guess what, I loose the use of this network since I
> INIT'ed to
> the global address. If I INIT to the site-local then I get use of both
> networks...

I don't see why you think we have a redundant network.

A rule that might be good is don't accept site-local addresses that are not
in your site in SCTP as SCTP peer!!!!

> The original code I wrote implemented the above A/1 but in 
> order to make
> things
> work properly at the bakeoff I commented out a lot of it to work like
> B/2..
 
I think you did write the right code.  And doing B/2 worked only because a
longer list was able to be checked.

SCTP should determine how to make A/1 work and your gut instinct was
correct.

But make sure the problem is that of not understanding scoping in IPv6
within an IPv6 context.  I think you should solve this here in the transport
area and the IPv6 experts should come to you.  You could get more than you
asked for throwing this over the wall to another group who does not
understand SCTP at this point in time till its more pervasive in our
community out of the transport area.  I am here as needed and I am sure
Steve and others are too.  The ADs in this case are intimately familiar with
IPv6 too.  IPng and Multihome groups are very good like this one but they
are pretty maxed right now too.
My 2 cents on that idea.

regards,
/jim

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
From: Steve Northridge <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Any suggestion on SS7 stack?
Date: Wed, 9 May 2001 09:04:21 -0400
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: spdmraab.compuserve.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ds-img-rel-2.compuserve.com [149.174.206.155]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Patrick,

Please include your personal e-mail address so that commercial messages can
be excluded from this board. Please contact me via my e-mail address below
to discuss the topic further.

Thanks,

Steve Northridge
Ulticom
[email-masked]

-----Original Message-----
From: Prasad S. Ganti [mailto:[email-masked]] Sent: Wednesday, May 09,
2001 8:45 AM
To: sigtran
Subject: Re: Any suggestion on SS7 stack?

Patrick,

I can suggest Trillium Digital Systems.  Please try their website
trillium.com. It is an Intel company now. We are using some of their other
stacks. Generally, robust and reliable.

Thanks,
Prasad

                    Patrick Lam
                    <allmailinglist@        To:     "sigtran"
<[email-masked]>
                    yahoo.com>              cc:     (bcc: Prasad S.
Ganti/Telcordia)
                                            Subject:     Any suggestion on
SS7 stack?
                    05/09/01 02:38
                    AM
                    Please respond
                    to sigtran

Hi all:

Just wondering if anyone has any suggestion on the commercial SS7 stacks out
there?  I am looking for something that has high reliability (and hopefully
performance as well, but reliability is more important).

Thanks very much in advance,

Patrick.

---
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-Lotus-FromDomain: HSS
From: [email-masked]
To: "sigtran" <[email-masked]>
cc: [email-masked]
Date: Thu, 10 May 2001 11:58:29 +0530
Subject: SS7 stack from Hughes
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greetings !

I came to know of your possible interest in SS7 software stacks, and have
taken the liberty of communicating directly with you to offer our SS7 stack,
that has been very successfully integrated in our customers' Narrowband and
Broadband network node implementations.

We, at Hughes Software Systems (HSS) have an extensive portfolio of software
protocols and products in the Wireline (e.g. SS7, Broadband SS7, V5, ATM,
INAP), Wireless (e.g. GPRS Gb,  UMTS MAP, RANAP, Iu-PS and CS), and the VoIP
(MGCP, MEGACO, SIGTRAN, MEGACO, SIP) domains.

In the SS7 portfolio, we have a complete set of stacks with the MTP2, MTP3,
SCCP, TCAP, ISUP,  INAP, and UMTS MAP offerings.  The core SS7 stack is
offered for both Narrowband as well as Broadband network nodes. These have
been implemented on a wide variety of signalling cards (e.g. Adax,
Performance Technologies, Datakinetics, etc) and on various operating
systems (e.g., Solaris, VxWorks, etc.). Specific implemenatations are
carried out by HSS via its strong team of over 1000 engineers. In addition,
there are a rich set of national and industry variants that are supported by
us. The SS7 stack has been certified by BellCore in the USA.

The SS7 stack is compliant to ITU-T, ETSI, ANSI and Bellcore GR
specifications.
We provide source code for all the SS7 layers, and offer very attractive
licensing options based on our customer needs.

Our products are software modules which are designed to be platform
independent and can be ported across different hardware platforms and
operating systems. All the three stacks are  based on the HSS Advanced
Architecture for Protocol Engineering  Framework (AAPE)  and designed for
portability, scalability, and flexibility. This has enabled us to port our
stack and effectively satisy the needs of our customers who have individual
preferences for Motorola PowerPC, SUN Sparc, Intel/Solaris, NT, VxWorks,
pSOS, Lynx systems.

Our USP is  in our ability to blend our professional services to assist in
architecting the the end solutions with our customers, and our domain
experience in the Telecom world, spanning across Wireless, Satellite,
Wireline as well as VoP infrastructrue. We are part of the Hughes/General
Motors family, and have offices in the US, Europe as well as India. We are
also represented via Business Partners for the Asia Pacific rim.

Our customer list, across our offerings (due to confidentiality reasons),
includes Marconi, NEC, Italtel, ADAX, Lucent, Ericsson, Dialogic/Intel,
XACCT, Armillaire, Alcatel, SUN, Embedded Wireless, etc.

I will be very happy to send you more information on our product !

My apologies for having taken the liberty of sending this directly to you,
but do hope we can proceed from here, and at this stage I can only assure
you that we will strive to meet all your expectations.

Looking forward to hearing from you,

With best regards

Anita

Anita B Gupta
Asst Vice President
Hughes Software Systems

www. hssworld.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Lotus-FromDomain: HSS
From: [email-masked]
To: "sigtran" <[email-masked]>
Date: Thu, 10 May 2001 12:17:55 +0530
Subject: APOLOGY : Re: SS7 stack from Hughes
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

MY very sincere personal aplogies to all for having used the mailing list by
mistake to send the mail on our SS7 stack. It was a big mistake and an
oversight.

SORRY once again !

Anita

Anita B Gupta

---
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: SG/SUA
Date: Thu, 10 May 2001 12:58:33 +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 Srini,

> Is there anything in the SUA draft that precludes to use SG 
> to connect two SUA nodes (ASP-SGP-ASP). What I mean is when SG 
> gets a SUA message with
>  
> - Route On GT : GT + SSN
>  
> After perform the address mapping (GTT like service) can the result be
> another IP node.

Catching up on a backlog of messages.  

This is "possible" but for now, it is outside the scope of the current SUA
draft.  Let's say that there is nothing preventing this, but it isn't part
of the architecture that is currently supported.

br,
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: SUA5: Address Mapping text
Date: Thu, 10 May 2001 13:17:28 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all, 

There has been some discussion as of late on SUA / GTT / ENUM / etc.  I have
updated the text.  Please comment.

br,
John

1.5 Internal Functions Provided in the SUA Layer 

It is assumed that Global Title Translation (GTT) occurs outside of SUA.
However, SUA will need to map the output of the GTT process, when
applicable, to an ASP via an Address Mapping Function (AMF).  

When SS7 addressing is used by the upper layer protocol, SUA will need to
determine the correct signaling endpoint.  How this is done is
implementation specific, but it could involve DNS [ENUM] or local
configuration information.

1.5.1 Address Translation and Mapping at the SG

The SG MUST provide address translation and mapping functions to direct
messages received from the SS7 network to the appropriate IP destination.

In order to support message distribution, the SG maintains an address
translation table, which maps the incoming SS7 messages to the appropriate
AS.  The relevant fields of the incoming SS7 message is compared to the
existing Routing Keys.  The Routing Keys reference an Application Server,
which will have one or more ASPs processing traffic for the AS.  The
availability and status of the ASPs is handled by SUA ASP management
messages.

Possible SS7 address/routing information that comprise a Routing Key entry
includes, for example, OPC, DPC, SIO found in the MTP3 routing label, or
other specific fields such as the SCCP subsystem number, or TCAP transaction
ID. Some possibilities include:

	Global Title (+ SSN optionally)
	PC (+ SSN optionally)
	Host Name (+ SSN optionally)
	IP Address(es) (+ SSN optionally)

An Application Server maintains a list of ASPs that are available to process
the traffic.  The list is dynamic, based upon the availability of the
individual ASPs in the list.  SUA ASP management messages are used to convey
the status of these ASPs and their availability in failover situations.

Normally, one or more ASPs areis active in the ASP (i.e., currently
processing traffic) but in certain failure and transition cases it is
possible that there may not be an active ASP available. The SG will buffer
the message destined for this AS for a time T(r) or until an ASP becomes
available. When no ASP becomes available before expiry of t(r), the SG will
flush the buffered messages and initiate the appropriate return or refusal
procedures. 

Both load-sharing and backup scenarios are supported.

If there is no Routing Key match for an incoming SS7 message, a default
treatment MUST be specified.  Possible solutions are to provide a default
Application Server to direct all unallocated traffic to a (set of) default
ASP(s), or to drop the messages and provide a notification to management.
The treatment of unallocated traffic is implementation dependent.

1.5.2 Address Translation and Mapping at the ASP

In order to direct messages to the SS7 network, the ASP must also perform an
address translation and mapping function in order to choose the proper SG or
SGP for a given message.  This is accomplished by observing the Destination
Point Code and other elements of the outgoing message, SS7 network status,
SG and SGP availability, and network appearance configuration tables.

A remote Signaling Gateway may be composed of one or more SGPs.  that are
capable of routing SS7 traffic.  As is the case with ASPs, a dynamic list of
SGPs in an SG can be maintained, taking into account the availability status
of the individual SGPs, configuration changes and fail-over mechanisms.
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.

1.5.3 SCTP Stream Mapping

The SUA supports SCTP streams. The SG/AS needs to maintain a list of SCTP
and SUA-users for mapping purposes.  SCCP-users requiring sequenced message
transfer need to be sent over a stream supporting sequenced delivery.

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

---
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: FW: M3UA Iss7 - Routing Key Overlap
Date: Thu, 10 May 2001 09:36:09 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>FW: M3UA Iss7 - Routing Key Overlap</TITLE> </HEAD>
<BODY>

<P ALIGN=LEFT><FONT COLOR="#000080" SIZE=2 FACE="Arial">Resending - I</FONT>
<FONT COLOR="#000080" SIZE=2 FACE="Arial">sent (and resent)</FONT> <FONT
COLOR="#000080" SIZE=2 FACE="Arial">some</FONT> <FONT COLOR="#000080" SIZE=2
FACE="Arial">e-some mails out</FONT><FONT COLOR="#000080" SIZE=2
FACE="Arial"> yesterday and didn't</FONT> <FONT COLOR="#000080" SIZE=2
FACE="Arial">see anything on the list</FONT><FONT COLOR="#000080" SIZE=2
FACE="Arial">, except for my test e-mail!</FONT><FONT COLOR="#000080" SIZE=2
FACE="Arial">.&nbsp; Perhaps all my mails are being sent to</FONT> <FONT
COLOR="#000080" SIZE=2 FACE="Arial">&quot;</FONT><FONT COLOR="#000080"
SIZE=2 FACE="Arial">my</FONT> <FONT COLOR="#000080" SIZE=2
FACE="Arial">sigtran</FONT> <FONT COLOR="#000080" SIZE=2
FACE="Arial">archive</FONT><FONT COLOR="#000080" SIZE=2
FACE="Arial">&quot;</FONT><FONT COLOR="#000080" SIZE=2 FACE="Arial">
instead</FONT><FONT COLOR="#000080" SIZE=2 FACE="Arial"></FONT> <FONT
COLOR="#000080" SIZE=2 FACE="Arial">&nbsp; 2;^)</FONT></P>

<P ALIGN=LEFT><A NAME="_MailData"><FONT COLOR="#000000" SIZE=2
FACE="Arial"></FONT></A>&nbsp;<FONT COLOR="#000000" SIZE=2
FACE="Arial">-----Original Message-----</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2 FACE="Arial">From:
&nbsp;</FONT> <FONT COLOR="#000000" SIZE=2 FACE="Arial">Sidebottom, Greg
[BCNR:7M01:EXCH]&nbsp; </FONT></B></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT COLOR="#000000" SIZE=2
FACE="Arial">Wednesday, May 09, 2001 11:32 AM</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT COLOR="#000000"
SIZE=2 FACE="Arial">[email-masked]'</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B>
<FONT COLOR="#000000" SIZE=2 FACE="Arial">M3UA Iss7 - Routing Key
Overlap</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2
FACE="Arial">Greetings,</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">An issue was raised
against the current text where we explicitly mention that overlap of Routing
Key information is not allowed.</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">From Section
1.4.2.2:</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp; &quot;</FONT><FONT COLOR="#0000FF" SIZE=2
FACE="Courier New">Routing Keys MUST be unique in the sense that a received
SS7 </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; signalling message cannot be matched to more
than one Routing </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; Key.&quot;</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">And in
4.3.4.1:</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp; &quot;If the SG determines that the Routing Key
parameter overlaps </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; with an existing Routing</FONT> <FONT
COLOR="#0000FF" SIZE=2 FACE="Courier New">Key entry, the SG returns a
</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; Registration Response message to the ASP, with
a Registration </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; Status of &quot;Error - Overlapping
(Non-Unique) Routing Key&quot;.&nbsp; An </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; incoming signalling message received at an SG
cannot match </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; against more than one</FONT><FONT
COLOR="#0000FF" SIZE=2 FACE="Courier New"> Routing Key.&quot;</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">I have heard the
view that there may be some valid cases where a Routing Key overlap is
OK.&nbsp; If so then perhaps we could replace the MUST with a SHOULD in
1.4.2.2.&nbsp; For 4.3.4.1 the last line could be deleted and we could
generalize the error response from &quot;Overlapping (Non-Unique) RK&quot;
to something like &quot;Cannot Support Routing on RK&quot; and change the
text around a bit to reflect that the problem is that the SG can't route if
it allows this RK.</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">So to close on this
- Is there support for this idea?&nbsp; If so, are the above changes
OK?</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Cheers,</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">&nbsp;&nbsp;
Greg</FONT></P> <BR>
<BR>
<BR>
<BR>
<BR>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Greg
Sidebottom</FONT></P>

<P ALIGN=LEFT></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: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: FW: M3UA Iss7 - ASP-Up received when ASP is "active" or "Inactive "
Date: Thu, 10 May 2001 09:36:47 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>FW: M3UA Iss7 - ASP-Up received when ASP is &quot;active&quot; or
&quot;Inactive&quot;</TITLE> </HEAD>
<BODY>

<P ALIGN=LEFT><FONT COLOR="#000080" SIZE=2 FACE="Arial">Resending
...</FONT></P>

<P ALIGN=LEFT><A NAME="_MailData"><FONT COLOR="#000000" SIZE=2
FACE="Arial"></FONT></A>&nbsp;<FONT COLOR="#000000" SIZE=2
FACE="Arial">-----Original Message-----</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2 FACE="Arial">From:
&nbsp;</FONT> <FONT COLOR="#000000" SIZE=2 FACE="Arial">Sidebottom, Greg
[BCNR:7M01:EXCH]&nbsp; </FONT></B></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT COLOR="#000000" SIZE=2
FACE="Arial">Wednesday, May 09, 2001 10:20 AM</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT COLOR="#000000"
SIZE=2 FACE="Arial">[email-masked]'</FONT></P>

<P ALIGN=LEFT><B><FONT COLOR="#000000" SIZE=2
FACE="Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B>
<FONT COLOR="#000000" SIZE=2 FACE="Arial">M3UA Iss7 - ASP-Up received when
ASP is &quot;active&quot; or &quot;Inactive&quot;</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Hi,</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">I'm getting close to
finishing off Iss7.&nbsp; I meant to close this open issue but forgot -
thanks to Ken for reminding me.</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Per
4.3.3.1:</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp; &quot;If an ASP-Up is received and internally the
remote ASP </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; is in the &quot;Active&quot; or
&quot;Standby&quot; state, an Error </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; (&quot;Unexpected Message) is returned and the
remote ASP </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; state is not changed.</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT COLOR="#0000FF" SIZE=2
FACE="Courier New">If an ASP-Up is received and internally the remote ASP
</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; is already in the &quot;Inactive&quot; state,
and ASP-Up Ack is </FONT></P>

<P ALIGN=LEFT><FONT COLOR="#0000FF" SIZE=2 FACE="Courier
New">&nbsp;&nbsp;&nbsp;&nbsp; returned and no action is
taken.&quot;</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">&nbsp;</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Now there was
discussion at the IETF meeting as to whether an ASP-Up in this case could
actually be a kind of reset by the ASP.&nbsp; If so, that would mean that
the SG should change the state of the ASP to &quot;inactive&quot; and send
an ASP-UP Ack.&nbsp; I guess the answer depends on how people think the ASPs
will behave - i.e. are there valid cases, other than a software error, where
an ASP would send an ASP-Up after going &quot;active&quot; or
&quot;standby&quot;?</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">We need to close on
this issue - any support for changing this behavior?</FONT></P>

<P ALIGN=LEFT><FONT COLOR="#000000" SIZE=2 FACE="Arial">Greg
Sidebottom</FONT></P>

<P ALIGN=LEFT></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: Thu, 10 May 2001 17:30:45 +0200 (MEST)
From: ecejoz <[email-masked]>
Reply-To: [email-masked]
Subject: Interim report
To: "sigtran" <[email-masked]>
Cc: [email-masked], 
    "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi all from Madrid!

This is the second report from the M3UA Interop Test.

We are now testing the 3rd configuration of the Test Plan.

We have finished sucessfuly the 1st and 2nd configurations.

Several issues have been found, documented and disscused with Greg.

A list of these will be included in the final report of the Interop Test.

This will be sent by tomorrow.

By the way, no real interoperability problems were found with the SCTP
implementations used at this Interop Test.

  Best Regards
  
  /Interop Coordination Team
  
  	- Barry Nagelberg
  	- Kurt Kite
  	- Jaime Olivares
  	- Heinz Prantner
  	- Michael Tuexen

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Mark Kobine <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA: Draft 7 typos
Date: Thu, 10 May 2001 17:06:33 +0100
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: blueyonder.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pcow028o.blueyonder.co.uk [195.188.53.124]
List-Unsubscribe: <mailto:[email-masked]>

Apologies if these have already been spotted and apologies in advance for my
pedantry :-)

1) The reference in section 1.6.3 should be to section 10 of [5] not section
9.

2) In section 1.6.4 M-ASP-UP confirm primitive the Purpose: should read "ASP
reports that it has" not "ASP reports that is has".

3) Section 3.3.1.3 first line of last paragraph. Should be "(Normal or
Emergency)" not "(Normal of Emergency)". In that same paragraph the cross
reference should be to section 3.3.1.5 not 3.3.1.4.

4) Section 3.3.3.1 in the paragraph starting "The Invalid Stream
Identifier".
There are 2 "i.e."s in this sentence and a stray ")." at the end.

5) Section 3.3.3.2 first sentence. This should read "The Notify message is
used". The "is" has been omitted.

6) The same section talks about "Status Identification" and "Status
Information"
parameters. Were these supposed to be one and the same?

7) Section 4.0. The first sentence should start "The M2UA layer" not "The
M2UA
layers".

8) In section 4.1.1 the cross reference is to section 2 - Conventions. I
don't
think this was the intention?

9) Section 4.3.1 first paragraph. Should the "AS" here actually be "ASP"?
Also, should the "it" in that same sentence be removed?

10) Section 4.3.1.1 penultimate paragraph. Should the "and" in the final
sentence be "or"?

Cheers,
Mark

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Joe Pakrasi <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: Any suggestion on SS7 stack?
Date: Thu, 10 May 2001 12:22:18 -0400
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-SMTP-HELO: cerberus.intellinet-tech.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: cerberus.intellinet-tech.com [208.200.170.3]
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.4522.1800" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=170123614-10052001>Hello Patrick,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=170123614-10052001></SPAN></FONT>&nbsp;</DIV> <DIV><FONT
color=#0000ff><FONT size=2><FONT face=Arial><SPAN
class=170123614-10052001>IntelliNet Technologies has recently completed an
upgrade to our SS7 Application Development Platform.&nbsp; This is an
excellent tool for&nbsp;a&nbsp;high quality and quick development
effort.&nbsp; It is offered in a complete HW and SW package and in a
redundant configuration to provide you with the high reliability that you
require.&nbsp; Please contact our sales department at 321-726-0686 or
respond to me directly at <A
href="mailto:[email-masked]">mailto:j.pakrasi@intellinet-tech
.com</A></SPAN><SPAN class=170123614-10052001>.&nbsp;
</SPAN></FONT></FONT></FONT></DIV> <DIV><FONT color=#0000ff><FONT
size=2><FONT face=Arial><SPAN
class=170123614-10052001></SPAN></FONT></FONT></FONT>&nbsp;</DIV> <DIV><FONT
color=#0000ff><FONT size=2><FONT face=Arial><SPAN
class=170123614-10052001>Thank you,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff><FONT size=2><FONT face=Arial><SPAN
class=170123614-10052001>-
Joe</SPAN></FONT></FONT></FONT></DIV></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]">Patrick Lam</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, May 09, 2001 2:38 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Any suggestion on SS7 
  stack?</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=Arial size=2>Hi all:</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Just wondering if anyone has any suggestion
on 
  the commercial SS7 stacks out there?&nbsp; I am looking for something that
has 
  high reliability (and hopefully performance as well, but reliability is
more 
  important).</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Thanks very much in advance,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Patrick.</FONT></DIV>---<BR>You are currently

  subscribed to sigtran as: <A 
 
href="mailto:[email-masked]">[email-masked]</A
><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>
To: "sigtran" <[email-masked]>
Date: Thu, 10 May 2001 09:52:40 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Mailer: MailCity Service
Subject: Re: Any suggestion on SS7 stack?
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Pretty soon I'm going to start charging for the use of this mailing list for
product advertising :o)

Seriously, I've asked before and ask again for people to keep this traffic
off the list.  It belongs someplace else, like maybe the Softswitch
Consortium.

Thanks,

L. Ong 

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Lotus-FromDomain: TEKELEC
From: Joe Keller <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Thu, 10 May 2001 12:56:20 -0400
Subject: Re: FW: M3UA Iss7 - Routing Key Overlap
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: domino2.nc.tekelec.com [198.89.40.41]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

    Can you clarify the valid cases for allowing overlapped routing key?
We may need to add text to what you have already proposed.

Thanks,
Joe

"Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]> on
05/10/2001 09:36:09 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Joe
Keller/Raleigh/TEKELEC) Subject:  FW: M3UA Iss7 - Routing Key Overlap

Resending - I sent (and resent) some e-some mails out yesterday and didn't
see anything on the list, except for my test e-mail!.  Perhaps all my mails
are being sent to "my sigtran archive" instead   2;^)

 -----Original Message-----
From:     Sidebottom, Greg [BCNR:7M01:EXCH] Sent:     Wednesday, May 09,
2001 11:32 AM To:  [email-masked]' Subject:  M3UA
Iss7 - Routing Key Overlap

Greetings,

An issue was raised against the current text where we explicitly mention
that overlap of Routing Key information is not allowed.

From Section 1.4.2.2:

    "Routing Keys MUST be unique in the sense that a received SS7
     signalling message cannot be matched to more than one Routing
     Key."

And in 4.3.4.1:

    "If the SG determines that the Routing Key parameter overlaps
     with an existing Routing Key entry, the SG returns a
     Registration Response message to the ASP, with a Registration
     Status of "Error - Overlapping (Non-Unique) Routing Key".  An
     incoming signalling message received at an SG cannot match
     against more than one Routing Key."

I have heard the view that there may be some valid cases where a Routing Key
overlap is OK.  If so then perhaps we could replace the MUST with a SHOULD
in 1.4.2.2.  For 4.3.4.1 the last line could be deleted and we could
generalize the error response from "Overlapping (Non-Unique) RK" to
something like "Cannot Support Routing on RK" and change the text around a
bit to reflect that the problem is that the SG can't route if it allows this
RK.

So to close on this - Is there support for this idea?  If so, are the above
changes OK?

Cheers,

   Greg

Greg Sidebottom

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

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\att11.htm" ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Thu, 10 May 2001 14:20:48 -0500
From: Randall Stewart <[email-masked]>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)
X-SMTP-HELO: sj-msg-core-2.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: sj-msg-core-2.cisco.com [171.69.24.11]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Randall Stewart wrote:
> 
> Qiaobing Xie wrote:
> >
> > Randy/Jim:
> >
> > Interesting discussion... But I have to admit it is still not quite
> > clear to me how we should deal with the link-locals. Let's see an
> > example:
> >
> > A dentist who bought a pair of IPv6 machines wants to add a little
> > redundancy to his office networking, he decides to put two interface
> > cards to each of the machines and connects them with two separate sets
> > of cables and then boots machines up. Now he starts an SCTP-based
> > application on one of the machine to communicate with the other
> > machine... The question is: will the SCTP be able to give him the
> > networking redundancy he's been hoping for?
> >
> > regards,
> > -Qiaobing
> 
No and having waded into this swamp and coded the IPv6 ref-impl I will
attempt
to explain why:
 
1) A link local address is only valid on a single interface.
2) A link local address is unique ONLY on a interface 3) When you send to a
Link Local address you specify the interface via
   the sin6_scope_id.
4) If you do otherwise (there are some implementations that just look in
   there neighbor cache to figure out which one to send to but this is
WRONG),
   you cannot send the packet... you will get a unreachable error..
unless
   you have a scope id.
5) If you atempt to do what some bad implementations do (a O/S I deplor
   I am told) then you have a distinct possibility that the same
   Link-Local address exists for two different peers.

Now this all may seem a bit vague but consider...

If I list a Link-Local address in a SCTP parameter, how do you have any idea
which interface it goes to... And even if we had a field for it, there is no
way the sender of the SCTP chunk can know what scope_id has been assigned to
the interface he is sending to on the peer... 

It just DOES NOT WORK!!
 
So for our dentist friend, if he wants multi-homing, he will have to buy a
router (hopefully a cisco one :-/... but even a freeBSD machine can do
here.. though I may hate to admit it :->) and set it up to advertise site 
local subnets.
 
Then he can INIT destined to a link local or site local and his peer will
add the link-local (since it is a from address) and add all of the
site-local addresses gaining our dentist friend his multi-homing..

There is just NO WAY you can make two lans redundant with no routers in IPv6
using link-local addresses..this statement is made from having implemented
the link local junk...

Now here are the basic rules I have devised for the BIS ..
****Jim please take a close look at these and either educate me or critic
them :/

 "
 5.1.2.1 Special rules for IPv6 address scoping  
     When selecting IPv6 addresses to include as parameters in the INIT
     chunk the following rules MUST be applied:  
     A1) The INIT chunk MUST NOT include any IPv6 Link Local
         address parameters.
 
     A2) An IPv6 Link Local address MAY be used has a destination
         address for an SCTP packet containing an INIT chunk.
 
     A3) If the destination address of the INIT is a Site-Local or
         Link Local address, then both Site-Local and Global IPv6
         address parameters SHOULD be included in the INIT chunk.
 
     A4) If the destination address of the INIT is an IPv6 Global
         address then the sender MUST NOT include any Site-Local
         IPv6 address parameters in the INIT chunk.
 
     A6) If the destination address of the INIT is an IPv4 Address
         then the sender MUST NOT include any Site-Local IPV6
         address parameters in the INIT chunk.
 
     When responding to an INIT chunk and selecting IPv6 address
     parameters to be included in the INIT-ACK chunk, the following rules
     MUST be applied:
 
     B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local
         address parameters.
 
     B2) If the source address of the SCTP packet containing the INIT
         chunk is a IPv6 Link-Local address, then both Site-Local and
         Global IPv6 address parameters SHOULD be included in the
         INIT-ACK chunk.
 
     B3) If the source address of the SCTP packet containing the INIT
         chunk is an IPv6 Site-Local address, then both Site-Local
         and Global IPv6 address parameters SHOULD be included in
         the INIT-ACK chunk.
 
     B4) If the source address of the SCTP packet containing the INIT
         chunk is an IPv6 Global address, then the sender MUST NOT
         include any Site-Local IPv6 address parameters in the
         INIT-ACK chunk.
 
     B5) If the source address of the SCTP packet containing the INIT
         chunk is an IPv4 address, then the sender MUST NOT
         include any Site-Local IPv6 address parameters in the
         INIT-ACK chunk.
 
 "
 
-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Thu, 10 May 2001 20:41:07 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate2.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate2.mot.com [136.182.1.10]
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 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.19">
<TITLE>RE: SUA5: Address Mapping text</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>It is still not clear to me that how address translation and
mapping is done in an all ip environment.&nbsp; I am not sure if you intend
to cover this under this section.&nbsp; Meanwhile, please see my other
comments inserted below.</FONT></P>

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

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: [email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>&gt; Sent: Thursday, May 10, 2001 3:17 AM</FONT>
<BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject:
SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi all, </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There has been some discussion as of late on SUA / GTT
/ ENUM </FONT> <BR><FONT SIZE=2>&gt; / etc.&nbsp; I have</FONT> <BR><FONT
SIZE=2>&gt; updated the text.&nbsp; Please comment.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; br,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5 Internal Functions Provided in the SUA Layer
</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is assumed that Global Title Translation (GTT)
occurs </FONT> <BR><FONT SIZE=2>&gt; outside of SUA.</FONT> <BR><FONT
SIZE=2>&gt; However, SUA will need to map the output of the GTT process,
when</FONT> <BR><FONT SIZE=2>&gt; applicable, to an ASP via an Address
Mapping Function (AMF).&nbsp; </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; When SS7 addressing is used by the upper layer
protocol, SUA </FONT> <BR><FONT SIZE=2>&gt; will need to</FONT> <BR><FONT
SIZE=2>&gt; determine the correct signaling endpoint.&nbsp; How this is done
is</FONT> <BR><FONT SIZE=2>&gt; implementation specific, but it could
involve DNS [ENUM] or local</FONT> <BR><FONT SIZE=2>&gt; configuration
information.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>[MYH] ==&gt; &quot;DNS [ENUM] and/or local configuration
information.&quot;</FONT> </P>

<P><FONT SIZE=2>&gt; 1.5.1 Address Translation and Mapping at the SG</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The SG MUST provide address translation and mapping
functions </FONT> <BR><FONT SIZE=2>&gt; to direct</FONT>
<BR><FONT SIZE=2>&gt; messages received from the SS7 network to the
appropriate IP </FONT> <BR><FONT SIZE=2>&gt; destination.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In order to support message distribution, the SG
maintains an address</FONT> <BR><FONT SIZE=2>&gt; translation table, which
maps the incoming SS7 messages to </FONT> <BR><FONT SIZE=2>&gt; the
appropriate</FONT> <BR><FONT SIZE=2>&gt; AS.&nbsp; The relevant fields of
the incoming SS7 message is </FONT> <BR><FONT SIZE=2>&gt; compared to
the</FONT> <BR><FONT SIZE=2>&gt; existing Routing Keys.&nbsp; The Routing
Keys reference an </FONT> <BR><FONT SIZE=2>&gt; Application Server,</FONT>
<BR><FONT SIZE=2>&gt; which will have one or more ASPs processing traffic
for the AS.&nbsp; The</FONT> <BR><FONT SIZE=2>&gt; availability and status
of the ASPs is handled by SUA ASP management</FONT> <BR><FONT SIZE=2>&gt;
messages.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Possible SS7 address/routing information that comprise
</FONT> <BR><FONT SIZE=2>&gt; a Routing Key entry includes, for example,
OPC, DPC, SIO found in </FONT> <BR><FONT SIZE=2>&gt; the MTP3 routing label,
or other specific fields such as the </FONT> <BR><FONT SIZE=2>&gt; SCCP
subsystem number, or TCAP transaction ID. Some </FONT> <BR><FONT SIZE=2>&gt;
possibilities include:</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Global Title (+ SSN
optionally)</FONT> <BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PC
(+ SSN optionally)</FONT> <BR><FONT SIZE=2>&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Host Name (+ SSN optionally)</FONT> <BR><FONT
SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP Address(es) (+ SSN
optionally)</FONT> </P>

<P><FONT SIZE=2>[MYH] My understanding is that in case of IP address the SSN
should be mandatory to identify the correct SSN.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; An Application Server maintains a list of ASPs that
are </FONT> <BR><FONT SIZE=2>&gt; available to process</FONT> <BR><FONT
SIZE=2>&gt; the traffic.&nbsp; The list is dynamic, based upon the
availability of the</FONT> <BR><FONT SIZE=2>&gt; individual ASPs in the
list.&nbsp; SUA ASP management messages are </FONT> <BR><FONT SIZE=2>&gt;
used to convey</FONT> <BR><FONT SIZE=2>&gt; the status of these ASPs and
their availability in failover </FONT> <BR><FONT SIZE=2>&gt;
situations.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Normally, one or more ASPs areis active in the ASP
(i.e., currently</FONT> </P>

<P><FONT SIZE=2>[MYH] Typo here, &quot;areis&quot; --&gt; &quot;are&quot;;
the second ASP should be &quot;AS&quot;</FONT> </P>

<P><FONT SIZE=2>&gt; processing traffic) but in certain failure and
transition cases it is</FONT> <BR><FONT SIZE=2>&gt; possible that there may
not be an active ASP available. The </FONT> <BR><FONT SIZE=2>&gt; SG will
buffer</FONT> <BR><FONT SIZE=2>&gt; the message destined for this AS for a
time T(r) or until an </FONT> <BR><FONT SIZE=2>&gt; ASP becomes</FONT>
<BR><FONT SIZE=2>&gt; available. When no ASP becomes available before expiry
of </FONT> <BR><FONT SIZE=2>&gt; t(r), the SG will</FONT> <BR><FONT
SIZE=2>&gt; flush the buffered messages and initiate the appropriate </FONT>
<BR><FONT SIZE=2>&gt; return or refusal</FONT> <BR><FONT SIZE=2>&gt;
procedures. </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Both load-sharing and backup scenarios are
supported.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If there is no Routing Key match for an incoming SS7
message, </FONT> <BR><FONT SIZE=2>&gt; a default</FONT>
<BR><FONT SIZE=2>&gt; treatment MUST be specified.&nbsp; Possible solutions
are to </FONT> <BR><FONT SIZE=2>&gt; provide a default</FONT> <BR><FONT
SIZE=2>&gt; Application Server to direct all unallocated traffic to a
</FONT> <BR><FONT SIZE=2>&gt; (set of) default</FONT> <BR><FONT SIZE=2>&gt;
ASP(s), or to drop the messages and provide a notification to </FONT>
<BR><FONT SIZE=2>&gt; management.</FONT> <BR><FONT SIZE=2>&gt; The treatment
of unallocated traffic is implementation dependent.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5.2 Address Translation and Mapping at the
ASP</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In order to direct messages to the SS7 network, the
ASP must </FONT> <BR><FONT SIZE=2>&gt; also perform an</FONT> <BR><FONT
SIZE=2>&gt; address translation and mapping function in order to choose
</FONT> <BR><FONT SIZE=2>&gt; the proper SG or</FONT> <BR><FONT SIZE=2>&gt;
SGP for a given message.&nbsp; This is accomplished by observing </FONT>
<BR><FONT SIZE=2>&gt; the Destination</FONT> <BR><FONT SIZE=2>&gt; Point
Code and other elements of the outgoing message, SS7 </FONT> <BR><FONT
SIZE=2>&gt; network status,</FONT> <BR><FONT SIZE=2>&gt; SG and SGP
availability, and network appearance configuration tables.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A remote Signaling Gateway may be composed of one or
more </FONT> <BR><FONT SIZE=2>&gt; SGPs.&nbsp; that are</FONT> <BR><FONT
SIZE=2>&gt; capable of routing SS7 traffic.&nbsp; As is the case with ASPs,
a </FONT> <BR><FONT SIZE=2>&gt; dynamic list of</FONT> <BR><FONT SIZE=2>&gt;
SGPs in an SG can be maintained, taking into account the </FONT> <BR><FONT
SIZE=2>&gt; availability status</FONT> <BR><FONT SIZE=2>&gt; of the
individual SGPs, configuration changes and fail-over </FONT> <BR><FONT
SIZE=2>&gt; mechanisms.</FONT> <BR><FONT SIZE=2>&gt; There is, however, no
SUA messaging to manage the status of </FONT> <BR><FONT SIZE=2>&gt; an SGP.
Whenever</FONT> <BR><FONT SIZE=2>&gt; an SCTP association to an SGP exists,
it is assumed to be </FONT> <BR><FONT SIZE=2>&gt; available.&nbsp;
Also,</FONT> <BR><FONT SIZE=2>&gt; every SGP of one SG communicating with
one ASP regarding one </FONT> <BR><FONT SIZE=2>&gt; AS provides</FONT>
<BR><FONT SIZE=2>&gt; identical SS7 connectivity to this ASP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5.3 SCTP Stream Mapping</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; The SUA supports SCTP streams. The SG/AS needs to
maintain a </FONT> <BR><FONT SIZE=2>&gt; list of SCTP</FONT> <BR><FONT
SIZE=2>&gt; and SUA-users for mapping purposes.&nbsp; SCCP-users requiring
</FONT> <BR><FONT SIZE=2>&gt; sequenced message</FONT> <BR><FONT SIZE=2>&gt;
transfer need to be sent over a stream supporting sequenced delivery.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; SUA MUST use stream 0 for SUA management messages. It
is </FONT> <BR><FONT SIZE=2>&gt; recommended that</FONT> <BR><FONT
SIZE=2>&gt; sequenced delivery is usedbe in order to preserve the order
</FONT> <BR><FONT SIZE=2>&gt; of management</FONT> <BR><FONT SIZE=2>&gt;
message delivery.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SG/SUA
Date: Thu, 10 May 2001 20:46:48 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate2.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate2.mot.com [136.182.1.10]
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 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.19">
<TITLE>RE: SG/SUA</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>Are you intend to cover this architecture in next SUA
release?</FONT> </P>

<P><FONT SIZE=2>BTW, I don't in favor of the word &quot;SG&quot; to be used
in this scenario.&nbsp; This case is more like the standard SCCP message
relay function provided by SCCP layer, and this mechanism is also available
in SUA layer.&nbsp; Why not call it an &quot;Relay Client&quot;?</FONT></P>

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

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: [email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>&gt; Sent: Thursday, May 10, 2001 2:59 AM</FONT>
<BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: RE:
SG/SUA</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Srini,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Is there anything in the SUA draft that precludes
to use SG </FONT> <BR><FONT SIZE=2>&gt; &gt; to connect two SUA nodes
(ASP-SGP-ASP). What I mean is when SG </FONT> <BR><FONT SIZE=2>&gt; &gt;
gets a SUA message with</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; - Route On GT : GT + SSN</FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; After perform the
address mapping (GTT like service) can </FONT> <BR><FONT SIZE=2>&gt; the
result be</FONT> <BR><FONT SIZE=2>&gt; &gt; another IP node.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Catching up on a backlog of messages.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This is &quot;possible&quot; but for now, it is
outside the scope of the current</FONT> <BR><FONT SIZE=2>&gt; SUA
draft.&nbsp; Let's say that there is nothing preventing this,</FONT>
<BR><FONT SIZE=2>&gt; but it isn't part of the architecture that is
currently supported.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; br,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: 'Young Michael-Y10724' <[email-masked]>, 
    "[email-masked]'" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 12:10:41 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Some comments below.
BTW: relaying client is fine with me. However someone will be bound to ask
what or where the relaying server is located. But now I am word smithing.
:-)
 
And with all that IPv6 scoping stuff going around, we'll have a lot of fun
figuring all that out.
 
yours sincerly,
Lode

Siemens Atea ICN D CS D 
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium Tel +32-14-25-2081   /  Fax +32-14-25-3212
E-mail:   [email-masked] 

-----Original Message-----
From: Young Michael-Y10724 [mailto:[email-masked]] Sent: vrijdag
11 mei 2001 2:41
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hi John, 

It is still not clear to me that how address translation and mapping is done
in an all ip environment.  I am not sure if you intend to cover this under
this section.  Meanwhile, please see my other comments inserted below.

BR, 

Michael Young 
--------------------------------------------------------------- System
Design, GTSS Vancouver, Motorola Tel: +1 (604)241-6032   Cel: +1
(604)726-6609 Email: [email-masked] 
--------------------------------------------------------------- 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, May 10, 2001 3:17 AM 
> To: sigtran 
> Subject: SUA5: Address Mapping text 
> 
> 
> Hi all, 
> 
> There has been some discussion as of late on SUA / GTT / ENUM 
> / etc.  I have 
> updated the text.  Please comment. 
> 
> br, 
> John 
> 
> 1.5 Internal Functions Provided in the SUA Layer 
> 
> It is assumed that Global Title Translation (GTT) occurs 
> outside of SUA. 

Suggestion for text:

If Global Titles are supported, then the Global Title Translation(GTT)
function needs to be supported by SUA. In the broadest sense, the GTT
function translates a GT to another GT + a IP address + optional a SSN. The
way in which this GTT function is performed is implementation dependant but
it could involve access to a remote database(examples DNS(ENUM), LDAP, ....)
and/or acces to a locally configured/engineerd database. 

How to enforce the consistency of the database(s) within the network is
outside the scope of the document, but the database must be configured so
that a response msg from the destination/termination/Called party sua node
can be send back to and received by the source/origination/Calling party sua
node.

Note: this is fairly obvious in a IP network(but in IP this  condition is
enforced by BGP or OSPF routing protocols), but in network based on GTT that
condition must be up till now enforced by carefully configuring your network
and agreements with other networks.

> However, SUA will need to map the output of the GTT process, when 
> applicable, to an ASP via an Address Mapping Function (AMF).  
> 
> When SS7 addressing is used by the upper layer protocol, SUA 
> will need to 
> determine the correct signaling endpoint.  How this is done is 
> implementation specific, but it could involve DNS [ENUM] or local 
> configuration information.  

SS7 addressing is a little vague here: is GT meant or is SS7 pointcodes
meant. In case of GT, yes remote or local databases should be used. In case
of real SS7 pointcodes, then I think only local databases will help you out,
besides it looks a little weird, having a extra indirection.  
[MYH] ==> "DNS [ENUM] and/or local configuration information." 

> 1.5.1 Address Translation and Mapping at the SG 
> 
> The SG MUST provide address translation and mapping functions 
> to direct 
> messages received from the SS7 network to the appropriate IP 
> destination. 
> 
> In order to support message distribution, the SG maintains an address 
> translation table, which maps the incoming SS7 messages to 
> the appropriate 
> AS.  The relevant fields of the incoming SS7 message is 
> compared to the 
> existing Routing Keys.  The Routing Keys reference an 
> Application Server, 
> which will have one or more ASPs processing traffic for the AS.  The 
> availability and status of the ASPs is handled by SUA ASP management 
> messages. 
> 
> Possible SS7 address/routing information that comprise 
> a Routing Key entry includes, for example, OPC, DPC, SIO found in 
> the MTP3 routing label, or other specific fields such as the 
> SCCP subsystem number, or TCAP transaction ID. Some 
> possibilities include: 
> 
>       Global Title (+ SSN optionally) 
>       PC (+ SSN optionally) 
>       Host Name (+ SSN optionally) 
>       IP Address(es) (+ SSN optionally) 

[MYH] My understanding is that in case of IP address the SSN should be
mandatory to identify the correct SSN.  

Depends whether the messages only contains the IP address or more addressing
info. If only the IP address is present in the message, then indeed the  ssn
must be present.

> 
> An Application Server maintains a list of ASPs that are 
> available to process 
> the traffic.  The list is dynamic, based upon the availability of the 
> individual ASPs in the list.  SUA ASP management messages are 
> used to convey 
> the status of these ASPs and their availability in failover 
> situations. 
> 
> Normally, one or more ASPs areis active in the ASP (i.e., currently 

[MYH] Typo here, "areis" --> "are"; the second ASP should be "AS" 

> processing traffic) but in certain failure and transition cases it is 
> possible that there may not be an active ASP available. The 
> SG will buffer 
> the message destined for this AS for a time T(r) or until an 
> ASP becomes 
> available. When no ASP becomes available before expiry of 
> t(r), the SG will 
> flush the buffered messages and initiate the appropriate 
> return or refusal 
> procedures. 
> 
> Both load-sharing and backup scenarios are supported. 
> 
> If there is no Routing Key match for an incoming SS7 message, 
> a default 
> treatment MUST be specified.  Possible solutions are to 
> provide a default 
> Application Server to direct all unallocated traffic to a 
> (set of) default 
> ASP(s), or to drop the messages and provide a notification to 
> management. 
> The treatment of unallocated traffic is implementation dependent. 
> 
> 1.5.2 Address Translation and Mapping at the ASP 
> 
> In order to direct messages to the SS7 network, the ASP must 
> also perform an 
> address translation and mapping function in order to choose 
> the proper SG or 
> SGP for a given message.  This is accomplished by observing 
> the Destination 
> Point Code and other elements of the outgoing message, SS7 
> network status, 
> SG and SGP availability, and network appearance configuration tables. 
> 
> A remote Signaling Gateway may be composed of one or more 
> SGPs.  that are 
> capable of routing SS7 traffic.  As is the case with ASPs, a 
> dynamic list of 
> SGPs in an SG can be maintained, taking into account the 
> availability status 
> of the individual SGPs, configuration changes and fail-over 
> mechanisms. 
> 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. 
> 
> 1.5.3 SCTP Stream Mapping 
> 
> The SUA supports SCTP streams. The SG/AS needs to maintain a 
> list of SCTP 
> and SUA-users for mapping purposes.  SCCP-users requiring 
> sequenced message 
> transfer need to be sent over a stream supporting sequenced delivery. 
> 
> SUA MUST use stream 0 for SUA management messages. It is 
> recommended that 
> sequenced delivery is usedbe in order to preserve the order 
> of management 
> message delivery. 
> 
>  

For the rest, no other comments.

> --- 
> 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: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 13:28:07 +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 Lode,

Some comments:

> 
> Suggestion for text:
> 
> If Global Titles are supported, then the Global Title Translation(GTT)
> function needs to be supported by SUA. In the broadest sense, the GTT
> function translates a GT to another GT + a IP address + 
> optional a SSN. The way in which this GTT function is performed is 
> implementation dependant but it could involve access to a remote database
> (examples DNS(ENUM), LDAP, ....) and/or acces to a locally
configured/engineerd 
> database. 

One problem with this is that in the signaling gateway, where is the GTT
performed?  Is it once at the SCCP layer; is it twice (SCCP layer and SUA
layer) or do we consider an implementation specific view that GTT is located
at the NIF and can be called by both SCCP and SUA and does some magic?

I'd suggest removing the GTT part of your paragraph and call it 'Address
Mapping Function' and maybe adding a note that within an SG, the GTT
function and Address Mapping Function can be combined in a implementation
spefic way (which is outside of the scope of this document).

> How to enforce the consistency of the database(s) within the 
> network is outside the scope of the document, but the database 
> must be configured so that a response msg from the destination/
> termination/Called party sua node can be send back to and received 
> by the  source/origination/Calling party sua node.
> 
> Note: this is fairly obvious in a IP network(but in IP this  
> condition is enforced by BGP or OSPF routing protocols), but in network 
> based on GTT that condition must be up till now enforced by carefully 
> configuring your network and agreements with other networks.

Agreed.

> > However, SUA will need to map the output of the GTT process, when 
> > applicable, to an ASP via an Address Mapping Function (AMF).  
> > 
> > When SS7 addressing is used by the upper layer protocol, SUA 
> > will need to 
> > determine the correct signaling endpoint.  How this is done is 
> > implementation specific, but it could involve DNS [ENUM] or local 
> > configuration information.  
> 
> SS7 addressing is a little vague here: is GT meant or is SS7 
> pointcodes meant. In case of GT, yes remote or local databases 
> should be used. In case of real SS7 pointcodes, then I think only 
> local databases will help you out, besides it looks a little weird, 
> having a extra indirection.  

We did a little implementation with SUA last summer with an SQL database
doing the address mapping.  This database was an example of what I meant.
The database could be located in a centralized place for one operator (or
replicated) and all of the SS7 addresses (GTs, Point Codes, SSNs) could be
located there along with all of the IP addresses & host names ...

> 
> [MYH] My understanding is that in case of IP address the SSN should be
> mandatory to identify the correct SSN.  
> 
> Depends whether the messages only contains the IP address or 
> more addressing info. If only the IP address is present in the 
> message, then indeed the  ssn must be present.

agreed.

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: SG/SUA
Date: Fri, 11 May 2001 13:36:41 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x4.nokia.com [131.228.20.27]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Micheal,
 
Are you intend to cover this architecture in next SUA release? 
[<JAL> ] I have some reservations about this.  I am not so sure that this is
something that would be so good to standardize within the IETF.  This
functionality is very close to an application-layer gateway (ALG) for SCTP,
using SS7 addressing.  On the other hand, DIAMETER is using proxies which
behave in a very similar manner.  However, the IESG is coming down very hard
on proxies since it breakes the end-to-end model and wreck havoc with
security protocols. I don't mind leaving hooks in the protocol so it can be
done, but I'm not sure that I want to standarize it.  Anyhow, I'd prefer to
get SUA done & into an RFC.  If we need to address such functionality, it
could be done in a follow on draft.
 
Does anyone feel strongly about this? 
 
In short, we are talking about ASP to ASP communication via a 3rd ASP which
acts as a relay between the 2 ASPs.  
 
John 

BTW, I don't in favor of the word "SG" to be used in this scenario.  This
case is more like the standard SCCP message relay function provided by SCCP
layer, and this mechanism is also available in SUA layer.  Why not call it
an "Relay Client"?

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Mark Kobine <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA: Draft 7 - Relationship between SG/AS/ASP/MGC
Date: Fri, 11 May 2001 12:10:43 +0100
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: blueyonder.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pcow024o.blueyonder.co.uk [195.188.53.126]
List-Unsubscribe: <mailto:[email-masked]>

Hi,

I need some clarification of the relationships between the various entities.

1) How many ACTIVE ASP's can there be per AS?

Although section 1.3.4 (2nd para) clearly states that "One or more ASP's in
the list are normally active" there are several statements in the spec that
suggest otherwise. These are:

- Section 1.3.4 last para. The use of a 1 + k redundancy model suggests 1
active ASP and k inactive ASP's.

- Section 1.5.2 second para, second sentence "... which ASP is currently
active." The use of the singular suggests only 1 ASP can be active.

- Section 4.3.3.4 last para. This suggests that only 1 ASP can be active per
AS.

2) How many AS's can there be per SG?

There are a number of statement in the spec that suggest that there may be
more than 1 AS per SG. These are:

- Section 4.3.3.2 first para. This paragraph talks about sending a single
ASP Down message to a single SG to remove the ASP from all AS's of which it
is a member. This suggests that there can be more than one AS per SG and
perhaps more alarmingly that they share a single SCTP association!

- Section 4.3.3.4 first para. This states that a ASP can be registered to
more than one AS but share a SCTP association. Thereby implying multiple
AS's on a single SG.

3) How many ASP's per MGC can there be?

On the basis of the ambiguity outlined in 1) and 2) I'd like to know how
many ASP's per MGC there can be?

Whatever the answers to the above the spec would benefit from a couple of
unambiguous statements to clarify 2) and 3).

Cheers,
Mark

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SG/SUA
Date: Fri, 11 May 2001 13:35:55 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: vrijdag 11 mei 2001 12:37
> To: sigtran
> Subject: RE: SG/SUA
> 
> 
> Hi Micheal,
>  
> Are you intend to cover this architecture in next SUA release? 
> [<JAL> ] I have some reservations about this.  I am not so 
> sure that this is
> something that would be so good to standardize within the IETF.  This
> functionality is very close to an application-layer gateway 
> (ALG) for SCTP,
> using SS7 addressing.  On the other hand, DIAMETER is using 
> proxies which
> behave in a very similar manner.  However, the IESG is coming 
> down very hard
> on proxies since it breakes the end-to-end model and wreck havoc with
> security protocols. I don't mind leaving hooks in the 
> protocol so it can be
> done, but I'm not sure that I want to standarize it.  Anyhow, 
> I'd prefer to
> get SUA done & into an RFC.  If we need to address such 
> functionality, it
> could be done in a follow on draft.

fine with me.
>  
> Does anyone feel strongly about this? 

I don't...
>  
> In short, we are talking about ASP to ASP communication via a 
> 3rd ASP which
> acts as a relay between the 2 ASPs.  
>  
> John 
> 
> BTW, I don't in favor of the word "SG" to be used in this 
> scenario.  This
> case is more like the standard SCCP message relay function 
> provided by SCCP
> layer, and this mechanism is also available in SUA layer.  
> Why not call it
> an "Relay Client"?
> 
No problem.

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium Tel +32-14-25-2081   /  Fax +32-14-25-3212
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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, 
    [email-masked], [email-masked]
Subject: RE: TR29.903 SUA Feasibility Study
Date: Fri, 11 May 2001 13:51:37 +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]

Hello Thomas,

The SCCP procedures describing GTT assume that the database is integrated.
For SUA, the AMF (Address Mapping Function) is there to model the integrated
database, without any restriction on access methods used by SUA internally
to perform its relay functions. As such, the AMF replaces the GTT in the
SCCP recommendations.

The term out-of-scope is too strong : relay functionality and support of GTT
(or hostname translation for that matter) is indeed IN the scope of SUA.
What we don't want to do is describe how this support is realized, but only
:

- valid input/output to/from this AMF (based on the rules in Q.714 for SCCP)
- hop counter procedures (protection against loops) - rules for loadsharing
or primary/backup routing, possibly using the TCAP destination TID

John, working with an external database accessed by your SUA is proprietary
and actually this database will belong to your "system" (one black box).
When building a network, you may have a central GT-database but this will be
regarded as an SUA-relay point (STP in SS7 terminology), so there is no
decoupling of SUA and AMF => these will be considered as existing together
on an SUA host which has relay functionality. SUA host with only end-point
functionality won't be able to route on GT or hostname; I want to clearly
stress this definition.

Again, how you realize this AMF is out of scope of the SUA specification :
local tables, using DNS, Oracle database connected to your box, ...

As a note : in SCCP an interface for external GT translation was also never
standardized. Reasons :
- there is no need for it (concept of relay functionality) => SRF - use of
existing protocols for database access => IN/MAP; or in IP-case : DNS, ...
LDAP

So SUA and AMF are integrated just as SCCP and GTT are intergrated. It is
the operator who controls the size and scope of his database. Some SUA
endpoints might, for their relay functionality, by default select an SUA
peer with an extensive AMF; in other words, operate with a real thin/default
AMF.

Any comments on this opinion ?

____________________________

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

-----Original Message-----
From: Koenig Thomas [mailto:[email-masked]] Sent: donderdag 10
mei 2001 14:21
To: Verwimp Gery; Coene Lode
Subject: WG: TR29.903 SUA Feasibility Study Importance: High

Dear Gery, Dear Lode,

could you please check till tomorrow the France Telecom review comment and
Michaels reply on the 3GPP SUA feasibility study?

Why is GTT out of scope of SUA as Michael writes? 

Thanks in advance !

Thomas König
____________________________________
s
> Information & Communication Mobile
> Networks Mobile Core
ICM N MC CP SE 2
Hfd/LS11
Phone:	+49 6621 169-178
Fax:	+49 6621 169-225
E-Mail: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von:	Schmitt Peter 
> Gesendet am:	Donnerstag, 10. Mai 2001 09:48
> An:	Koenig Thomas
> Betreff:	WG: TR29.903 SUA Feasibility Study
> Wichtigkeit:	Hoch
> 
> Hallo Thomas;
> 
> bitte mit Atea kolleghen Diskutieren!
> 
> Response bis Freitag 11.05.01 17:00
> 
> >  <<N4-010563.zip>> 
> Gruss Peter
> Kind Regards / Mit Freundlichen Grüssen
>                         Peter Schmitt 
>
----------------------------------------------------------------------------
------
>                               Siemens AG 
>                               Information & Communication Mobile
>                               ICM N MC CP SE 2
>                               Tel.: +496621169152
>                               Fax: +496621169225
> Peter Schmitt          Mail: [email-masked]
> 
> -----Ursprüngliche Nachricht-----
> Von:	Young Michael-Y10724 [SMTP:[email-masked]]
> Gesendet am:	Donnerstag, 10. Mai 2001 04:06
> An:	[email-masked]
> Betreff:	Re: TR29.903 SUA Feasibility Study
> 
>  Dear Francois, 
> 
> Thanks for your comments, please see my reply inserted below.
> 
> BR,
> 
> Michael Young
> ---------------------------------------------------------------
> System Design, GTSS Vancouver, Motorola
> Tel: +1 (604)241-6032   Cel: +1 (604)726-6609
> Email: [email-masked]
> --------------------------------------------------------------- 
> 
> -----Original Message-----
> From: DRONNE Francois FTRD/DMR/ISS
[mailto:[email-masked]]
> Sent: Monday, May 07, 2001 3:04 AM
> To: [email-masked]
> Subject: Re: TR29.903 SUA Feasibility Study
> 
> 
> Dear Michael,
>  
> I fully disagree with the chapter "8.4 Mobility Number Portability" where
it is written that the "MNP uses MAP protocol to provide the service".
> Actually, most of the service is supported by the SCCP layer, as described
in the 23.066. The SRF function does look at the SCCP to check the nature of
the message received (use of the TT parameter) and also to check the address
of the subscriber (CdPA = MSISDN).
> Therefore, the fact that SUA "fully supports TCAP and MAP" is not enough
and I suggest you to investigate more on this very sensitive point.
> [Young Michael-Y10724] The investigation we have done shows SUA can
effectively replace SCCP/M3UA except GTT, which is out of the scope of SUA.
That's also why AMF (Address Mapping Function is introduced and refered in
SUA spec).  As to SRF, which is one of the two options to implement MNP:
IN-based or SRF-based.  SRF stands for Signalling Relay Function, it
actually means that a SCCP message sent to an HLR may need to be relayed by
an MNP-SRF node.   Message relay is a standard mechanism provided by SCCP
and it is also the basic service provided by SUA (Please refer to section
1.4.6 Relay function under section 1.4 Services provided by the SUA layer).
The actually MNP service is provided by utilizing several MAP procedures and
messages.  However, the statements in 29.903 might not be very accurate and
any rewording is welcome. 
>  
> I also have questions for my clarification :
>  
> 1/ Chapters 7.1.2.1 , you mentionned that the AMF function uses the E.164
address with the SSN to find the corresponding IP address. But the routing
on Global Title (with E.164 address) is also possible without SSN. Do you
intend to change the SSN to be mandatory in SCCP, when routing on GT?> 
> [Young Michael-Y10724]  I don't think SSN is mandatory in SCCP when
routing on GT, it actually depends on different cases.  Below is my
understanding, please correct me if I am wrong. 
> 
> In current SS7 network, the use of SSN is a network operator option and
values for intra-PLMN usage are network specific. However SSNs have been
reserved for inter-PLMN use, as defined in 3GPP TS 23.003. 
> 
> The addressing elements consist of information contained within the
Calling and the Called Party Addresses which are sent by the application to
the lower layers. 
> 
> The application expects the SCCP to route messages by either (a) the use
of the Destination Point Code (DPC) plus the Subsystem Number (SSN), or (b)
the use of the GT plus optionally the SSN. The application also specifies to
the lower layer whether to route the message on the DPC or the GT.
> 
> Method (a) above may be used when the application is aware of the
destination point code and the destination SSN located at that point code to
which the message is to be delivered. Within a national network different
SSNs, according to ITU-T SCCP recommendation Q.713, may be allocated for the
different network specific applications.
> 
> Method (b) above may be used when a message is to be delivered to a
SCCP-user which can be identified by the combination of the elements within
the GT. An example of the use of this method is when messages have to be
delivered between different networks. This method may be used since the
originating network is unaware of the point code and SSN's allocations
within the destination network. The network that determines the end-node to
which the message is to be delivered has to perform a GT Translation to
derive the destination Point Code and the SSN. If optionally the original
address contained the SSN, then this may be used as the destination SSN, or
the translation may, if required, provide an appropriate new SSN. 
>  
> 2/ Chapter 7.1.2.1 again, you describe the query to an ENUM server. To my
comprehension, this mechanism seems to bring complexity, compares to the
classical routing procedures based on the first digits (CC + NDC). Am I
right?
> [Young Michael-Y10724] In section 7.1.2.1, it utilises the  standard ENUM
service to find out the IP address associated with the E164 number, it is
almost one time process.  I don't think this is more complex than current
routing mechanism based on GMT (E214). 
>  
> Thank you in advance for your answer.
>  
> Best Regards,
>  
> François DRONNE
> France Telecom
> 
> 	-----Message d'origine-----
> 	De : Young Michael-Y10724 [mailto:[email-masked]]
> 	Envoyé : samedi 5 mai 2001 07:47
> 	À : [email-masked]
> 	Objet : TR29.903 SUA Feasibility Study
> 	
> 	
> 
> 	Dear CN4 colleagues, 
> 
> 	Please see the preliminary release of the subject item enclosed.  I
would appreciate if you can provide the comments before I make  final
submission to CN4 meeting next Tuesday.
> 
> 	Thanks & have a nice weekend, 
> 
> 	Michael Young 
> 	--------------------------------------------------------------- 
> 	System Design, GTSS Vancouver, Motorola 
> 	Tel: +1 (604)241-6032   Cel: +1 (604)726-6609 
> 	Email: [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: Address Mapping text
Date: Fri, 11 May 2001 14:02:40 +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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

2 comments :

- with DPC or IP address, ALWAYS a valid SSN has to be present. With this
the end-SUA has to address it's user; we have to keep this interface with
the user.

- does an ASP still have to know the concept of SG-SGP ?

greetings,

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent:
donderdag 10 mei 2001 12:17
To: sigtran
Subject: SUA5: Address Mapping text

Hi all, 

There has been some discussion as of late on SUA / GTT / ENUM / etc.  I have
updated the text.  Please comment.

br,
John

1.5 Internal Functions Provided in the SUA Layer 

It is assumed that Global Title Translation (GTT) occurs outside of SUA.
However, SUA will need to map the output of the GTT process, when
applicable, to an ASP via an Address Mapping Function (AMF).  

When SS7 addressing is used by the upper layer protocol, SUA will need to
determine the correct signaling endpoint.  How this is done is
implementation specific, but it could involve DNS [ENUM] or local
configuration information.

1.5.1 Address Translation and Mapping at the SG

The SG MUST provide address translation and mapping functions to direct
messages received from the SS7 network to the appropriate IP destination.

In order to support message distribution, the SG maintains an address
translation table, which maps the incoming SS7 messages to the appropriate
AS.  The relevant fields of the incoming SS7 message is compared to the
existing Routing Keys.  The Routing Keys reference an Application Server,
which will have one or more ASPs processing traffic for the AS.  The
availability and status of the ASPs is handled by SUA ASP management
messages.

Possible SS7 address/routing information that comprise a Routing Key entry
includes, for example, OPC, DPC, SIO found in the MTP3 routing label, or
other specific fields such as the SCCP subsystem number, or TCAP transaction
ID. Some possibilities include:

	Global Title (+ SSN optionally)
	PC (+ SSN optionally)
	Host Name (+ SSN optionally)
	IP Address(es) (+ SSN optionally)

An Application Server maintains a list of ASPs that are available to process
the traffic.  The list is dynamic, based upon the availability of the
individual ASPs in the list.  SUA ASP management messages are used to convey
the status of these ASPs and their availability in failover situations.

Normally, one or more ASPs areis active in the ASP (i.e., currently
processing traffic) but in certain failure and transition cases it is
possible that there may not be an active ASP available. The SG will buffer
the message destined for this AS for a time T(r) or until an ASP becomes
available. When no ASP becomes available before expiry of t(r), the SG will
flush the buffered messages and initiate the appropriate return or refusal
procedures. 

Both load-sharing and backup scenarios are supported.

If there is no Routing Key match for an incoming SS7 message, a default
treatment MUST be specified.  Possible solutions are to provide a default
Application Server to direct all unallocated traffic to a (set of) default
ASP(s), or to drop the messages and provide a notification to management.
The treatment of unallocated traffic is implementation dependent.

1.5.2 Address Translation and Mapping at the ASP

In order to direct messages to the SS7 network, the ASP must also perform an
address translation and mapping function in order to choose the proper SG or
SGP for a given message.  This is accomplished by observing the Destination
Point Code and other elements of the outgoing message, SS7 network status,
SG and SGP availability, and network appearance configuration tables.

A remote Signaling Gateway may be composed of one or more SGPs.  that are
capable of routing SS7 traffic.  As is the case with ASPs, a dynamic list of
SGPs in an SG can be maintained, taking into account the availability status
of the individual SGPs, configuration changes and fail-over mechanisms.
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.

1.5.3 SCTP Stream Mapping

The SUA supports SCTP streams. The SG/AS needs to maintain a list of SCTP
and SUA-users for mapping purposes.  SCCP-users requiring sequenced message
transfer need to be sent over a stream supporting sequenced delivery.

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

---
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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 14:13:16 +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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Michael,
 
Simple : in an all IP-environment, you may also route on GT or hostname. The
AMF then has the responsibility of mapping this to an SCTP association
(IP-address) and either the same GT/hostname or a new one (the destination
might also be a relay node) !!
 
greetings,

____________________________ 

Gery Verwimp 
SIEMENS ATEA 
ICN D CS D5 

Tel. : +32 14 25 3424 
Fax : +32 14 25 3212 
mailto:g <mailto:g> [email-masked]
____________________________________ 

-----Original Message-----
From: Young Michael-Y10724 [mailto:[email-masked]] Sent: vrijdag
11 mei 2001 2:41
To: sigtran
Subject: RE: SUA5: Address Mapping text

Hi John, 

It is still not clear to me that how address translation and mapping is done
in an all ip environment.  I am not sure if you intend to cover this under
this section.  Meanwhile, please see my other comments inserted below.

BR, 

Michael Young 
--------------------------------------------------------------- System
Design, GTSS Vancouver, Motorola Tel: +1 (604)241-6032   Cel: +1
(604)726-6609 Email: [email-masked] 
--------------------------------------------------------------- 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, May 10, 2001 3:17 AM 
> To: sigtran 
> Subject: SUA5: Address Mapping text 
> 
> 
> Hi all, 
> 
> There has been some discussion as of late on SUA / GTT / ENUM 
> / etc.  I have 
> updated the text.  Please comment. 
> 
> br, 
> John 
> 
> 1.5 Internal Functions Provided in the SUA Layer 
> 
> It is assumed that Global Title Translation (GTT) occurs 
> outside of SUA. 
> However, SUA will need to map the output of the GTT process, when 
> applicable, to an ASP via an Address Mapping Function (AMF).  
> 
> When SS7 addressing is used by the upper layer protocol, SUA 
> will need to 
> determine the correct signaling endpoint.  How this is done is 
> implementation specific, but it could involve DNS [ENUM] or local 
> configuration information. 
> 
[MYH] ==> "DNS [ENUM] and/or local configuration information." 

> 1.5.1 Address Translation and Mapping at the SG 
> 
> The SG MUST provide address translation and mapping functions 
> to direct 
> messages received from the SS7 network to the appropriate IP 
> destination. 
> 
> In order to support message distribution, the SG maintains an address 
> translation table, which maps the incoming SS7 messages to 
> the appropriate 
> AS.  The relevant fields of the incoming SS7 message is 
> compared to the 
> existing Routing Keys.  The Routing Keys reference an 
> Application Server, 
> which will have one or more ASPs processing traffic for the AS.  The 
> availability and status of the ASPs is handled by SUA ASP management 
> messages. 
> 
> Possible SS7 address/routing information that comprise 
> a Routing Key entry includes, for example, OPC, DPC, SIO found in 
> the MTP3 routing label, or other specific fields such as the 
> SCCP subsystem number, or TCAP transaction ID. Some 
> possibilities include: 
> 
>       Global Title (+ SSN optionally) 
>       PC (+ SSN optionally) 
>       Host Name (+ SSN optionally) 
>       IP Address(es) (+ SSN optionally) 

[MYH] My understanding is that in case of IP address the SSN should be
mandatory to identify the correct SSN. 
> 
> An Application Server maintains a list of ASPs that are 
> available to process 
> the traffic.  The list is dynamic, based upon the availability of the 
> individual ASPs in the list.  SUA ASP management messages are 
> used to convey 
> the status of these ASPs and their availability in failover 
> situations. 
> 
> Normally, one or more ASPs areis active in the ASP (i.e., currently 

[MYH] Typo here, "areis" --> "are"; the second ASP should be "AS" 

> processing traffic) but in certain failure and transition cases it is 
> possible that there may not be an active ASP available. The 
> SG will buffer 
> the message destined for this AS for a time T(r) or until an 
> ASP becomes 
> available. When no ASP becomes available before expiry of 
> t(r), the SG will 
> flush the buffered messages and initiate the appropriate 
> return or refusal 
> procedures. 
> 
> Both load-sharing and backup scenarios are supported. 
> 
> If there is no Routing Key match for an incoming SS7 message, 
> a default 
> treatment MUST be specified.  Possible solutions are to 
> provide a default 
> Application Server to direct all unallocated traffic to a 
> (set of) default 
> ASP(s), or to drop the messages and provide a notification to 
> management. 
> The treatment of unallocated traffic is implementation dependent. 
> 
> 1.5.2 Address Translation and Mapping at the ASP 
> 
> In order to direct messages to the SS7 network, the ASP must 
> also perform an 
> address translation and mapping function in order to choose 
> the proper SG or 
> SGP for a given message.  This is accomplished by observing 
> the Destination 
> Point Code and other elements of the outgoing message, SS7 
> network status, 
> SG and SGP availability, and network appearance configuration tables. 
> 
> A remote Signaling Gateway may be composed of one or more 
> SGPs.  that are 
> capable of routing SS7 traffic.  As is the case with ASPs, a 
> dynamic list of 
> SGPs in an SG can be maintained, taking into account the 
> availability status 
> of the individual SGPs, configuration changes and fail-over 
> mechanisms. 
> 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. 
> 
> 1.5.3 SCTP Stream Mapping 
> 
> The SUA supports SCTP streams. The SG/AS needs to maintain a 
> list of SCTP 
> and SUA-users for mapping purposes.  SCCP-users requiring 
> sequenced message 
> transfer need to be sent over a stream supporting sequenced delivery. 
> 
> SUA MUST use stream 0 for SUA management messages. It is 
> recommended that 
> sequenced delivery is usedbe in order to preserve the order 
> of management 
> message delivery. 
> 
> 
> --- 
> 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: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: TR29.903 SUA Feasibility Study
Date: Fri, 11 May 2001 15:38:40 +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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Gery,

> So SUA and AMF are integrated just as SCCP and GTT are 
> intergrated. It is the operator who controls the size and 
> scope of his database. Some SUA endpoints might, for their 
> relay functionality, by default select an SUA
> peer with an extensive AMF; in other words, operate with a 
> real thin/default AMF.
> 
> Any comments on this opinion ?

I agree completely.  

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Mark Kobine <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA: Draft 7 - Assorted Queries
Date: Fri, 11 May 2001 13:59:21 +0100
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: blueyonder.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [195.188.53.121]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

I have a few queries with the M2UA spec.

1) Section 1.4.2. The first paragraph reads as though there might be
something missing immediately following the paragraph. More specifically the
last sentence reads "These primitives are shown below:" but there are none
listed.

Or is this referring to the primitives in section 1.4.3?

2) Section 3.3.3.2. When an AS sends out a AS_State_Change Notify message
does it send it to all ASPs (except the ones that are Down) or just the
active one(s)?

3) Section 4.2.1 first para. Does the "(Error)" in the first sentence refer
to the Error Message? If so it makes little sense in the context.

Cheers,
Mark

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Fri, 11 May 2001 10:39:47 -0500
From: Randall Stewart <[email-masked]>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: New RFC2960bis
X-SMTP-HELO: sj-msg-core-4.cisco.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.10]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all:

I have just sent to the I-D editor the 2960BIS... first pass..
I am sure we will have a couple of more :)

Now attached please find a diff -c of the changes...

I first de-paged the RFC and saved it... this is my rcs base 1.2 text (used
in the diff).

The 1.6 version is the updated final version I just sent off to the editor
(minus the paging).

Regards

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127Index:
draft-ietf-tsvwg-rfc2960bis-00.txt
=================================================================== RCS
file: /home/sourceTree/doc/sctp/draft-ietf-tsvwg-rfc2960bis-00.txt,v
retrieving revision 1.2
retrieving revision 1.6
diff -c -r1.2 -r1.6
*** draft-ietf-tsvwg-rfc2960bis-00.txt	2001/05/08 14:31:37	1.2 ---
draft-ietf-tsvwg-rfc2960bis-00.txt	2001/05/11 14:59:52	1.6
***************
*** 112,117 ****
--- 112,118 ----
           3.3.10.8 Unrecognized Parameters............................ 45
           3.3.10.9 No User Data....................................... 46
           3.3.10.10 Cookie Received While Shutting Down............... 46 +
3.3.10.11 Restart of an association with new addresses......
         3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
         3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
         3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
***************
*** 150,156 ****
       6.5 Stream Identifier and Stream Sequence Number................ 80
       6.6 Ordered and Unordered Delivery.............................. 80
       6.7 Report Gaps in Received DATA TSNs........................... 81 !
6.8 Adler-32 Checksum Calculation............................... 82
       6.9 Fragmentation............................................... 83
       6.10 Bundling .................................................. 84
     7. Congestion Control   .......................................... 85
--- 151,157 ----
       6.5 Stream Identifier and Stream Sequence Number................ 80
       6.6 Ordered and Unordered Delivery.............................. 80
       6.7 Report Gaps in Received DATA TSNs........................... 81 !
6.8 fletcher-16 Checksum Calculation............................ 82
       6.9 Fragmentation............................................... 83
       6.10 Bundling .................................................. 84
     7. Congestion Control   .......................................... 85
***************
*** 415,429 ****
  1.3.6 Packet Validation
  
     A mandatory Verification Tag field and a 32 bit checksum field (see !
Appendix B for a description of the Adler-32 checksum) are included
     in the SCTP common header.  The Verification Tag value is chosen by
     each end of the association during association startup.  Packets
     received without the expected Verification Tag value are discarded,
     as a protection against blind masquerade attacks and against stale !
SCTP packets from a previous association.  The Adler-32 checksum
     should be set by the sender of each SCTP packet to provide additional
     protection against data corruption in the network.  The receiver of !
an SCTP packet with an invalid Adler-32 checksum silently discards
     the packet.
  
  1.3.7 Path Management
--- 416,430 ----
  1.3.6 Packet Validation
  
     A mandatory Verification Tag field and a 32 bit checksum field (see !
appendix B for a description of the fletcher-16 checksum) are included
     in the SCTP common header.  The Verification Tag value is chosen by
     each end of the association during association startup.  Packets
     received without the expected Verification Tag value are discarded,
     as a protection against blind masquerade attacks and against stale !
SCTP packets from a previous association.  The Fletcher-16 checksum
     should be set by the sender of each SCTP packet to provide additional
     protection against data corruption in the network.  The receiver of !
an SCTP packet with an invalid Fletcher-16 checksum silently discards
     the packet.
  
  1.3.7 Path Management
***************
*** 756,763 ****
     Checksum: 32 bits (unsigned integer)
  
           This field contains the checksum of this SCTP packet.  Its !
calculation is discussed in Section 6.8.  SCTP uses the Adler- !          32
algorithm as described in Appendix B for calculating the
           checksum
  
  3.2  Chunk Field Descriptions
--- 757,764 ----
     Checksum: 32 bits (unsigned integer)
  
           This field contains the checksum of this SCTP packet.  Its !
calculation is discussed in Section 6.8.  SCTP uses the Fletcher- !
16 algorithm as described in Appendix B for calculating the
           checksum
  
  3.2  Chunk Field Descriptions
***************
*** 820,826 ****
  
     01 - Stop processing this SCTP packet and discard it, do not process
          any further chunks within it, and report the unrecognized !
parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
     10 - Skip this chunk and continue processing.
--- 821,827 ----
  
     01 - Stop processing this SCTP packet and discard it, do not process
          any further chunks within it, and report the unrecognized !
parameter in an 'Unrecognized Chunk Type' (in either an
          ERROR or in the INIT ACK).
  
     10 - Skip this chunk and continue processing.
***************
*** 845,863 ****
        field will be set to 4.  The Chunk Length field does not count any
        padding.
  
     Chunk Value: variable length
  
        The Chunk Value field contains the actual information to be
        transferred in the chunk.  The usage and format of this field is
        dependent on the Chunk Type.
  
-    The total length of a chunk (including Type, Length and Value fields) -
MUST be a multiple of 4 bytes.  If the length of the chunk is not a -
multiple of 4 bytes, the sender MUST pad the chunk with all zero -    bytes
and this padding is not included in the chunk length field.
-    The sender should never pad with more than 3 bytes.  The receiver -
MUST ignore the padding bytes.
- 
     SCTP defined chunks are described in detail in Section 3.3.  The
     guidelines for IETF-defined chunk extensions can be found in Section
     13.1 of this document.
--- 846,868 ----
        field will be set to 4.  The Chunk Length field does not count any
        padding.
  
+       Chunks (including Type, Length and Value fields) are padded out +
by the sender with all zero bytes to be a multiple of 4 bytes +       long.
This padding MUST NOT be more than 3 bytes in total.
+       The Chunk Length value does not include terminating padding +
of the Chunk. However, it does include padding of any variable +
length parameter except the last parameter in the Chunk. The +
receiver MUST ignore the padding.
+ 
+       Note: A robust implementation should accept the Chunk whether +
or not the final padding has been included in the Chunk Length.
+ 
     Chunk Value: variable length
  
        The Chunk Value field contains the actual information to be
        transferred in the chunk.  The usage and format of this field is
        dependent on the Chunk Type.
  
     SCTP defined chunks are described in detail in Section 3.3.  The
     guidelines for IETF-defined chunk extensions can be found in Section
     13.1 of this document.
***************
*** 913,923 ****
     specify the action that must be taken if the processing endpoint does
     not recognize the Parameter Type.
  
!    00 - Stop processing this SCTP packet and discard it, do not process !
any further chunks within it.
  
!    01 - Stop processing this SCTP packet and discard it, do not process !
any further chunks within it, and report the unrecognized
          parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
--- 918,928 ----
     specify the action that must be taken if the processing endpoint does
     not recognize the Parameter Type.
  
!    00 - Stop processing this SCTP chunk and discard it, do not process !
any further parmameters within this chunk.
  
!    01 - Stop processing this SCTP chunk and discard it, do not process !
any further parameters within this chunks, and report the unrecognized
          parameter in an 'Unrecognized Parameter Type' (in either an
          ERROR or in the INIT ACK).
  
***************
*** 929,935 ****
  
     The actual SCTP parameters are defined in the specific SCTP chunk
     sections.  The rules for IETF-defined parameter extensions are !
defined in Section 13.2.
  
  3.3 SCTP Chunk Definitions
  
--- 934,944 ----
  
     The actual SCTP parameters are defined in the specific SCTP chunk
     sections.  The rules for IETF-defined parameter extensions are !
defined in Section 13.2. Note that a parameter value MUST be unique !
across all chunks. For example, the parameter value '5' is used to !
represent an IPv4 address (see section 3.3.2). The value '5' then !    is
reserved across all chunks to represent an IPv4 address and !    MUST NOT be
reused with a different meaning in any other chunk.
  
  3.3 SCTP Chunk Definitions
  
***************
*** 1155,1161 ****
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details.
  
        Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
        the association.
--- 1164,1170 ----
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details. 
  
        Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
        the association.
***************
*** 1378,1384 ****
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details.
  
        Note: A receiver of an INIT ACK  with the MIS value set to 0
        SHOULD destroy the association discarding its TCB.
--- 1387,1396 ----
  
        Note: There is no negotiation of the actual number of streams but
        instead the two endpoints will use the min(requested, offered).
!       See Section 5.1.1 for details. The Number of Inbound Streams !
sent in the INIT-ACK MUST NOT be greater than the value found !       in the
number of outbound streams received in the INIT.
! 
  
        Note: A receiver of an INIT ACK  with the MIS value set to 0
        SHOULD destroy the association discarding its TCB.
***************
*** 1870,1875 ****
--- 1882,1888 ----
         8              Unrecognized Parameters
         9              No User Data
        10              Cookie Received While Shutting Down +       11
Restart of an association with new addresses
  
     Cause Length: 16 bits (unsigned integer)
  
***************
*** 1880,1886 ****
  
        This field carries the details of the error condition.
  
!    Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
     Guidelines for the IETF to define new error cause values are
     discussed in Section 13.3.
  
--- 1893,1899 ----
  
        This field carries the details of the error condition.
  
!    Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
     Guidelines for the IETF to define new error cause values are
     discussed in Section 13.3.
  
***************
*** 2017,2023 ****
     ---------------
     Invalid Mandatory Parameter:  This error cause is returned to the
     originator of an INIT or INIT ACK chunk when one of the mandatory !
parameters is set to a invalid value.
  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Cause Code=7              |      Cause Length=4           |
--- 2030,2036 ----
     ---------------
     Invalid Mandatory Parameter:  This error cause is returned to the
     originator of an INIT or INIT ACK chunk when one of the mandatory !
parameters is set to an invalid value.
  
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Cause Code=7              |      Cause Length=4           |
***************
*** 2082,2087 ****
--- 2095,2120 ----
        |     Cause Code=10              |      Cause Length=4          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
+ 3.3.10.11 Restart of an association with new addresses (11) + 
+     Cause of error
+     --------------
+     Restart of an association with new addresses: A COOKIE ECHO was +
received on an existing association. But the COOKIE ECHO added +
addresses to the association that were previously NOT part +     of the
association. The New addresses are listed in the +     error code. This
ERROR is normally sent as part of an ABORT +     refusing the Cookie Echo
(see section 5.2.4).
+ 
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|     Cause Code=11              |      Cause Length=Variable   | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +       /
New Address TLVs                             / +       \
\ +       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       
+ 
+ 
  3.3.11 Cookie Echo (COOKIE ECHO) (10):
  
     This chunk is used only during the initialization of an association.
***************
*** 2532,2537 ****
--- 2565,2620 ----
     using a 'Supported Address Types' parameter in the new INIT to
     indicate what types of address it prefers.
  
+ 5.1.2.1 Special rules for IPv6 address scoping + 
+     When selecting IPv6 addresses to include as parameters in the INIT +
chunk the following rules MUST be applied: + 
+     A1) The INIT chunk MUST NOT include any IPv6 Link Local +
address parameters.
+ 
+     A2) An IPv6 Link Local address MAY be used as a destination +
address for an SCTP packet containing an INIT chunk.
+ 
+     A3) If the destination address of the INIT is a Site-Local or +
Link Local address, then both Site-Local and Global IPv6 +         address
parameters SHOULD be included in the INIT chunk.
+ 
+     A4) If the destination address of the INIT is an IPv6 Global +
address then the sender MUST NOT include any Site-Local +         IPv6
address parameters in the INIT chunk.
+ 
+     A5) If the destination address of the INIT is an IPv4 Address +
then the sender MUST NOT include any Site-Local IPV6 +         address
parameters in the INIT chunk.
+ 
+     When responding to an INIT chunk and selecting IPv6 address +
parameters to be included in the INIT-ACK chunk, the following rules +
MUST be applied:
+  
+     B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local +
address parameters.
+ 
+     B2) If the source address of the SCTP packet containing the INIT +
chunk is an IPv6 Link-Local address, then both Site-Local and +
Global IPv6 address parameters SHOULD be included in the +         INIT-ACK
chunk.
+ 
+     B3) If the source address of the SCTP packet containing the INIT +
chunk is an IPv6 Site-Local address, then both Site-Local +         and
Global IPv6 address parameters SHOULD be included in +         the INIT-ACK
chunk.
+ 
+     B4) If the source address of the SCTP packet containing the INIT +
chunk is an IPv6 Global address, then the sender MUST NOT +         include
any Site-Local IPv6 address parameters in the +         INIT-ACK chunk.
+ 
+     B5) If the source address of the SCTP packet containing the INIT +
chunk is an IPv4 address, then the sender MUST NOT +         include any
Site-Local IPv6 address parameters in the +         INIT-ACK chunk.
+ 
  5.1.3 Generating State Cookie
  
     When sending an INIT ACK as a response to an INIT chunk, the sender
***************
*** 2875,2880 ****
--- 2958,2976 ----
        related to this peer MUST be reset to their initial values (see
        Section 6.2.1).
  
+       If the cookie indicates that a new address(es) have been added +
to a restarting association, then the entire cookie MUST be discarded.
+       An ABORT MUST be sent that SHOULD include the error 'restart +
of an association with new addresses'. The error SHOULD list the +
addresses that were added to the restarting assocation.
+ 
+     This error should also list the TLV(s) with the new address(es) +
that was/were not present in the old association. This would allow +     a
true restarting association to go through a recovery procedure +     (if it
desired) to bring back the association.
+ 
+ 
+ 
        After this the endpoint shall enter the ESTABLISHED state.
  
        If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
***************
*** 2907,2913 ****
     Note: The "peer's Verification Tag" is the tag received in the
     Initiate Tag field of the INIT or INIT ACK chunk.
  
! 5.2.4.1 An Example of a Association Restart
  
     In the following example, "A" initiates the association after a
     restart has occurred.  Endpoint "Z" had no knowledge of the restart ---
3003,3009 ----
     Note: The "peer's Verification Tag" is the tag received in the
     Initiate Tag field of the INIT or INIT ACK chunk.
  
! 5.2.4.1 An Example of an Association Restart
  
     In the following example, "A" initiates the association after a
     restart has occurred.  Endpoint "Z" had no knowledge of the restart
***************
*** 2931,2942 ****
  Tag=Tag_A                                             Tag=Tag_Z
  <--------------------------------------------------------------->
  {A crashes and restarts}
! {app sets up a association with Z}
  (build TCB)
  INIT [I-Tag=Tag_A'
        & other info]  --------\
  (Start T1-init timer)         \
! (Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                        compose temp TCB and Cookie_Z
                                        with Tie-Tags to previous
                                        association) --- 3027,3038 ----
  Tag=Tag_A                                             Tag=Tag_Z
  <--------------------------------------------------------------->
  {A crashes and restarts}
! {app sets up an association with Z}
  (build TCB)
  INIT [I-Tag=Tag_A'
        & other info]  --------\
  (Start T1-init timer)         \
! (Enter COOKIE-WAIT state)      \---> (find an existing TCB
                                        compose temp TCB and Cookie_Z
                                        with Tie-Tags to previous
                                        association) ***************
*** 3143,3149 ****
  
     B) At any given time, the sender MUST NOT transmit new data to a
        given transport address if it has cwnd or more bytes of data !
outstanding to that transport address.
  
     C) When the time comes for the sender to transmit, before sending new
        DATA chunks, the sender MUST first transmit any outstanding DATA ---
3239,3247 ----
  
     B) At any given time, the sender MUST NOT transmit new data to a
        given transport address if it has cwnd or more bytes of data !
outstanding to that transport address. The sender may exceed !       cwnd by
up to (PMTU-1) bytes on a new transmission if the cwnd !       is not
currently exceeded.
  
     C) When the time comes for the sender to transmit, before sending new
        DATA chunks, the sender MUST first transmit any outstanding DATA
***************
*** 3156,3162 ****
     Multiple DATA chunks committed for transmission MAY be bundled in a
     single packet.  Furthermore, DATA chunks being retransmitted MAY be
     bundled with new DATA chunks, as long as the resulting packet size !
does not exceed the path MTU.  A ULP may request that no bundling is
     performed but this should only turn off any delays that a SCTP
     implementation may be using to increase bundling efficiency.  It does
     not in itself stop all bundling from occurring (i.e. in case of ---
3254,3260 ----
     Multiple DATA chunks committed for transmission MAY be bundled in a
     single packet.  Furthermore, DATA chunks being retransmitted MAY be
     bundled with new DATA chunks, as long as the resulting packet size !
does not exceed the path MTU.  An ULP may request that no bundling is
     performed but this should only turn off any delays that a SCTP
     implementation may be using to increase bundling efficiency.  It does
     not in itself stop all bundling from occurring (i.e. in case of
***************
*** 3225,3231 ****
     chunk format.  In particular, the SCTP endpoint MUST fill in the
     Cumulative TSN Ack field to indicate the latest sequential TSN (of a
     valid DATA chunk) it has received.  Any received DATA chunks with TSN !
greater than the value in the Cumulative TSN Ack field SHOULD also be
     reported in the Gap Ack Block fields.
  
     Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
--- 3323,3329 ----
     chunk format.  In particular, the SCTP endpoint MUST fill in the
     Cumulative TSN Ack field to indicate the latest sequential TSN (of a
     valid DATA chunk) it has received.  Any received DATA chunks with TSN !
greater than the value in the Cumulative TSN Ack field MUST also be
     reported in the Gap Ack Block fields.
  
     Note:  The SHUTDOWN chunk does not contain Gap Ack Block fields.
***************
*** 3768,3777 ****
     the size limit set by the MTU, and leave the remaining highest TSN
     numbers unacknowledged.
  
! 6.8 Adler-32 Checksum Calculation
  
     When sending an SCTP packet, the endpoint MUST strengthen the data !
integrity of the transmission by including the Adler-32 checksum
     value calculated on the packet, as described below.
  
     After the packet is constructed (containing the SCTP common header ---
3866,3875 ----
     the size limit set by the MTU, and leave the remaining highest TSN
     numbers unacknowledged.
  
! 6.8 Fletcher-32 Checksum Calculation
  
     When sending an SCTP packet, the endpoint MUST strengthen the data !
integrity of the transmission by including the Fletcher-16 checksum
     value calculated on the packet, as described below.
  
     After the packet is constructed (containing the SCTP common header
***************
*** 3780,3803 ****
     1) Fill in the proper Verification Tag in the SCTP common header and
        initialize the checksum field to 0's.
  
!    2) Calculate the Adler-32 checksum of the whole packet, including the
        SCTP common header and all the chunks.  Refer to appendix B for !
details of the Adler-32 algorithm.  And,
  
     3) Put the resultant value into the checksum field in the common
        header, and leave the rest of the bits unchanged.
  
     When an SCTP packet is received, the receiver MUST first check the !
Adler-32 checksum:
  
!    1) Store the received Adler-32 checksum value aside,
  
     2) Replace the 32 bits of the checksum field in the received SCTP !
packet with all '0's and calculate an Adler-32 checksum value of
        the whole received packet.  And,
  
!    3) Verify that the calculated Adler-32 checksum is the same as the !
received Adler-32 checksum.  If not, the receiver MUST treat the
        packet as an invalid SCTP packet.
  
     The default procedure for handling invalid SCTP packets is to ---
3878,3901 ----
     1) Fill in the proper Verification Tag in the SCTP common header and
        initialize the checksum field to 0's.
  
!    2) Calculate the Fletcher-16 checksum of the whole packet, including
the
        SCTP common header and all the chunks.  Refer to appendix B for !
details of the Fletcher-16 algorithm.  And,
  
     3) Put the resultant value into the checksum field in the common
        header, and leave the rest of the bits unchanged.
  
     When an SCTP packet is received, the receiver MUST first check the !
Fletcher-16 checksum:
  
!    1) Store the received Fletcher-16 checksum value aside,
  
     2) Replace the 32 bits of the checksum field in the received SCTP !
packet with all '0's and calculate an Fletcher-16 checksum value of
        the whole received packet.  And,
  
!    3) Verify that the calculated Fletcher-16 checksum is the same as the !
received Fletcher-16 checksum.  If not, the receiver MUST treat the
        packet as an invalid SCTP packet.
  
     The default procedure for handling invalid SCTP packets is to
***************
*** 4147,4159 ****
        marked for retransmission will fit into a single packet, subject
        to constraint of the path MTU of the destination transport address
        to which the packet is being sent.  Call this value K. Retransmit !
those K DATA chunks in a single packet.
  
     4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
        outstanding TSN number sent to that address, or the endpoint is
        retransmitting the first outstanding DATA chunk sent to that
        address.
  
     Note: Before the above adjustments, if the received SACK also
     acknowledges new DATA chunks and advances the Cumulative TSN Ack
     Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
--- 4245,4263 ----
        marked for retransmission will fit into a single packet, subject
        to constraint of the path MTU of the destination transport address
        to which the packet is being sent.  Call this value K. Retransmit !
those K DATA chunks in a single packet. When a Fast Retransmit !       is
being performed the sender SHOULD ignore the value of cwnd and !
SHOULD NOT delay retransmission.
  
     4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
        outstanding TSN number sent to that address, or the endpoint is
        retransmitting the first outstanding DATA chunk sent to that
        address.
  
+    5) Mark the DATA chunk(s) as being fast retransmitted and thus +
ineligible for a subsequent fast retransmit until after the +       T3-rxt
timer expires.
+ 
     Note: Before the above adjustments, if the received SACK also
     acknowledges new DATA chunks and advances the Cumulative TSN Ack
     Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
***************
*** 4167,4172 ****
--- 4271,4283 ----
     TSN's, the effect of TCP fast-recovery is achieved automatically with
     no adjustment to the congestion control window size.
  
+    Upon acknowledgement of a DATA chunk that has been fast retransmitted,
+    the protocol parameter 'Max.Burst' MUST be applied to limit +    how
many SCTP packets may be sent upon the completion of SACK +    processing. 
+ 
+ 
+ 
  7.3 Path MTU Discovery
  
     [RFC1191] specifies "Path MTU Discovery", whereby an endpoint
***************
*** 4226,4242 ****
  
  8.1 Endpoint Failure Detection
  
!    An endpoint shall keep a counter on the total number of consecutive !
retransmissions to its peer (including retransmissions to all the !
destination transport addresses of the peer if it is multi-homed).
!    If the value of this counter exceeds the limit indicated in the !
protocol parameter 'Association.Max.Retrans', the endpoint shall !
consider the peer endpoint unreachable and shall stop transmitting !    any
more data to it (and thus the association enters the CLOSED !    state).  In
addition, the endpoint shall report the failure to the !    upper layer, and
optionally report back all outstanding user data !    remaining in its
outbound queue. The association is automatically !    closed when the peer
endpoint becomes unreachable.
  
     The counter shall be reset each time a DATA chunk sent to that peer
     endpoint is acknowledged (by the reception of a SACK), or a ---
4337,4354 ----
  
  8.1 Endpoint Failure Detection
  
!     An endpoint shall keep a counter on the total number of consecutive !
retransmissions to its peer (including retransmissions to all the !
destination transport addresses of the peer if it is multi-homed, !     and
unacknowledged HEARTBEAT Chunks).  If the value of this counter !
exceeds the limit indicated in the protocol parameter !
'Association.Max.Retrans', the endpoint shall consider the peer !
endpoint unreachable and shall stop transmitting any more data to it !
(and thus the association enters the CLOSED state).  In addition, !     the
endpoint shall report the failure to the upper layer, and !     optionally
report back all outstanding user data remaining in its !     outbound queue.
The association is automatically closed when the !     peer endpoint becomes
unreachable.
  
     The counter shall be reset each time a DATA chunk sent to that peer
     endpoint is acknowledged (by the reception of a SACK), or a
***************
*** 4288,4294 ****
     By default, an SCTP endpoint shall monitor the reachability of the
     idle destination transport address(es) of its peer by sending a
     HEARTBEAT chunk periodically to the destination transport !
address(es).
  
     A destination transport address is considered "idle" if no new chunk
     which can be used for updating path RTT (usually including first ---
4400,4410 ----
     By default, an SCTP endpoint shall monitor the reachability of the
     idle destination transport address(es) of its peer by sending a
     HEARTBEAT chunk periodically to the destination transport !
address(es). HEARTBEAT sending MAY begin upon reaching the !    ESTABLISHED
state, and is discontinued after sending either !    SHUTDOWN or
SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST !    respond to a HEARTBEAT
with a HEARTBEAT-ACK after entering !    the COOKIE-SENT state up until
reaching the CLOSED state.
  
     A destination transport address is considered "idle" if no new chunk
     which can be used for updating path RTT (usually including first
***************
*** 4335,4342 ****
     well).
  
     The receiver of the HEARTBEAT should immediately respond with a !
HEARTBEAT ACK that contains the Heartbeat Information field copied !    from
the received HEARTBEAT chunk.
  
     Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
     should clear the error counter of the destination transport address ---
4451,4459 ----
     well).
  
     The receiver of the HEARTBEAT should immediately respond with a !
HEARTBEAT ACK that contains the Heartbeat Information TLV, together !
with any other received TLVs, copied unchanged from the received !
HEARTBEAT chunk.
  
     Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
     should clear the error counter of the destination transport address
***************
*** 4362,4368 ****
     heartbeat interval set by the SCTP user is added to the RTO of that
     destination (including any exponential backoff).  Only one heartbeat
     should be sent each time the heartbeat timer expires (if multiple !
destinations are idle).  It is a implementation decision on how to
     choose which of the candidate idle destinations to heartbeat to (if
     more than one destination is idle).
  
--- 4479,4485 ----
     heartbeat interval set by the SCTP user is added to the RTO of that
     destination (including any exponential backoff).  Only one heartbeat
     should be sent each time the heartbeat timer expires (if multiple !
destinations are idle).  It is an implementation decision on how to
     choose which of the candidate idle destinations to heartbeat to (if
     more than one destination is idle).
  
***************
*** 4380,4386 ****
  8.4 Handle "Out of the blue" Packets
  
     An SCTP packet is called an "out of the blue" (OOTB) packet if it is !
correctly formed, i.e., passed the receiver's Adler-32 check (see
     Section 6.8), but the receiver is not able to identify the
     association to which this packet belongs.
  
--- 4497,4503 ----
  8.4 Handle "Out of the blue" Packets
  
     An SCTP packet is called an "out of the blue" (OOTB) packet if it is !
correctly formed, i.e., passed the receiver's Fletcher-16 check (see
     Section 6.8), but the receiver is not able to identify the
     association to which this packet belongs.
  
***************
*** 4573,4579 ****
        SHUTDOWN sender.
  
     Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT !
send a SHUTDOWN in response to a ULP request, and should discard
     subsequent SHUTDOWN chunks.
  
     If there are still outstanding DATA chunks left, the SHUTDOWN ---
4690,4696 ----
        SHUTDOWN sender.
  
     Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT !
send a SHUTDOWN in response to an ULP request, and should discard
     subsequent SHUTDOWN chunks.
  
     If there are still outstanding DATA chunks left, the SHUTDOWN
***************
*** 4664,4670 ****
  
  10.1 ULP-to-SCTP
  
!    The following sections functionally characterize a ULP/SCTP
     interface.  The notation used is similar to most procedure or
     function calls in high level languages.
  
--- 4781,4787 ----
  
  10.1 ULP-to-SCTP
  
!    The following sections functionally characterize an ULP/SCTP
     interface.  The notation used is similar to most procedure or
     function calls in high level languages.
  
***************
*** 5750,5755 ****
--- 5867,5875 ----
        instances of this parameter type may be found within the same
        chunk.
  
+    e) Each parameter type MUST be unique across all chunks. 
+ 
+ 
  13.3 IETF-defined Additional Error Causes
  
     Additional cause codes may be allocated in the range 11 to 65535
***************
*** 5791,5800 ****
  
     RTO.Initial              - 3  seconds
     RTO.Min                  - 1  second !    RTO.Max                 -  60
seconds
     RTO.Alpha                - 1/8
     RTO.Beta                 - 1/4
!    Valid.Cookie.Life        - 60  seconds
     Association.Max.Retrans  - 10 attempts
     Path.Max.Retrans         - 5  attempts (per destination address)
     Max.Init.Retransmits     - 8  attempts --- 5911,5921 ----
  
     RTO.Initial              - 3  seconds
     RTO.Min                  - 1  second !    RTO.Max                  - 60
seconds !    Max.Burst                - 4  packets
     RTO.Alpha                - 1/8
     RTO.Beta                 - 1/4
!    Valid.Cookie.Life        - 60 seconds
     Association.Max.Retrans  - 10 attempts
     Path.Max.Retrans         - 5  attempts (per destination address)
     Max.Init.Retransmits     - 8  attempts ***************
*** 6068,6084 ****
  
        Note: The CWR is considered a Control chunk.
  
- Appendix B Alder 32 bit checksum calculation
  
!    The Adler-32 checksum calculation given in this appendix is copied from
!    [RFC1950].
  
!    Adler-32 is composed of two sums accumulated per byte: s1 is the sum !
of all bytes, s2 is the sum of all s1 values.  Both sums are done !
modulo 65521.  s1 is initialized to 1, s2 to zero.  The Adler-32 !
checksum is stored as s2*65536 + s1 in network byte order.
  
!    The following C code computes the Adler-32 checksum of a data buffer.
     It is written for clarity, not for speed.  The sample code is in the
     ANSI C programming language.  Non C users may find it easier to read
     with these hints:
--- 6189,6220 ----
  
        Note: The CWR is considered a Control chunk.

!    Appendix B Fletcher-16 checksum
  
!    The 16-bit Fletcher Checksum Algorithm is calculated over a sequence !
of 16 bit data quantities (call them D[1] through D[N]) by maintaining !
2 unsigned 1's-complement 16-bit accumulators A and B whose contents are !
initially zero, and performing the following loop where i ranges from !    1
to N:
! 
!            A := A + D[i]
!            B := B + A
! 
!    It can be shown that at the end of the loop A will contain the 16-bit !
1's complement sum of all octets in the datagram, and that B will !
contain (N)D[1] + (N-1)D[2] + ... + D[N].
! 
!    The octets covered by this algorithm should be the entire SCTP !
packet including the Common header and all chunks. Note that, !    for
purposes of the checksum computation, the checksum field !    itself must be
equal to zero.
! 
!    The result of the checksum should be placed in the 32-bit checksum !
field with B being placed in the most signifigant bit postion and !    A
being placed in the least signifigant position.
  
!    The following C code computes the Fletcher-16 checksum of a data
buffer.
     It is written for clarity, not for speed.  The sample code is in the
     ANSI C programming language.  Non C users may find it easier to read
     with these hints:
***************
*** 6091,6130 ****
            bit(s) at the right.
     ++     "n++" increments the variable n.
     %      modulo operator: a % b is the remainder of a divided by b.
!     #define BASE 65521 /* largest prime smaller than 65536 */
      /*
!       Update a running Adler-32 checksum with the bytes buf[0..len-1] !
and return the updated checksum.  The Adler-32 checksum should be !
initialized to 1.
! 
!        Usage example:
! 
!          unsigned long adler = 1L;
! 
!          while (read_buffer(buffer, length) != EOF) { !            adler =
update_adler32(adler, buffer, length); !          }
!          if (adler != original_adler) error(); !       */
!       unsigned long update_adler32(unsigned long adler, !
unsigned char *buf, int len)
        {
!         unsigned long s1 = adler & 0xffff; !         unsigned long s2 =
(adler >> 16) & 0xffff; !         int n;
! 
!         for (n = 0; n < len; n++) {
!           s1 = (s1 + buf[n]) % BASE;
!           s2 = (s2 + s1)     % BASE;
          }
!         return (s2 << 16) + s1;
!       }
  
-       /* Return the adler32 of the bytes buf[0..len-1] */ -       unsigned
long adler32(unsigned char *buf, int len) -       {
-         return update_adler32(1L, buf, len); -       }
  
  Full Copyright Statement
  
--- 6227,6276 ----
            bit(s) at the right.
     ++     "n++" increments the variable n.
     %      modulo operator: a % b is the remainder of a divided by b.
! 
      /*
!       Update a running Fletcher-16 checksum with the bytes buf[0..len-1] !
and return the updated checksum.  The checksum should be !       initialized
to 0.
! 
!        Usage example (assuming buf is a sctp packet): !
unsigned int sum,insum,*inp; ! 
!                inp = &buf[8];
!                insum = *inp;
! 	       *inp = 0;
!                sum = fletcher(buf, length); ! 	       if(sum !=
insum){
!                   /* drop packet, csum error */ ! 	       }
!      */
!       unsigned int fletcher(unsigned char *buf, int len)
        {
!         unsigned long s1 = 0;
! 	unsigned long s2 = 0;
! 	unsigned short *bufp;
!         int n,nlen;
!         nlen = len / 2;
! 
!         bufp = (unsigned short *)buf; !         for (n = 0; n < nlen;
n++,bufp++) { !             s1 = ((s1 + *bufp) & 0x0000ffff); !
s2 = ((s2 + s1) & 0x0000ffff);
          }
!         if(len > (nlen *2)){
!          /* do the odd byte, we don't !           * expect this code to
execute, !           * since SCTP does NOT have Odd byte !           *
messages.
!           */
!           unsigned short x;
!           x = buf[(len-1)] << 8 | 0;
!           s1 = ((s1 + x) & 0x0000ffff); !           s2 = ((s2 + s1) &
0x0000ffff); !         }
!         return ((unsigned int)(s2 << 16) + s1); !      }

  Full Copyright Statement

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Miriyala Srinivas-FSM016 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 11:19:20 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate4.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate4.mot.com [144.189.100.102]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hello All,

I agree with John that we use the term "Address Mapping Function" instead of
GTT to explain the need to map global titles to other addressing forms by
the SUA.

Regards
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: Friday,
May 11, 2001 5:28 AM
To: sigtran
Cc: Michael.Young
Subject: RE: SUA5: Address Mapping text

Hi Lode,

Some comments:

> 
> Suggestion for text:
> 
> If Global Titles are supported, then the Global Title Translation(GTT)
> function needs to be supported by SUA. In the broadest sense, the GTT
> function translates a GT to another GT + a IP address + 
> optional a SSN. The way in which this GTT function is performed is 
> implementation dependant but it could involve access to a remote database
> (examples DNS(ENUM), LDAP, ....) and/or acces to a locally
configured/engineerd 
> database. 

One problem with this is that in the signaling gateway, where is the GTT
performed?  Is it once at the SCCP layer; is it twice (SCCP layer and SUA
layer) or do we consider an implementation specific view that GTT is located
at the NIF and can be called by both SCCP and SUA and does some magic?

I'd suggest removing the GTT part of your paragraph and call it 'Address
Mapping Function' and maybe adding a note that within an SG, the GTT
function and Address Mapping Function can be combined in a implementation
spefic way (which is outside of the scope of this document).

> How to enforce the consistency of the database(s) within the 
> network is outside the scope of the document, but the database 
> must be configured so that a response msg from the destination/
> termination/Called party sua node can be send back to and received 
> by the  source/origination/Calling party sua node.
> 
> Note: this is fairly obvious in a IP network(but in IP this  
> condition is enforced by BGP or OSPF routing protocols), but in network 
> based on GTT that condition must be up till now enforced by carefully 
> configuring your network and agreements with other networks.

Agreed.

> > However, SUA will need to map the output of the GTT process, when 
> > applicable, to an ASP via an Address Mapping Function (AMF).  
> > 
> > When SS7 addressing is used by the upper layer protocol, SUA 
> > will need to 
> > determine the correct signaling endpoint.  How this is done is 
> > implementation specific, but it could involve DNS [ENUM] or local 
> > configuration information.  
> 
> SS7 addressing is a little vague here: is GT meant or is SS7 
> pointcodes meant. In case of GT, yes remote or local databases 
> should be used. In case of real SS7 pointcodes, then I think only 
> local databases will help you out, besides it looks a little weird, 
> having a extra indirection.  

We did a little implementation with SUA last summer with an SQL database
doing the address mapping.  This database was an example of what I meant.
The database could be located in a centralized place for one operator (or
replicated) and all of the SS7 addresses (GTs, Point Codes, SSNs) could be
located there along with all of the IP addresses & host names ...

> 
> [MYH] My understanding is that in case of IP address the SSN should be
> mandatory to identify the correct SSN.  
> 
> Depends whether the messages only contains the IP address or 
> more addressing info. If only the IP address is present in the 
> message, then indeed the  ssn must be present.

agreed.

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]
Date: Fri, 11 May 2001 18:38:40 +0200 (MEST)
From: ecejoz <[email-masked]>
Reply-To: [email-masked]
Subject: Final report from the Interop Test
To: "sigtran" <[email-masked]>
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi all from Madrid!

This is the final report from the 1st M3UA Interop Test.

15 companies and 31 people have been involved, with 16 different
implementations.

The version 5 of the protocol was tested and the 30% of the implementations
can support the mandatory functionality of version 6 of the protocol.

· The implementations were programed in the following languages:

C : 16 implementations 
C++ : 3 implementations 

· The following Operating Systems were used:

Linux :  12
Solaris : 6
Windows NT : 1

· And the type of computers used were: 

Laptops : 23
Work Stations : 6
Portable PC : 2

· The test were grouped into four configurations. 

Approximately 25 issues and comments were found and discussed daily with
Greg Sidebottom by conference call.

A list of open issues and questions made by all the participants is
attached.

As Test Coordinator, I would like to thank Heinz Prantner for the good job
he has done with this documentation.

Also, I would like to thank the Interop Coordination Team for being such a
good proffesional people and share their knwoledge with all of us. For so,
thanks Barry Nagelberg, Michael Tuexen, Kurt Kite and Heinz Prantner.

I would like to thank Greg Sidebottom for attending us in a such a kind way.

The first configuration was successfully tested by 77 of the 120 possible
pairs of implementations.

The second configuration was successfully tested by 33 of the 120 possible
pairs of implementations.

The third configuration was successfully tested by 39 of the 120 possible
pairs of implementations .

The fourth configuration was successfully tested by 30 of the 120 possible
pairs of implementations.

· The configurations were designed as follows:

CONFIGURATION 1: 1+0 -  1 SG - 1 ASP

1.1. Association establishment, started by the ASP 1.2 Connection
establishment
1.3 Activation of traffic between the two nodes 1.4 Sending data: from ASP
to SGP
1.5 Sending data: from ASP to SGP
1.6 Deactivation of the traffic between the nodes 1.7 ASP disconnection
1.8 Close association
--- New Proposals
1.9 Restart of the ASP

***********************

CONFIGURATION 2: 1+1 -  1 SG - 2 ASP in the same AS

2.1 Activation of the traffic
2.2 Over ride of the ASP
2.3 Over ride of the ASP with Stand By
2.3.1 Just as V5
2.3.2 (Optional !!) AS V6 way
2.4 Load share
2.5 ASPs disconnection

***********************

CONFIGURATION 3: 1+0 -  1 SG - 1 ASP serving to two different ASs

3.1 ASP_ACTIVE msg with more than one Routing Context
	The SG sends DATA msgs to the different ASs with its 
	different Routing Context
3.2 ASP_INACTIVE with more than one Routing Contexxt
	The Data msg should be refused when the AS is inactive.

************************

CONFIGURATION 4:  -  1 SG - 2 ASP serving to two different ASs.

4.1 Testing the MTP-PAUSE primitives with the DUNA message.
4.2 Testing the MTP-RESUME primitives with the DAVA message.
4.3 Testing the MTP-STATUS primitives with the DUPU and SCON 
	messages.

_________________________

Issues found and comments during the M3UA bakeoff

Last updated: HP, Thursday, 18:00 MEZ

Authors: Michael Tuexen
         Barry Nagelberg
         Heinz Prantner
         Jaime Olivares
         Kurt Kite

 Introduction:

   Issues found during the bake-off based on the m3ua draft version 5 will
   be collected here in case they are not covered by draft version 6. The
   issue list is updated once or twice a day based on the findings and after
   discussion by the bake-off participants. They then will be further
discussed
   via phone conference with Greg Sidebottom and updated with his comments,
   statements. Each update will be made available to the bake-off
participants
   on the local ftp server and - of course - to Greg via email.

 Issues:

 001   Notify message: the draft SHOULD specify the case where there is no
                       Routing Context specified in the notify message.
                       (similar to the wording at asp active)

       [Greg] will be covered by Version 7

 002   At receiption of the ASP-UP the SG updates the AS State to inactive.
       At least one implementation sends a Notify prior to ASP UP ACK, which
       is discarded in the ASP since the AS is in the down state until
       the receiption of the ASP UP ACK.

       [Greg] Version 7 will state something like "... MUST send Ack before 
        Notify...."

 003   paragraph 4.3.3.6 says the Notify message ... is sent ... should be
       rephrased to MUST be sent or SHOULD be sent...

       [Greg] tends to 'SHOULD'

 004   some discussion started whether the ASP UP changes the AS state and
of
       which one (which As). and then do we have to send NOTIFY  for all ASs
       ...?

       [Greg] needs to be distinguished between static configuration
         (preconfigured Application Server) and dynamic configuration
         (by Version 6 utilities like REG DEREG messages):

         - in static configuration you know the relation between AS ASP and
           the AS becomes inactive at the reception of the first ASP_UP
           message for that AS.

         - in dynamic configuration the ASP_UP comes before the REG so the
           SG does not know the relation. you wait for REG or ACTIVE message
           for state change of AS. Version 7 will cover further
clarification.

         - potentialy new ERROR code needed for ASP ACT without RC in
           absence of static configuration....

 005   7.1 add text to clarify the usage of protocol identifier:

         the proposed M3UA id SHOULD be used or 0 for unspecified. Other
values
         MUST not be used.

       [Greg] Ok.

 006  in case the sending of the NOTIFY message is mandatory, a procedure
      description, what to do in the ASP on receiption of the notify, would
      be applicable.

       [Greg] The Notify message was intended for Management Information
         (LM, System Management). Version 7 will state something like that.

TUESDAY

 007 ASP ACT without RC

     chapter 4.3.3.4 endof paragraph one states that the receiver must know
     which AS the ASP is member.. but it does not say that they have to be
     updated with new state information....

     [Greg] will add text for clarification, as well some description
      for ack before notify similar to asp_up

 008 DAUD DUNA DATA SCON ..
    
      Network Appearance Optional => misleading, its optional when the SG
      appears not more than in one network... otherwise mandatory
      (well, it is the ASP reporting for an AS which has only one 
         network appearance)

      [Greg] .. will make addition to 3.3.1 (DATA), 3.4.1 (DUNA), 3.4.2
             (DAVA), 3.4.3 (DAUD), 3.4.4 (SCON), 3.4.5 (DUPU), 3.4.6
             (DRST) to specify that the attribute *optional* for the
             network apearance parameter only
             applies to "single networked" scenarios. in that case
             you may or may not have the param.

 009 zero length optional parameter

     parameter appears with tag and length only, where the length indicates 
     header length only (zero length parameter value) ... 
      that should be ok for info strings or diagnostics
     which are already defined to be length 0 to n bytes, so its not really 
     an issue...

      [Greg] given the nature of TLVs, a parameter with length 4 should 
            be acceptable.

 010 byte definition for protocol data

     During the phone conference this issue came up: The illustration
     of the byte definition for the routing labels (itu and ansi) 
     are still subject for controversy. A decision has to be made
     whether the draft should contain the illustration of byte
     ordering for the payload data. In case the graphic remains
     it must made clear that it is for illustration purpose
     only and the implementor is not required to make any changes
     to the byte stream as it is defined in itu and ansi 
     specifications. Furthermore, the itu point code format should be
     illustrated as 14 bit values without structures, since the
     q.704 does not specify any structure, and structures (which do
     exist outside Q.704) may vary.

WEDNESDAY

 011 ASP Maintenance Message with RC acknowledged without RC

      ASP ACTIVE sent with a RC can be acknowledged
      without having the optional RC in the ACK.

      [Greg] spec will clarify: ACK MUST have RC in ACK
      
 012 multiple occurance of same tlv

      nothing against it.

      [Greg] draft will clarify: .... MAY have duplicate params ....

       brings up another issue about contradictionary params...

 014 ASP1 is ACTIVE
     ASP2 is DOWN
     ASP2 sends UP
     The SG sends UP_ACK but no Notify since the AS did not change state

     by the way: not all comments are issues for the draft, but for the
     purpose of keeping track of history they are mentioned here.

 015 first ASP sends UP OVERIDE STB before ACT has announced himself
        ACK with ACTIVE OVERIDE

 016 SG receives DATA from STB ASP
     or SG receives DATA from INACTIVE ASP

     clarify draft

      do you have to check the state when receiving data ?

      option one: the Sg checks the ASP state on receiption of
                  each DATA message.

                  pro: detect "babbling idiot" (cite Brian Bidulock) as soon
                       as possible.

                  con: performance overhead due to routing table 
                       lookups. Since there are not too many 
                       AS's per ASP expected it should not be 
                       too much of an overhead...

                  con: potentially additional mechanism needed for
                       apropriate reaction on fault detection.
                       one possibility could be the sending of
                       an Notify Active in response to the inactive 
                       sender (who talks while sleeping).

      option two: the ASP does not check the ASP state on receiption
                  of data messages.

      [Greg] needs further investigation ...

 017 ACTIVE ASP receives NOTIFY (ALT_ASP_ACTIVE) 

      Does this change the state of the ASP within the ASP? 
      Yes, if overide, ASP changes state.

      [Greg] if not yet there, spec needs to specify this.
        ASP has to check the state with its neighbour ASP...

 018 ASP sends ASP_ACTIVE 
     SG responds ACTIVE_ACK on Stream 0
     SG sends DATA on Stream 1
     assume DATA received before ACK
     DATA is lost because ASP is inactive 

      [Greg] yes, message is lost
         make note about it in draft

 019 follow up question to issue 004:

     in case there is no preconfiguration:

     ASP1 sends ASP UP (we dont know which As belongs to)
     ASP1 sends REG
     ASP2 sends ASP UP (ditto)
     ASP1 sends ACTIVE
     we cannot send Notify to ASP2 since we dont know....

     [Greg] proposals for issue 4 should cover that

 020 two ASP in loadshare mode

     (1) one ASP goes down, the AS remains active with one ASP only
     (2) the AS is up as soon as one ASP is Active

     both rules, scenarios have been questioned

     or, what is the difference between 2+2 and 3+1 (n+k)

 021 Error Response and Acknowledgement

     It occured that some implementations (at least one) did send an error
message
     in response to a state maintenance message AND an acknowledgement
     after the error. does not seem right.

     Relation between any msg and an error response is given by
     optional diagnostic info only.
     Perhaps we may need mandatory diagnostic infos in some cases.

     has been discussed already on the mailing list...

     how about negative acks

THURSDAY

 022 receiption of ASP_ACTIVE without having configuration information

        neither static configuration nor REG has been received 
        at receiption of ASP_ACTIVE

     [Greg] needs clarification, oob asp active
        asp active pragraph update. discard message
        in that case.

 023 "AS Restart"      

       In case one AS loses connectivity with the SGP(s) some 
       guidelines similar to mtp restart what to do would be
       appreciated. E.g. Should the ASPs hold back the ACTIVE message
       and request the DPC states via AUDIT before going active?

       proposals with pros cons

       Correlate MTP Restart in SG with above (1.4.3.2)

 024 DAUD message from the SG to the ASP in case it received an SCON from
ASP

      Since the SCON can be sent from the ASP to the SG it should be
      allowed to query the congestion state by the SG to the ASP.

     [Greg] Check for usefulness

 025 4.3.3.1 (Version 6) last two paragraphs:

     The handling of an unexpected ASP-Up message, described in these
     paragraphs, does not explain the desired behavior, in case the 
     ASP represents more than one AS, and the ASP states are different, 
     e.g. AS1 is active, AS2 is inactive.

 026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
        congestion.

     The proposal for sending a SCON message from the ASP to the
     SG for indicating M3UA or ASP congestion seems fragile. The
     SCON, similar to the MTP message TFC, indicates congestion
     towards an AS. Detection of congestion towards the AS 
     should lead to an traffic reduction at the originators. 
     Traffic towards the AS should be responded with TFCs. The
     effective way to ease the load for the ASP seems to be
     the closing of the receiver window in sctp (on upper
     layer request), which should lead to an congestion
     indication on the other side (the SG) from sctp to
     the upper layer. The SG, receiving traffic destined to
     the congested assoc, should respond appropriatly to 
     the originator. 

     The only case, where the SCON sent by the ASP seems
     applicable, is when the AS is geographically seperated
     from the ASP and the ASP detects overload towards the 
     AS. In any case, I would propose to relate the
     SCON to the AS (RC) rather than DPC.

     Just a thought, has not been discussed at the 
     bakoff yet.

 027 Audit Destination (the SG) from the ASP

     Is it possible to audit the dpc of the SG from
     the ASP (without having the ASP knowing whether it is the
       SG behind this Point Code )

Best Regards

 /Interop Coordination Team
  
  	- Barry Nagelberg
  	- Kurt Kite
  	- Jaime Olivares
  	- Heinz Prantner
  	- Michael Tuexen

---
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: FW: M3UA Iss7 - Routing Key Overlap
Date: Fri, 11 May 2001 13:04:37 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: FW: M3UA Iss7 - Routing Key Overlap</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>The application I seem to remember is where an SG could
accept an overlapping RK and rearrange the configuration data to ensure
unique routing.&nbsp; For example, if ASP1 registered for DPC=X, CIC codes 1
- 100.&nbsp; Then later ASP2 came in and registered for DPC=x, CIC codes 1 -
50.&nbsp; The SG could react by creating internally RK structures that allow
both ASP1and ASP2 to receive traffic for CICs 1-50 and ASP1 to get
51-100.&nbsp; How the actual traffic is distributed is determined by the
traffic modes in the ASP-Actives.</FONT></P>

<P><FONT SIZE=2>All this assumes that there is no change to the protocol
needed (i.e., the SG handles this internally).&nbsp; If so then how an SG
does this is probably implementation dependent.&nbsp; The key is that if an
SG can do this and still ensure unique routing, then we should allow
it.&nbsp; </FONT></P>

<P><FONT SIZE=2>Hope this helps,</FONT> </P>

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

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Joe Keller [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 10, 2001 12:56
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: FW:
M3UA Iss7 - Routing Key Overlap</FONT> </P>

<P><FONT SIZE=2>&nbsp;&lt;&lt; File: Internet HTML &gt;&gt; &lt;&lt; File:
footer &gt;&gt; </FONT> <BR><FONT SIZE=2>Greg,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Can you clarify the valid cases for
allowing overlapped routing key?</FONT> <BR><FONT SIZE=2>We may need to add
text to what you have already proposed.</FONT> </P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Joe</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>&quot;Sidebottom, Greg [BCNR:7M01:EXCH]&quot;
&lt;[email-masked]&gt; on 05/10/2001</FONT> <BR><FONT
SIZE=2>09:36:09 AM</FONT>
</P>

<P><FONT SIZE=2>Please respond to
[email-masked]</FONT> </P>

<P><FONT SIZE=2>To:&nbsp;&nbsp; &quot;sigtran&quot;
&lt;[email-masked]&gt;</FONT> <BR><FONT
SIZE=2>cc:&nbsp;&nbsp;&nbsp; (bcc: Joe Keller/Raleigh/TEKELEC)</FONT>
<BR><FONT SIZE=2>Subject:&nbsp; FW: M3UA Iss7 - Routing Key Overlap</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Resending - I sent (and resent) some e-some mails out
yesterday and didn't</FONT> <BR><FONT SIZE=2>see anything on the list,
except for my test e-mail!.&nbsp; Perhaps all my mails</FONT> <BR><FONT
SIZE=2>are being sent to &quot;my sigtran archive&quot; instead&nbsp;&nbsp;
2;^)</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From:&nbsp;&nbsp;&nbsp;&nbsp; Sidebottom, Greg
[BCNR:7M01:EXCH]</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp;&nbsp;&nbsp;
Wednesday, May 09, 2001 11:32 AM</FONT> <BR><FONT SIZE=2>To:&nbsp;
[email-masked]'</FONT> <BR><FONT
SIZE=2>Subject:&nbsp; M3UA Iss7 - Routing Key Overlap</FONT> </P>

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

<P><FONT SIZE=2>An issue was raised against the current text where we
explicitly mention</FONT> <BR><FONT SIZE=2>that overlap of Routing Key
information is not allowed.</FONT> </P>

<P><FONT SIZE=2>From Section 1.4.2.2:</FONT> </P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &quot;Routing Keys MUST be unique in the
sense that a received SS7</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;
signalling message cannot be matched to more than one Routing</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Key.&quot;</FONT> </P>

<P><FONT SIZE=2>And in 4.3.4.1:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &quot;If the SG determines that the
Routing Key parameter overlaps</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; with an existing Routing Key entry, the SG
returns a</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Registration
Response message to the ASP, with a Registration</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Status of &quot;Error - Overlapping
(Non-Unique) Routing Key&quot;.&nbsp; An</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; incoming signalling message received at an
SG cannot match</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; against
more than one Routing Key.&quot;</FONT> </P>

<P><FONT SIZE=2>I have heard the view that there may be some valid cases
where a Routing Key</FONT> <BR><FONT SIZE=2>overlap is OK.&nbsp; If so then
perhaps we could replace the MUST with a SHOULD</FONT> <BR><FONT SIZE=2>in
1.4.2.2.&nbsp; For 4.3.4.1 the last line could be deleted and we
could</FONT> <BR><FONT SIZE=2>generalize the error response from
&quot;Overlapping (Non-Unique) RK&quot; to</FONT> <BR><FONT SIZE=2>something
like &quot;Cannot Support Routing on RK&quot; and change the text around
a</FONT> <BR><FONT SIZE=2>bit to reflect that the problem is that the SG
can't route if it allows this</FONT> <BR><FONT SIZE=2>RK.</FONT>
</P>

<P><FONT SIZE=2>So to close on this - Is there support for this idea?&nbsp;
If so, are the above</FONT> <BR><FONT SIZE=2>changes OK?</FONT>
</P>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Greg</FONT> </P>
<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>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M3UA Sample Configuration question
Date: Fri, 11 May 2001 14:40:06 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <html
xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">

<meta name=ProgId content=Word.Document> <meta name=Generator
content="Microsoft Word 9"> <meta name=Originator content="Microsoft Word
9"> <link rel=File-List href="cid:[email-masked]"> <!--[if
gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>  <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-alt:"Arial Unicode MS";
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-format:other;
	mso-font-pitch:variable;
	mso-font-signature:1 135135232 16 0 262144 0;} @font-face
	{font-family:"MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-alt:"Arial Unicode MS";
	mso-font-charset:128;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:fixed;
	mso-font-signature:1 134676480 16 0 131072 0;} @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;} @font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-charset:128;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:fixed;
	mso-font-signature:1 134676480 16 0 131072 0;} @font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-format:other;
	mso-font-pitch:variable;
	mso-font-signature:1 135135232 16 0 262144 0;}  /* Style Definitions
*/
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:SimSun;
	mso-hansi-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-fareast-language:ZH-CN;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";
	color:blue;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:SimSun;
	mso-hansi-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-fareast-language:ZH-CN;}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1027"/> </xml><![endif]--><!--[if
gte mso 9]><xml>  <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=white lang=EN-US style='tab-interval:.5in'>

<div class=Section1>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Greetin
gs,<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Respons
e below ¡<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 color=black
face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Zhang Yi
[mailto:[email-masked]]<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, May 07, 2001
11:51 PM<br>
<b><span style='font-weight:bold'>To:</span></b> sigtran<br> <b><span
style='font-weight:bold'>Subject:</span></b> M3UA Sample Configuration
question</span></font><font color=navy><span
style='color:navy;mso-color-alt: windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 color=navy
face=SimSun><span style='font-size:12.0pt;color:navy'><![if
!supportEmptyParas]>&nbsp;<![endif]></span></font><font color=navy><span
style='color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=4 color=black
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman"; color:black'>Hi, all,</span></font><font color=navy><span
style='color:navy; mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=4 color=black
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman"; color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In M3UA draft 06, the
M3UA endpoint to endpoint configuration is described at section 1.5.2 as
Example 2: SCCP Transport between IPSPs. But there is no further description
to how the two M3UA instance present in two IPSPs set up their
communication. It looks that the AS, ASP status management procedure
(described in section 4.3) is not applicable in this case.
</span></font><font size=4 color=navy face="Times New Roman"><span
style='font-size:13.5pt;font-family:"Times New Roman";
color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal style='margin-left:.5in'><font size=4 color=black
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman"; color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So, what's
procedure shall be used for two IPSPs? Shall only association status between
two IPSPs be taken into consideration? </span></font><font color=navy><span
style='color:navy; mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt;font-family:"Times New
Roman"; mso-ascii-font-family:SimSun;color:black'>&nbsp;</span></font><font
color=navy><span
style='color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=4 color=black
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman"; color:black'>Yours</span></font><font color=navy><span
style='color:navy; mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=4 color=black
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman"; color:black'>ZhangYi</span></font><font size=4 color=navy
face="Times New Roman"><span style='font-size:13.5pt;font-family:"Times New
Roman";color:navy;mso-color-alt: windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>[Greg]
<span style="mso-spacerun: yes">&nbsp;</span>Hmmm, the general assumption
has always been that the protocol for point-to-point is no different, except
as noted in sections 1.5.2 and 1.4.3.3 that imply that SSNM messaging
wouldn' t be used. <span style="mso-spacerun: yes">&nbsp;</span>But I admit
the procedural description mainly centers around the SG/ASP case and various
people have correctly stated that the point-to-point case could be given
some more description.<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Section
4.3.1 (AS and ASP State Maintenance) says
<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><o:p></o:p></span></font></span></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span>&quot;Similarly, where IPSPs use M3UA in a point-to-point
fashion, the <o:p></o:p></span></font></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span>M3UA layer in an IPSP maintains the
state of remote IPSPs. For <o:p></o:p></span></font></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span>the purposes of the following
procedures, only the SG/ASP case is <o:p></o:p></span></font></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span>described but the SG side of the
procedures also apply to an IPSP<o:p></o:p></span></font></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span>sending traffic to an AS consisting
of a set of remote IPSPs.&quot;</span><o:p></o:p></font></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>So I
think that answers your question, even though it could be argued that the
text doesn't explicitly cover the case where there is only a single remote
IPSP in an AS. <span style="mso-spacerun: yes">&nbsp;</span>I'll add an
explicit statement right up front in Section
4.3:<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span>&quot;These
procedures support the M3UA management of SCTP Associations
<o:p></o:p></span></font></p>

<p class=MsoPlainText style='margin-right:48.1pt'><font size=2 color=blue
face="Courier New"><span style='font-size:10.0pt;mso-fareast-font-family:"MS
Mincho"'><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span><span
style="mso-spacerun: yes">&nbsp;</span>between SGs and ASPs or between
IPSPs.&quot;</span><o:p></o:p></font></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I'll
also do a pass through the spec to see if there is anywhere else where
changes can be made to make the point-to-point case
clearer.<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><span
style="mso-spacerun: yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span><span style="mso-spacerun:
yes">&nbsp;</span>Greg<o:p></o:p></span></font></span></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt;font-family:"Times New
Roman"; mso-ascii-font-family:SimSun;color:black'>&nbsp;</span></font><font
color=navy><span
style='color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</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>
From: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 16:54:55 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate4.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate4.mot.com [144.189.100.102]
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 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.19">
<TITLE>RE: SUA5: Address Mapping text</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Thanks Gery.&nbsp; I completely agree with you.&nbsp; Enen
though it is very simple, I still hope to see it somewhere in the SUA
spec.</FONT></P>

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

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Friday, May 11, 2001 5:13
AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt;
Subject: RE: SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Michael,</FONT> <BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Simple : in an all IP-environment, you may also route
on GT </FONT> <BR><FONT SIZE=2>&gt; or hostname. The</FONT> <BR><FONT
SIZE=2>&gt; AMF then has the responsibility of mapping this to an SCTP
association</FONT> <BR><FONT SIZE=2>&gt; (IP-address) and either the same
GT/hostname or a new one </FONT> <BR><FONT SIZE=2>&gt; (the
destination</FONT> <BR><FONT SIZE=2>&gt; might also be a relay node)
!!</FONT> <BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; greetings,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ____________________________ </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 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>&gt;
Fax : +32 14 25 3212 </FONT> <BR><FONT SIZE=2>&gt; <A
HREF="mailto:g">mailto:g</A> &lt;<A HREF="mailto:g">mailto:g</A>&gt;
[email-masked] </FONT> <BR><FONT SIZE=2>&gt;
____________________________________ </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: Young Michael-Y10724 [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</
A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: vrijdag 11 mei 2001 2:41</FONT>
<BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: RE:
SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi John, </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is still not clear to me that how address
translation and </FONT> <BR><FONT SIZE=2>&gt; mapping is done</FONT>
<BR><FONT SIZE=2>&gt; in an all ip environment.&nbsp; I am not sure if you
intend to </FONT> <BR><FONT SIZE=2>&gt; cover this under</FONT> <BR><FONT
SIZE=2>&gt; this section.&nbsp; Meanwhile, please see my other comments
inserted below.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; BR, </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Michael Young </FONT> <BR><FONT SIZE=2>&gt;
--------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>&gt; System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>&gt; Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1
(604)726-6609 </FONT> <BR><FONT SIZE=2>&gt; Email:
[email-masked] </FONT> <BR><FONT SIZE=2>&gt;
--------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message----- </FONT> <BR><FONT
SIZE=2>&gt; &gt; From: [email-masked] [ <A
HREF="mailto:[email-masked]">mailto:[email-masked]</A></FO
NT> <BR><FONT SIZE=2>&gt; &lt;<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>&gt;
] </FONT> <BR><FONT SIZE=2>&gt; &gt; Sent: Thursday, May 10, 2001 3:17 AM
</FONT> <BR><FONT SIZE=2>&gt; &gt; To: sigtran </FONT> <BR><FONT SIZE=2>&gt;
&gt; Subject: SUA5: Address Mapping text </FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi all, </FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; There has been some discussion as of late on SUA
/ GTT / ENUM </FONT> <BR><FONT SIZE=2>&gt; &gt; / etc.&nbsp; I have </FONT>
<BR><FONT SIZE=2>&gt; &gt; updated the text.&nbsp; Please comment. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; br, </FONT>
<BR><FONT SIZE=2>&gt; &gt; John </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1.5 Internal Functions Provided in the SUA Layer
</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It is assumed that Global Title Translation (GTT)
occurs </FONT> <BR><FONT SIZE=2>&gt; &gt; outside of SUA. </FONT> <BR><FONT
SIZE=2>&gt; &gt; However, SUA will need to map the output of the GTT
process, when </FONT> <BR><FONT SIZE=2>&gt; &gt; applicable, to an ASP via
an Address Mapping Function (AMF).&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; When SS7 addressing is used by the upper layer
protocol, SUA </FONT> <BR><FONT SIZE=2>&gt; &gt; will need to </FONT>
<BR><FONT SIZE=2>&gt; &gt; determine the correct signaling endpoint.&nbsp;
How this is done is </FONT> <BR><FONT SIZE=2>&gt; &gt; implementation
specific, but it could involve DNS [ENUM] or local </FONT> <BR><FONT
SIZE=2>&gt; &gt; configuration information. </FONT> <BR><FONT SIZE=2>&gt;
&gt; </FONT>
<BR><FONT SIZE=2>&gt; [MYH] ==&gt; &quot;DNS [ENUM] and/or local
configuration information.&quot; </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1.5.1 Address Translation and Mapping at the SG
</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The SG MUST provide address translation and
mapping functions </FONT> <BR><FONT SIZE=2>&gt; &gt; to direct </FONT>
<BR><FONT SIZE=2>&gt; &gt; messages received from the SS7 network to the
appropriate IP </FONT> <BR><FONT SIZE=2>&gt; &gt; destination. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In order to support message distribution, the SG
maintains </FONT> <BR><FONT SIZE=2>&gt; an address </FONT> <BR><FONT
SIZE=2>&gt; &gt; translation table, which maps the incoming SS7 messages to
</FONT> <BR><FONT SIZE=2>&gt; &gt; the appropriate </FONT> <BR><FONT
SIZE=2>&gt; &gt; AS.&nbsp; The relevant fields of the incoming SS7 message
is </FONT> <BR><FONT SIZE=2>&gt; &gt; compared to the </FONT> <BR><FONT
SIZE=2>&gt; &gt; existing Routing Keys.&nbsp; The Routing Keys reference an
</FONT> <BR><FONT SIZE=2>&gt; &gt; Application Server, </FONT> <BR><FONT
SIZE=2>&gt; &gt; which will have one or more ASPs processing traffic for the
</FONT> <BR><FONT SIZE=2>&gt; AS.&nbsp; The </FONT> <BR><FONT SIZE=2>&gt;
&gt; availability and status of the ASPs is handled by SUA ASP </FONT>
<BR><FONT SIZE=2>&gt; management </FONT> <BR><FONT SIZE=2>&gt; &gt;
messages. </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Possible SS7 address/routing information that
comprise </FONT> <BR><FONT SIZE=2>&gt; &gt; a Routing Key entry includes,
for example, OPC, DPC, SIO found in </FONT> <BR><FONT SIZE=2>&gt; &gt; the
MTP3 routing label, or other specific fields such as the </FONT> <BR><FONT
SIZE=2>&gt; &gt; SCCP subsystem number, or TCAP transaction ID. Some </FONT>
<BR><FONT SIZE=2>&gt; &gt; possibilities include: </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Global Title
(+ SSN optionally) </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PC (+ SSN optionally) </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Host Name (+
SSN optionally) </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP Address(es) (+ SSN optionally)
</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [MYH] My understanding is that in case of IP address
the SSN should be</FONT> <BR><FONT SIZE=2>&gt; mandatory to identify the
correct SSN. </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; An Application Server maintains a list of ASPs
that are </FONT> <BR><FONT SIZE=2>&gt; &gt; available to process </FONT>
<BR><FONT SIZE=2>&gt; &gt; the traffic.&nbsp; The list is dynamic, based
upon the </FONT> <BR><FONT SIZE=2>&gt; availability of the </FONT> <BR><FONT
SIZE=2>&gt; &gt; individual ASPs in the list.&nbsp; SUA ASP management
messages are </FONT> <BR><FONT SIZE=2>&gt; &gt; used to convey </FONT>
<BR><FONT SIZE=2>&gt; &gt; the status of these ASPs and their availability
in failover </FONT> <BR><FONT SIZE=2>&gt; &gt; situations. </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Normally, one or more ASPs areis active in the
ASP (i.e., currently </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [MYH] Typo here, &quot;areis&quot; --&gt;
&quot;are&quot;; the second ASP should be &quot;AS&quot; </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; processing traffic) but in certain failure and
transition </FONT> <BR><FONT SIZE=2>&gt; cases it is </FONT> <BR><FONT
SIZE=2>&gt; &gt; possible that there may not be an active ASP available. The
</FONT> <BR><FONT SIZE=2>&gt; &gt; SG will buffer </FONT> <BR><FONT
SIZE=2>&gt; &gt; the message destined for this AS for a time T(r) or until
an </FONT> <BR><FONT SIZE=2>&gt; &gt; ASP becomes </FONT> <BR><FONT
SIZE=2>&gt; &gt; available. When no ASP becomes available before expiry of
</FONT> <BR><FONT SIZE=2>&gt; &gt; t(r), the SG will </FONT> <BR><FONT
SIZE=2>&gt; &gt; flush the buffered messages and initiate the appropriate
</FONT> <BR><FONT SIZE=2>&gt; &gt; return or refusal </FONT> <BR><FONT
SIZE=2>&gt; &gt; procedures. </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Both load-sharing and backup scenarios are
supported. </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; If there is no Routing Key match for an incoming
SS7 message, </FONT> <BR><FONT SIZE=2>&gt; &gt; a default </FONT> <BR><FONT
SIZE=2>&gt; &gt; treatment MUST be specified.&nbsp; Possible solutions are
to </FONT> <BR><FONT SIZE=2>&gt; &gt; provide a default </FONT> <BR><FONT
SIZE=2>&gt; &gt; Application Server to direct all unallocated traffic to a
</FONT> <BR><FONT SIZE=2>&gt; &gt; (set of) default </FONT> <BR><FONT
SIZE=2>&gt; &gt; ASP(s), or to drop the messages and provide a notification
to </FONT> <BR><FONT SIZE=2>&gt; &gt; management. </FONT> <BR><FONT
SIZE=2>&gt; &gt; The treatment of unallocated traffic is implementation
dependent. </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1.5.2 Address Translation and Mapping at the ASP
</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In order to direct messages to the SS7 network,
the ASP must </FONT> <BR><FONT SIZE=2>&gt; &gt; also perform an </FONT>
<BR><FONT SIZE=2>&gt; &gt; address translation and mapping function in order
to choose </FONT> <BR><FONT SIZE=2>&gt; &gt; the proper SG or </FONT>
<BR><FONT SIZE=2>&gt; &gt; SGP for a given message.&nbsp; This is
accomplished by observing </FONT> <BR><FONT SIZE=2>&gt; &gt; the Destination
</FONT> <BR><FONT SIZE=2>&gt; &gt; Point Code and other elements of the
outgoing message, SS7 </FONT> <BR><FONT SIZE=2>&gt; &gt; network status,
</FONT> <BR><FONT SIZE=2>&gt; &gt; SG and SGP availability, and network
appearance </FONT> <BR><FONT SIZE=2>&gt; configuration tables. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; A remote Signaling Gateway may be composed of one
or more </FONT> <BR><FONT SIZE=2>&gt; &gt; SGPs.&nbsp; that are </FONT>
<BR><FONT SIZE=2>&gt; &gt; capable of routing SS7 traffic.&nbsp; As is the
case with ASPs, a </FONT> <BR><FONT SIZE=2>&gt; &gt; dynamic list of </FONT>
<BR><FONT SIZE=2>&gt; &gt; SGPs in an SG can be maintained, taking into
account the </FONT> <BR><FONT SIZE=2>&gt; &gt; availability status </FONT>
<BR><FONT SIZE=2>&gt; &gt; of the individual SGPs, configuration changes and
fail-over </FONT> <BR><FONT SIZE=2>&gt; &gt; mechanisms. </FONT> <BR><FONT
SIZE=2>&gt; &gt; There is, however, no SUA messaging to manage the status of
</FONT> <BR><FONT SIZE=2>&gt; &gt; an SGP. Whenever </FONT> <BR><FONT
SIZE=2>&gt; &gt; an SCTP association to an SGP exists, it is assumed to be
</FONT> <BR><FONT SIZE=2>&gt; &gt; available.&nbsp; Also, </FONT> <BR><FONT
SIZE=2>&gt; &gt; every SGP of one SG communicating with one ASP regarding
one </FONT> <BR><FONT SIZE=2>&gt; &gt; AS provides </FONT> <BR><FONT
SIZE=2>&gt; &gt; identical SS7 connectivity to this ASP. </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1.5.3 SCTP Stream Mapping </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The SUA supports SCTP streams. The SG/AS needs to
maintain a </FONT> <BR><FONT SIZE=2>&gt; &gt; list of SCTP </FONT> <BR><FONT
SIZE=2>&gt; &gt; and SUA-users for mapping purposes.&nbsp; SCCP-users
requiring </FONT> <BR><FONT SIZE=2>&gt; &gt; sequenced message </FONT>
<BR><FONT SIZE=2>&gt; &gt; transfer need to be sent over a stream supporting
sequenced </FONT> <BR><FONT SIZE=2>&gt; delivery. </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; SUA MUST use stream 0 for SUA management
messages. It is </FONT> <BR><FONT SIZE=2>&gt; &gt; recommended that </FONT>
<BR><FONT SIZE=2>&gt; &gt; sequenced delivery is usedbe in order to preserve
the order </FONT> <BR><FONT SIZE=2>&gt; &gt; of management </FONT> <BR><FONT
SIZE=2>&gt; &gt; message delivery. </FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; --- </FONT>
<BR><FONT SIZE=2>&gt; &gt; You are currently subscribed to sigtran as:
</FONT> <BR><FONT SIZE=2>&gt; [email-masked] </FONT> <BR><FONT
SIZE=2>&gt; &gt; To unsubscribe send a blank email to </FONT> <BR><FONT
SIZE=2>&gt; &gt; [email-masked] </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as: </FONT>
<BR><FONT SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; To unsubscribe send a blank email to</FONT> <BR><FONT
SIZE=2>&gt; [email-masked] </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, 
    Young Michael-Y10724 <[email-masked]>, 
    [email-masked]
Subject: RE: TR29.903 SUA Feasibility Study
Date: Fri, 11 May 2001 17:41:21 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: ftpbox.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ftpbox.mot.com [129.188.136.101]
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.2654.19">
<TITLE>RE: TR29.903 SUA Feasibility Study</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Thanks for your comprehensive comments, I agree with your
principles however I don't want to mix GTT of SCCP and AMF of SUA in the SUA
spec.</FONT></P>

<P><FONT SIZE=2>My original statement is &quot;The investigation we have
done shows SUA can effectively replace SCCP/M3UA except GTT, which is out of
the scope of SUA.&nbsp; That's also why AMF (Address Mapping Function) is
introduced and refered in SUA spec.&quot;.&nbsp; What I am tryint to say is
the term GTT is out of SUA spec, and AMF in SUA covers all the functionality
of GTT in SCCP.&nbsp; Therefore,&nbsp; I like your statement &quot;the AMF
(in SUA) replaces the GTT in the SCCP recommendations.&quot;</FONT></P>

<P><FONT SIZE=2>There is no doubt that both relay functionality and address
translation/mapping functionality (AMF) are clearly specified in current SUA
spec (refer to section 1.4 &amp; 1.5).&nbsp; I agree how to realise AMF
should be implementation dependent.</FONT></P>

<P><FONT SIZE=2>As to loadsharing, the SUA spec. shall not limit any
implementation, eg. TID can only be an example.</FONT> </P>

<P><FONT SIZE=2>Have a nice weekend,</FONT> </P>

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Friday, May 11, 2001 4:52
AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Cc:
[email-masked]'; Michael.Young; </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; Subject: RE:
TR29.903 SUA Feasibility Study</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello Thomas,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The SCCP procedures describing GTT assume that the
database </FONT> <BR><FONT SIZE=2>&gt; is integrated.</FONT> <BR><FONT
SIZE=2>&gt; For SUA, the AMF (Address Mapping Function) is there to model
</FONT> <BR><FONT SIZE=2>&gt; the integrated</FONT> <BR><FONT SIZE=2>&gt;
database, without any restriction on access methods used by </FONT>
<BR><FONT SIZE=2>&gt; SUA internally</FONT> <BR><FONT SIZE=2>&gt; to perform
its relay functions. As such, the AMF replaces the </FONT> <BR><FONT
SIZE=2>&gt; GTT in the</FONT> <BR><FONT SIZE=2>&gt; SCCP
recommendations.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The term out-of-scope is too strong : relay
functionality and </FONT> <BR><FONT SIZE=2>&gt; support of GTT</FONT>
<BR><FONT SIZE=2>&gt; (or hostname translation for that matter) is indeed IN
the </FONT> <BR><FONT SIZE=2>&gt; scope of SUA.</FONT> <BR><FONT SIZE=2>&gt;
What we don't want to do is describe how this support is </FONT> <BR><FONT
SIZE=2>&gt; realized, but only</FONT> <BR><FONT SIZE=2>&gt; :</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - valid input/output to/from this AMF (based on the
rules in </FONT> <BR><FONT SIZE=2>&gt; Q.714 for SCCP)</FONT> <BR><FONT
SIZE=2>&gt; - hop counter procedures (protection against loops)</FONT>
<BR><FONT SIZE=2>&gt; - rules for loadsharing or primary/backup routing,
possibly </FONT> <BR><FONT SIZE=2>&gt; using the TCAP</FONT> <BR><FONT
SIZE=2>&gt; destination TID</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; John, working with an external database accessed by
your SUA </FONT> <BR><FONT SIZE=2>&gt; is proprietary</FONT> <BR><FONT
SIZE=2>&gt; and actually this database will belong to your
&quot;system&quot; (one </FONT> <BR><FONT SIZE=2>&gt; black box).</FONT>
<BR><FONT SIZE=2>&gt; When building a network, you may have a central
GT-database </FONT> <BR><FONT SIZE=2>&gt; but this will be</FONT> <BR><FONT
SIZE=2>&gt; regarded as an SUA-relay point (STP in SS7 terminology), so
</FONT> <BR><FONT SIZE=2>&gt; there is no</FONT> <BR><FONT SIZE=2>&gt;
decoupling of SUA and AMF =&gt; these will be considered as </FONT>
<BR><FONT SIZE=2>&gt; existing together</FONT> <BR><FONT SIZE=2>&gt; on an
SUA host which has relay functionality. SUA host with </FONT> <BR><FONT
SIZE=2>&gt; only end-point</FONT> <BR><FONT SIZE=2>&gt; functionality won't
be able to route on GT or hostname; I </FONT> <BR><FONT SIZE=2>&gt; want to
clearly</FONT> <BR><FONT SIZE=2>&gt; stress this definition.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Again, how you realize this AMF is out of scope of the
SUA </FONT> <BR><FONT SIZE=2>&gt; specification :</FONT> <BR><FONT
SIZE=2>&gt; local tables, using DNS, Oracle database connected to your box,
...</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As a note : in SCCP an interface for external GT
translation </FONT> <BR><FONT SIZE=2>&gt; was also never</FONT> <BR><FONT
SIZE=2>&gt; standardized. Reasons :</FONT> <BR><FONT SIZE=2>&gt; - there is
no need for it (concept of relay functionality) =&gt; SRF</FONT> <BR><FONT
SIZE=2>&gt; - use of existing protocols for database access =&gt; IN/MAP; or
</FONT> <BR><FONT SIZE=2>&gt; in IP-case :</FONT> <BR><FONT SIZE=2>&gt; DNS,
... LDAP</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So SUA and AMF are integrated just as SCCP and GTT are
</FONT> <BR><FONT SIZE=2>&gt; intergrated. It is</FONT> <BR><FONT
SIZE=2>&gt; the operator who controls the size and scope of his database.
Some SUA</FONT> <BR><FONT SIZE=2>&gt; endpoints might, for their relay
functionality, by default </FONT> <BR><FONT SIZE=2>&gt; select an SUA</FONT>
<BR><FONT SIZE=2>&gt; peer with an extensive AMF; in other words, operate
with a </FONT> <BR><FONT SIZE=2>&gt; real thin/default</FONT> <BR><FONT
SIZE=2>&gt; AMF.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Any comments on this opinion ?</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ____________________________</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gery Verwimp</FONT> <BR><FONT SIZE=2>&gt; &gt; SIEMENS
ATEA</FONT> <BR><FONT SIZE=2>&gt; &gt; ICN D CS D5</FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel. : +32 14 25 3424</FONT> <BR><FONT
SIZE=2>&gt; Fax : +32 14 25 3212</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>&gt;
____________________________________</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: Koenig Thomas [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
de</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: donderdag 10 mei 2001
14:21</FONT> <BR><FONT SIZE=2>&gt; To: Verwimp Gery; Coene Lode</FONT>
<BR><FONT SIZE=2>&gt; Subject: WG: TR29.903 SUA Feasibility Study</FONT>
<BR><FONT SIZE=2>&gt; Importance: High</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dear Gery, Dear Lode,</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; could you please check till tomorrow the France
Telecom </FONT> <BR><FONT SIZE=2>&gt; review comment and</FONT> <BR><FONT
SIZE=2>&gt; Michaels reply on the 3GPP SUA feasibility study?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Why is GTT out of scope of SUA as Michael writes?
</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks in advance !</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; Thomas König</FONT> <BR><FONT SIZE=2>&gt;
____________________________________</FONT> <BR><FONT SIZE=2>&gt; s</FONT>
<BR><FONT SIZE=2>&gt; &gt; Information &amp; Communication Mobile</FONT>
<BR><FONT SIZE=2>&gt; &gt; Networks Mobile Core</FONT> <BR><FONT SIZE=2>&gt;
ICM N MC CP SE 2</FONT> <BR><FONT SIZE=2>&gt; Hfd/LS11</FONT>
<BR><FONT SIZE=2>&gt; Phone:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49
6621 169-178</FONT> <BR><FONT SIZE=2>&gt; Fax:&nbsp; +49 6621 169-225</FONT>
<BR><FONT SIZE=2>&gt; E-Mail: [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; Von:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Schmitt Peter </FONT> <BR><FONT SIZE=2>&gt; &gt; Gesendet
am:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Donnerstag, 10. Mai 2001
09:48</FONT> <BR><FONT SIZE=2>&gt; &gt; An: Koenig Thomas</FONT> <BR><FONT
SIZE=2>&gt; &gt; Betreff:&nbsp;&nbsp;&nbsp; WG: TR29.903 SUA Feasibility
Study</FONT> <BR><FONT SIZE=2>&gt; &gt;
Wichtigkeit:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hoch</FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hallo Thomas;</FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; bitte mit Atea kolleghen Diskutieren!</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Response bis Freitag 11.05.01 17:00</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp; &lt;&lt;N4-010563.zip&gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Gruss Peter</FONT> <BR><FONT SIZE=2>&gt; &gt;
Kind Regards / Mit Freundlichen Grüssen</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Peter Schmitt </FONT> <BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt;
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; --------------</FONT> <BR><FONT SIZE=2>&gt;
------</FONT>
<BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Siemens AG </FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Information &amp; Communication
Mobile</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ICM N MC CP SE 2</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel.: +496621169152</FONT> <BR><FONT
SIZE=2>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +496621169225</FONT> <BR><FONT
SIZE=2>&gt; &gt; Peter
Schmitt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mail:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; Von:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Young Michael-Y10724 [SMTP:[email-masked]]</FONT> <BR><FONT
SIZE=2>&gt; &gt; Gesendet am:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Donnerstag, 10. Mai 2001 04:06</FONT> <BR><FONT SIZE=2>&gt; &gt; An:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt;
Betreff:&nbsp;&nbsp;&nbsp; Re: TR29.903 SUA Feasibility Study</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; Dear Francois, </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks for your comments, please see my reply
inserted below.</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; BR,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Michael Young</FONT> <BR><FONT SIZE=2>&gt; &gt;
---------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; &gt; System Design, GTSS Vancouver, Motorola</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1
(604)726-6609</FONT> <BR><FONT SIZE=2>&gt; &gt; Email:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt;
--------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; &gt; From: DRONNE Francois FTRD/DMR/ISS</FONT> <BR><FONT
SIZE=2>&gt; [<A
HREF="mailto:[email-masked]">mailto:francois.dronne@RD.
FRANCETELECOM.FR</A>]</FONT> <BR><FONT SIZE=2>&gt; &gt; Sent: Monday, May
07, 2001 3:04 AM</FONT> <BR><FONT SIZE=2>&gt; &gt; To:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt; Subject: Re:
TR29.903 SUA Feasibility Study</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Dear Michael,</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; I fully disagree with the
chapter &quot;8.4 Mobility Number </FONT> <BR><FONT SIZE=2>&gt;
Portability&quot; where</FONT> <BR><FONT SIZE=2>&gt; it is written that the
&quot;MNP uses MAP protocol to provide the service&quot;.</FONT> <BR><FONT
SIZE=2>&gt; &gt; Actually, most of the service is supported by the SCCP
</FONT> <BR><FONT SIZE=2>&gt; layer, as described</FONT> <BR><FONT
SIZE=2>&gt; in the 23.066. The SRF function does look at the SCCP to </FONT>
<BR><FONT SIZE=2>&gt; check the nature of</FONT> <BR><FONT SIZE=2>&gt; the
message received (use of the TT parameter) and also to </FONT> <BR><FONT
SIZE=2>&gt; check the address</FONT> <BR><FONT SIZE=2>&gt; of the subscriber
(CdPA = MSISDN).</FONT> <BR><FONT SIZE=2>&gt; &gt; Therefore, the fact that
SUA &quot;fully supports TCAP and MAP&quot; </FONT> <BR><FONT SIZE=2>&gt; is
not enough</FONT> <BR><FONT SIZE=2>&gt; and I suggest you to investigate
more on this very sensitive point.</FONT> <BR><FONT SIZE=2>&gt; &gt; [Young
Michael-Y10724] The investigation we have done shows SUA can</FONT>
<BR><FONT SIZE=2>&gt; effectively replace SCCP/M3UA except GTT, which is out
of the </FONT> <BR><FONT SIZE=2>&gt; scope of SUA.</FONT> <BR><FONT
SIZE=2>&gt; That's also why AMF (Address Mapping Function is introduced
</FONT> <BR><FONT SIZE=2>&gt; and refered in</FONT> <BR><FONT SIZE=2>&gt;
SUA spec).&nbsp; As to SRF, which is one of the two options to </FONT>
<BR><FONT SIZE=2>&gt; implement MNP:</FONT> <BR><FONT SIZE=2>&gt; IN-based
or SRF-based.&nbsp; SRF stands for Signalling Relay Function, it</FONT>
<BR><FONT SIZE=2>&gt; actually means that a SCCP message sent to an HLR may
need to </FONT> <BR><FONT SIZE=2>&gt; be relayed by</FONT> <BR><FONT
SIZE=2>&gt; an MNP-SRF node.&nbsp;&nbsp; Message relay is a standard
mechanism </FONT> <BR><FONT SIZE=2>&gt; provided by SCCP</FONT> <BR><FONT
SIZE=2>&gt; and it is also the basic service provided by SUA (Please </FONT>
<BR><FONT SIZE=2>&gt; refer to section</FONT> <BR><FONT SIZE=2>&gt; 1.4.6
Relay function under section 1.4 Services provided by </FONT> <BR><FONT
SIZE=2>&gt; the SUA layer).</FONT> <BR><FONT SIZE=2>&gt; The actually MNP
service is provided by utilizing several MAP </FONT> <BR><FONT SIZE=2>&gt;
procedures and</FONT> <BR><FONT SIZE=2>&gt; messages.&nbsp; However, the
statements in 29.903 might not be </FONT> <BR><FONT SIZE=2>&gt; very
accurate and</FONT> <BR><FONT SIZE=2>&gt; any rewording is welcome. </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; I also
have questions for my clarification :</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; 1/ Chapters 7.1.2.1 , you
mentionned that the AMF function </FONT> <BR><FONT SIZE=2>&gt; uses the
E.164</FONT> <BR><FONT SIZE=2>&gt; address with the SSN to find the
corresponding IP address. </FONT> <BR><FONT SIZE=2>&gt; But the
routing</FONT> <BR><FONT SIZE=2>&gt; on Global Title (with E.164 address) is
also possible without </FONT> <BR><FONT SIZE=2>&gt; SSN. Do you</FONT>
<BR><FONT SIZE=2>&gt; intend to change the SSN to be mandatory in SCCP, when
</FONT> <BR><FONT SIZE=2>&gt; routing on GT?&gt; </FONT> <BR><FONT
SIZE=2>&gt; &gt; [Young Michael-Y10724]&nbsp; I don't think SSN is mandatory
in SCCP when</FONT> <BR><FONT SIZE=2>&gt; routing on GT, it actually depends
on different cases.&nbsp; Below is my</FONT> <BR><FONT SIZE=2>&gt;
understanding, please correct me if I am wrong. </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In current SS7 network, the use of SSN is a
network </FONT> <BR><FONT SIZE=2>&gt; operator option and</FONT> <BR><FONT
SIZE=2>&gt; values for intra-PLMN usage are network specific. However
</FONT> <BR><FONT SIZE=2>&gt; SSNs have been</FONT> <BR><FONT SIZE=2>&gt;
reserved for inter-PLMN use, as defined in 3GPP TS 23.003. </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The addressing elements consist of information
contained within the</FONT> <BR><FONT SIZE=2>&gt; Calling and the Called
Party Addresses which are sent by the </FONT> <BR><FONT SIZE=2>&gt;
application to</FONT> <BR><FONT SIZE=2>&gt; the lower layers. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The application expects the SCCP to route
messages by </FONT> <BR><FONT SIZE=2>&gt; either (a) the use</FONT>
<BR><FONT SIZE=2>&gt; of the Destination Point Code (DPC) plus the Subsystem
Number </FONT> <BR><FONT SIZE=2>&gt; (SSN), or (b)</FONT> <BR><FONT
SIZE=2>&gt; the use of the GT plus optionally the SSN. The application
</FONT> <BR><FONT SIZE=2>&gt; also specifies to</FONT> <BR><FONT SIZE=2>&gt;
the lower layer whether to route the message on the DPC or the GT.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Method (a) above may be used when the application
is aware of the</FONT> <BR><FONT SIZE=2>&gt; destination point code and the
destination SSN located at </FONT> <BR><FONT SIZE=2>&gt; that point code
to</FONT> <BR><FONT SIZE=2>&gt; which the message is to be delivered. Within
a national </FONT> <BR><FONT SIZE=2>&gt; network different</FONT> <BR><FONT
SIZE=2>&gt; SSNs, according to ITU-T SCCP recommendation Q.713, may be
</FONT> <BR><FONT SIZE=2>&gt; allocated for the</FONT> <BR><FONT SIZE=2>&gt;
different network specific applications.</FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; Method (b) above may be used when a message is to
be delivered to a</FONT> <BR><FONT SIZE=2>&gt; SCCP-user which can be
identified by the combination of the </FONT> <BR><FONT SIZE=2>&gt; elements
within</FONT> <BR><FONT SIZE=2>&gt; the GT. An example of the use of this
method is when messages </FONT> <BR><FONT SIZE=2>&gt; have to be</FONT>
<BR><FONT SIZE=2>&gt; delivered between different networks. This method may
be used </FONT> <BR><FONT SIZE=2>&gt; since the</FONT>
<BR><FONT SIZE=2>&gt; originating network is unaware of the point code and
SSN's allocations</FONT> <BR><FONT SIZE=2>&gt; within the destination
network. The network that determines </FONT> <BR><FONT SIZE=2>&gt; the
end-node to</FONT> <BR><FONT SIZE=2>&gt; which the message is to be
delivered has to perform a GT </FONT> <BR><FONT SIZE=2>&gt; Translation
to</FONT> <BR><FONT SIZE=2>&gt; derive the destination Point Code and the
SSN. If optionally </FONT> <BR><FONT SIZE=2>&gt; the original</FONT>
<BR><FONT SIZE=2>&gt; address contained the SSN, then this may be used as
the </FONT> <BR><FONT SIZE=2>&gt; destination SSN, or</FONT> <BR><FONT
SIZE=2>&gt; the translation may, if required, provide an appropriate new
SSN. </FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt;
&gt; 2/ Chapter 7.1.2.1 again, you describe the query to an ENUM </FONT>
<BR><FONT SIZE=2>&gt; server. To my</FONT> <BR><FONT SIZE=2>&gt;
comprehension, this mechanism seems to bring complexity, </FONT> <BR><FONT
SIZE=2>&gt; compares to the</FONT> <BR><FONT SIZE=2>&gt; classical routing
procedures based on the first digits (CC + </FONT> <BR><FONT SIZE=2>&gt;
NDC). Am I</FONT> <BR><FONT SIZE=2>&gt; right?</FONT>
<BR><FONT SIZE=2>&gt; &gt; [Young Michael-Y10724] In section 7.1.2.1, it
utilises the&nbsp; </FONT> <BR><FONT SIZE=2>&gt; standard ENUM</FONT>
<BR><FONT SIZE=2>&gt; service to find out the IP address associated with the
E164 </FONT> <BR><FONT SIZE=2>&gt; number, it is</FONT> <BR><FONT
SIZE=2>&gt; almost one time process.&nbsp; I don't think this is more
complex </FONT> <BR><FONT SIZE=2>&gt; than current</FONT> <BR><FONT
SIZE=2>&gt; routing mechanism based on GMT (E214). </FONT> <BR><FONT
SIZE=2>&gt; &gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; Thank you in
advance for your answer.</FONT> <BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Best Regards,</FONT> <BR><FONT SIZE=2>&gt;
&gt;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; François DRONNE</FONT>
<BR><FONT SIZE=2>&gt; &gt; France Telecom</FONT> <BR><FONT SIZE=2>&gt; &gt;
</FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; -----Message
d'origine-----</FONT> <BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; De :
Young Michael-Y10724 [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</
A>]</FONT> <BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Envoyé : samedi 5
mai 2001 07:47</FONT> <BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; À :
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; &gt;
&nbsp;&nbsp;&nbsp; Objet : TR29.903 SUA Feasibility Study</FONT> <BR><FONT
SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt;
&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Dear CN4 colleagues, </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Please see the preliminary
release of the subject item </FONT> <BR><FONT SIZE=2>&gt; enclosed.&nbsp;
I</FONT> <BR><FONT SIZE=2>&gt; would appreciate if you can provide the
comments before I make&nbsp; final</FONT> <BR><FONT SIZE=2>&gt; submission
to CN4 meeting next Tuesday.</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Thanks &amp; have a nice
weekend, </FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Michael Young </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp;
--------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; System Design, GTSS Vancouver,
Motorola </FONT> <BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Tel: +1
(604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609 </FONT> <BR><FONT
SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; Email: [email-masked]
</FONT> <BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp;
--------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &nbsp;&nbsp;&nbsp; &nbsp; </FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 17:11:32 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: ftpbox.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ftpbox.mot.com [129.188.136.101]
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.19">
<TITLE>RE: SUA5: Address Mapping text</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Have a nice weekend,</FONT> </P>

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Friday, May 11, 2001 5:03
AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt;
Subject: RE: SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2 comments :</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - with DPC or IP address, ALWAYS a valid SSN has to be
</FONT> <BR><FONT SIZE=2>&gt; present. With this</FONT> <BR><FONT
SIZE=2>&gt; the end-SUA has to address it's user; we have to keep this
</FONT> <BR><FONT SIZE=2>&gt; interface with</FONT> <BR><FONT SIZE=2>&gt;
the user.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>[MYH} I agree.</FONT>
</P>

<P><FONT SIZE=2>&gt; - does an ASP still have to know the concept of SG-SGP
?</FONT> </P>

<P><FONT SIZE=2>[MYH] It depends.&nbsp; If the operator is willing to expose
its network topology and free to have all its network signalling nodes to
establish SCTP associations with outside network, I don't think ASP need to
know the concept of SG-SGP.&nbsp; However, the concept of SG-SGP in all ip
scenario is debatable.&nbsp; The operator might just want to have&nbsp; one
or more boarder gateway(s) sitting at the edge of its network to interact
with outside world by relaying SUA msgs.&nbsp; Why not name this guy
&quot;SUA Relay Node&quot;?</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; greetings,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ____________________________</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gery Verwimp</FONT> <BR><FONT SIZE=2>&gt; &gt; SIEMENS
ATEA</FONT> <BR><FONT SIZE=2>&gt; &gt; ICN D CS D5</FONT> <BR><FONT
SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Tel. : +32 14 25 3424</FONT> <BR><FONT
SIZE=2>&gt; Fax : +32 14 25 3212</FONT> <BR><FONT SIZE=2>&gt; <A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> <BR><FONT SIZE=2>&gt;
____________________________________</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: [email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>&gt; Sent: donderdag 10 mei 2001 12:17</FONT>
<BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject:
SUA5: Address Mapping text</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi all, </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There has been some discussion as of late on SUA / GTT
/ ENUM </FONT> <BR><FONT SIZE=2>&gt; / etc.&nbsp; I have</FONT> <BR><FONT
SIZE=2>&gt; updated the text.&nbsp; Please comment.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; br,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5 Internal Functions Provided in the SUA Layer
</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is assumed that Global Title Translation (GTT)
occurs </FONT> <BR><FONT SIZE=2>&gt; outside of SUA.</FONT> <BR><FONT
SIZE=2>&gt; However, SUA will need to map the output of the GTT process,
when</FONT> <BR><FONT SIZE=2>&gt; applicable, to an ASP via an Address
Mapping Function (AMF).&nbsp; </FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; When SS7 addressing is used by the upper layer
protocol, SUA </FONT> <BR><FONT SIZE=2>&gt; will need to</FONT> <BR><FONT
SIZE=2>&gt; determine the correct signaling endpoint.&nbsp; How this is done
is</FONT> <BR><FONT SIZE=2>&gt; implementation specific, but it could
involve DNS [ENUM] or local</FONT> <BR><FONT SIZE=2>&gt; configuration
information.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5.1 Address Translation and Mapping at the SG</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The SG MUST provide address translation and mapping
functions </FONT> <BR><FONT SIZE=2>&gt; to direct</FONT>
<BR><FONT SIZE=2>&gt; messages received from the SS7 network to the
appropriate IP </FONT> <BR><FONT SIZE=2>&gt; destination.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In order to support message distribution, the SG
maintains an address</FONT> <BR><FONT SIZE=2>&gt; translation table, which
maps the incoming SS7 messages to </FONT> <BR><FONT SIZE=2>&gt; the
appropriate</FONT> <BR><FONT SIZE=2>&gt; AS.&nbsp; The relevant fields of
the incoming SS7 message is </FONT> <BR><FONT SIZE=2>&gt; compared to
the</FONT> <BR><FONT SIZE=2>&gt; existing Routing Keys.&nbsp; The Routing
Keys reference an </FONT> <BR><FONT SIZE=2>&gt; Application Server,</FONT>
<BR><FONT SIZE=2>&gt; which will have one or more ASPs processing traffic
for the AS.&nbsp; The</FONT> <BR><FONT SIZE=2>&gt; availability and status
of the ASPs is handled by SUA ASP management</FONT> <BR><FONT SIZE=2>&gt;
messages.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Possible SS7 address/routing information that comprise
</FONT> <BR><FONT SIZE=2>&gt; a Routing Key entry includes, for example,
OPC, DPC, SIO found in </FONT> <BR><FONT SIZE=2>&gt; the MTP3 routing label,
or other specific fields such as the </FONT> <BR><FONT SIZE=2>&gt; SCCP
subsystem number, or TCAP transaction ID. Some </FONT> <BR><FONT SIZE=2>&gt;
possibilities include:</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Global Title (+ SSN
optionally)</FONT> <BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PC
(+ SSN optionally)</FONT> <BR><FONT SIZE=2>&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Host Name (+ SSN optionally)</FONT> <BR><FONT
SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP Address(es) (+ SSN
optionally)</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; An Application Server maintains a list of ASPs that
are </FONT> <BR><FONT SIZE=2>&gt; available to process</FONT> <BR><FONT
SIZE=2>&gt; the traffic.&nbsp; The list is dynamic, based upon the
availability of the</FONT> <BR><FONT SIZE=2>&gt; individual ASPs in the
list.&nbsp; SUA ASP management messages are </FONT> <BR><FONT SIZE=2>&gt;
used to convey</FONT> <BR><FONT SIZE=2>&gt; the status of these ASPs and
their availability in failover </FONT> <BR><FONT SIZE=2>&gt;
situations.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Normally, one or more ASPs areis active in the ASP
(i.e., currently</FONT> <BR><FONT SIZE=2>&gt; processing traffic) but in
certain failure and transition cases it is</FONT> <BR><FONT SIZE=2>&gt;
possible that there may not be an active ASP available. The </FONT>
<BR><FONT SIZE=2>&gt; SG will buffer</FONT> <BR><FONT SIZE=2>&gt; the
message destined for this AS for a time T(r) or until an </FONT> <BR><FONT
SIZE=2>&gt; ASP becomes</FONT> <BR><FONT SIZE=2>&gt; available. When no ASP
becomes available before expiry of </FONT> <BR><FONT SIZE=2>&gt; t(r), the
SG will</FONT> <BR><FONT SIZE=2>&gt; flush the buffered messages and
initiate the appropriate </FONT> <BR><FONT SIZE=2>&gt; return or
refusal</FONT> <BR><FONT SIZE=2>&gt; procedures. </FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Both load-sharing and backup scenarios are
supported.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If there is no Routing Key match for an incoming SS7
message, </FONT> <BR><FONT SIZE=2>&gt; a default</FONT>
<BR><FONT SIZE=2>&gt; treatment MUST be specified.&nbsp; Possible solutions
are to </FONT> <BR><FONT SIZE=2>&gt; provide a default</FONT> <BR><FONT
SIZE=2>&gt; Application Server to direct all unallocated traffic to a
</FONT> <BR><FONT SIZE=2>&gt; (set of) default</FONT> <BR><FONT SIZE=2>&gt;
ASP(s), or to drop the messages and provide a notification to </FONT>
<BR><FONT SIZE=2>&gt; management.</FONT> <BR><FONT SIZE=2>&gt; The treatment
of unallocated traffic is implementation dependent.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5.2 Address Translation and Mapping at the
ASP</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In order to direct messages to the SS7 network, the
ASP must </FONT> <BR><FONT SIZE=2>&gt; also perform an</FONT> <BR><FONT
SIZE=2>&gt; address translation and mapping function in order to choose
</FONT> <BR><FONT SIZE=2>&gt; the proper SG or</FONT> <BR><FONT SIZE=2>&gt;
SGP for a given message.&nbsp; This is accomplished by observing </FONT>
<BR><FONT SIZE=2>&gt; the Destination</FONT> <BR><FONT SIZE=2>&gt; Point
Code and other elements of the outgoing message, SS7 </FONT> <BR><FONT
SIZE=2>&gt; network status,</FONT> <BR><FONT SIZE=2>&gt; SG and SGP
availability, and network appearance configuration tables.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A remote Signaling Gateway may be composed of one or
more </FONT> <BR><FONT SIZE=2>&gt; SGPs.&nbsp; that are</FONT> <BR><FONT
SIZE=2>&gt; capable of routing SS7 traffic.&nbsp; As is the case with ASPs,
a </FONT> <BR><FONT SIZE=2>&gt; dynamic list of</FONT> <BR><FONT SIZE=2>&gt;
SGPs in an SG can be maintained, taking into account the </FONT> <BR><FONT
SIZE=2>&gt; availability status</FONT> <BR><FONT SIZE=2>&gt; of the
individual SGPs, configuration changes and fail-over </FONT> <BR><FONT
SIZE=2>&gt; mechanisms.</FONT> <BR><FONT SIZE=2>&gt; There is, however, no
SUA messaging to manage the status of </FONT> <BR><FONT SIZE=2>&gt; an SGP.
Whenever</FONT> <BR><FONT SIZE=2>&gt; an SCTP association to an SGP exists,
it is assumed to be </FONT> <BR><FONT SIZE=2>&gt; available.&nbsp;
Also,</FONT> <BR><FONT SIZE=2>&gt; every SGP of one SG communicating with
one ASP regarding one </FONT> <BR><FONT SIZE=2>&gt; AS provides</FONT>
<BR><FONT SIZE=2>&gt; identical SS7 connectivity to this ASP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1.5.3 SCTP Stream Mapping</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; The SUA supports SCTP streams. The SG/AS needs to
maintain a </FONT> <BR><FONT SIZE=2>&gt; list of SCTP</FONT> <BR><FONT
SIZE=2>&gt; and SUA-users for mapping purposes.&nbsp; SCCP-users requiring
</FONT> <BR><FONT SIZE=2>&gt; sequenced message</FONT> <BR><FONT SIZE=2>&gt;
transfer need to be sent over a stream supporting sequenced delivery.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; SUA MUST use stream 0 for SUA management messages. It
is </FONT> <BR><FONT SIZE=2>&gt; recommended that</FONT> <BR><FONT
SIZE=2>&gt; sequenced delivery is usedbe in order to preserve the order
</FONT> <BR><FONT SIZE=2>&gt; of management</FONT> <BR><FONT SIZE=2>&gt;
message delivery.</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as: </FONT>
<BR><FONT SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; To unsubscribe send a blank email to</FONT> <BR><FONT
SIZE=2>&gt; [email-masked]</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Fri, 11 May 2001 17:19:44 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: ftpbox.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: ftpbox.mot.com [129.188.136.101]
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">
<TITLE>RE: SUA5: Address Mapping text</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD> <BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN
class=541081921-11052001>Resend due to the same first line as my previous
email...</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><B><FONT color=#000080 face="Comic Sans MS" size=2>Michael
Young</FONT></B><FONT face="Times New Roman"><BR></FONT><FONT color=#808080
face="Comic Sans MS" 
size=2>---------------------------------------------------------------</FONT
><FONT face="Times New Roman"><BR></FONT><FONT color=#808080 face="Comic
Sans MS" size=2>System Design, GTSS Vancouver, Motorola</FONT><BR><FONT
color=#808080 face="Comic Sans MS" size=2>Tel: +1 (604)241-6032&nbsp;&nbsp;
Cel: +1 (604)726-6609</FONT><FONT face="Times New Roman"><BR></FONT><FONT
color=#808080 face="Comic Sans MS" size=2>Email:
[email-masked]</FONT><FONT face="Times New
Roman"><BR></FONT><FONT color=#808080 face="Comic Sans MS"
size=2>---------------------------------------------------------------</FONT
><FONT face="Times New Roman"> </FONT></P>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Young Michael-Y10724 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, May
11, 
  2001 2:12 PM<BR><B>To:</B> sigtran<BR><B>Subject:</B> RE: SUA5: Address 
  Mapping text<BR><BR></DIV></FONT>
  <P><FONT size=2>Please see below.</FONT> </P>
  <P><FONT size=2>Have a nice weekend,</FONT> </P>
  <P><FONT size=2>Michael Young </FONT><BR><FONT 
  size=2>--------------------------------------------------------------- 
  </FONT><BR><FONT size=2>System Design, GTSS Vancouver, Motorola 
  </FONT><BR><FONT size=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 
  (604)726-6609 </FONT><BR><FONT size=2>Email: [email-masked] 
  </FONT><BR><FONT 
  size=2>--------------------------------------------------------------- 
  </FONT></P><BR><BR>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT
size=2>&gt; 
  From: Verwimp Gery [<A 
 
href="mailto:[email-masked]">mailto:[email-masked].
be</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Friday, May 11, 2001 5:03 AM</FONT> <BR><FONT 
  size=2>&gt; To: sigtran</FONT> <BR><FONT size=2>&gt; Subject: RE: SUA5: 
  Address Mapping text</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 2 comments :</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; - with DPC or IP address, ALWAYS a valid SSN
has 
  to be </FONT><BR><FONT size=2>&gt; present. With this</FONT> <BR><FONT 
  size=2>&gt; the end-SUA has to address it's user; we have to keep this 
  </FONT><BR><FONT size=2>&gt; interface with</FONT> <BR><FONT size=2>&gt;
the 
  user.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>[MYH} I 
  agree.</FONT> </P>
  <P><FONT size=2>&gt; - does an ASP still have to know the concept of
SG-SGP 
  ?</FONT> </P>
  <P><FONT size=2>[MYH] It depends.&nbsp; If the operator is willing to
expose 
  its network topology and free to have all its network signalling nodes to 
  establish SCTP associations with outside network, I don't think ASP need
to 
  know the concept of SG-SGP.&nbsp; However, the concept of SG-SGP in all ip

  scenario is debatable.&nbsp; The operator might just want to have&nbsp;
one or 
  more boarder gateway(s) sitting at the edge of its network to interact
with 
  outside world by relaying SUA msgs.&nbsp; Why not name this guy "SUA Relay

  Node"?</FONT></P>
  <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; greetings,</FONT>
<BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt;
____________________________</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Gery Verwimp</FONT> 
  <BR><FONT size=2>&gt; &gt; SIEMENS ATEA</FONT> <BR><FONT size=2>&gt; &gt;
ICN 
  D CS D5</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt;
&gt; 
  Tel. : +32 14 25 3424</FONT> <BR><FONT size=2>&gt; Fax : +32 14 25
3212</FONT> 
  <BR><FONT size=2>&gt; <A 
 
href="mailto:[email-masked]">mailto:[email-masked].
be</A></FONT> 
  <BR><FONT size=2>&gt; ____________________________________</FONT>
<BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; From: 
  [email-masked] [<A 
 
href="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> 
  <BR><FONT size=2>&gt; Sent: donderdag 10 mei 2001 12:17</FONT> <BR><FONT 
  size=2>&gt; To: sigtran</FONT> <BR><FONT size=2>&gt; Subject: SUA5:
Address 
  Mapping text</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Hi all, </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; There has been some discussion as of late on
SUA 
  / GTT / ENUM </FONT><BR><FONT size=2>&gt; / etc.&nbsp; I have</FONT>
<BR><FONT 
  size=2>&gt; updated the text.&nbsp; Please comment.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; br,</FONT> <BR><FONT size=2>&gt; 
  John</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 1.5
Internal 
  Functions Provided in the SUA Layer </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; It is assumed that Global Title Translation
(GTT) 
  occurs </FONT><BR><FONT size=2>&gt; outside of SUA.</FONT> <BR><FONT 
  size=2>&gt; However, SUA will need to map the output of the GTT process, 
  when</FONT> <BR><FONT size=2>&gt; applicable, to an ASP via an Address
Mapping 
  Function (AMF).&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; When SS7 addressing is used by the upper layer protocol, SUA 
  </FONT><BR><FONT size=2>&gt; will need to</FONT> <BR><FONT size=2>&gt; 
  determine the correct signaling endpoint.&nbsp; How this is done is</FONT>

  <BR><FONT size=2>&gt; implementation specific, but it could involve DNS
[ENUM] 
  or local</FONT> <BR><FONT size=2>&gt; configuration information.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 1.5.1 Address
Translation 
  and Mapping at the SG</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; The SG MUST provide address translation and mapping functions 
  </FONT><BR><FONT size=2>&gt; to direct</FONT> <BR><FONT size=2>&gt;
messages 
  received from the SS7 network to the appropriate IP </FONT><BR><FONT 
  size=2>&gt; destination.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; In order to support message distribution, the SG maintains an 
  address</FONT> <BR><FONT size=2>&gt; translation table, which maps the 
  incoming SS7 messages to </FONT><BR><FONT size=2>&gt; the
appropriate</FONT> 
  <BR><FONT size=2>&gt; AS.&nbsp; The relevant fields of the incoming SS7 
  message is </FONT><BR><FONT size=2>&gt; compared to the</FONT> <BR><FONT 
  size=2>&gt; existing Routing Keys.&nbsp; The Routing Keys reference an 
  </FONT><BR><FONT size=2>&gt; Application Server,</FONT> <BR><FONT
size=2>&gt; 
  which will have one or more ASPs processing traffic for the AS.&nbsp; 
  The</FONT> <BR><FONT size=2>&gt; availability and status of the ASPs is 
  handled by SUA ASP management</FONT> <BR><FONT size=2>&gt;
messages.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Possible SS7 
  address/routing information that comprise </FONT><BR><FONT size=2>&gt; a 
  Routing Key entry includes, for example, OPC, DPC, SIO found in 
  </FONT><BR><FONT size=2>&gt; the MTP3 routing label, or other specific
fields 
  such as the </FONT><BR><FONT size=2>&gt; SCCP subsystem number, or TCAP 
  transaction ID. Some </FONT><BR><FONT size=2>&gt; possibilities 
  include:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Global Title (+ SSN optionally)</FONT> 
  <BR><FONT size=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PC (+ SSN 
  optionally)</FONT> <BR><FONT size=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Host 
  Name (+ SSN optionally)</FONT> <BR><FONT size=2>&gt; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP Address(es) (+ SSN optionally)</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; An Application Server 
  maintains a list of ASPs that are </FONT><BR><FONT size=2>&gt; available
to 
  process</FONT> <BR><FONT size=2>&gt; the traffic.&nbsp; The list is
dynamic, 
  based upon the availability of the</FONT> <BR><FONT size=2>&gt; individual

  ASPs in the list.&nbsp; SUA ASP management messages are </FONT><BR><FONT 
  size=2>&gt; used to convey</FONT> <BR><FONT size=2>&gt; the status of
these 
  ASPs and their availability in failover </FONT><BR><FONT size=2>&gt; 
  situations.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Normally, one or more ASPs areis active in the ASP (i.e., currently</FONT>

  <BR><FONT size=2>&gt; processing traffic) but in certain failure and 
  transition cases it is</FONT> <BR><FONT size=2>&gt; possible that there
may 
  not be an active ASP available. The </FONT><BR><FONT size=2>&gt; SG will 
  buffer</FONT> <BR><FONT size=2>&gt; the message destined for this AS for a

  time T(r) or until an </FONT><BR><FONT size=2>&gt; ASP becomes</FONT> 
  <BR><FONT size=2>&gt; available. When no ASP becomes available before
expiry 
  of </FONT><BR><FONT size=2>&gt; t(r), the SG will</FONT> <BR><FONT
size=2>&gt; 
  flush the buffered messages and initiate the appropriate </FONT><BR><FONT 
  size=2>&gt; return or refusal</FONT> <BR><FONT size=2>&gt; procedures. 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Both
load-sharing 
  and backup scenarios are supported.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; If there is no Routing Key match for an
incoming 
  SS7 message, </FONT><BR><FONT size=2>&gt; a default</FONT> <BR><FONT 
  size=2>&gt; treatment MUST be specified.&nbsp; Possible solutions are to 
  </FONT><BR><FONT size=2>&gt; provide a default</FONT> <BR><FONT
size=2>&gt; 
  Application Server to direct all unallocated traffic to a </FONT><BR><FONT

  size=2>&gt; (set of) default</FONT> <BR><FONT size=2>&gt; ASP(s), or to
drop 
  the messages and provide a notification to </FONT><BR><FONT size=2>&gt; 
  management.</FONT> <BR><FONT size=2>&gt; The treatment of unallocated
traffic 
  is implementation dependent.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT

  size=2>&gt; 1.5.2 Address Translation and Mapping at the ASP</FONT>
<BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; In order to direct messages to
the 
  SS7 network, the ASP must </FONT><BR><FONT size=2>&gt; also perform
an</FONT> 
  <BR><FONT size=2>&gt; address translation and mapping function in order to

  choose </FONT><BR><FONT size=2>&gt; the proper SG or</FONT> <BR><FONT 
  size=2>&gt; SGP for a given message.&nbsp; This is accomplished by
observing 
  </FONT><BR><FONT size=2>&gt; the Destination</FONT> <BR><FONT size=2>&gt; 
  Point Code and other elements of the outgoing message, SS7
</FONT><BR><FONT 
  size=2>&gt; network status,</FONT> <BR><FONT size=2>&gt; SG and SGP 
  availability, and network appearance configuration tables.</FONT>
<BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; A remote Signaling Gateway may be

  composed of one or more </FONT><BR><FONT size=2>&gt; SGPs.&nbsp; that 
  are</FONT> <BR><FONT size=2>&gt; capable of routing SS7 traffic.&nbsp; As
is 
  the case with ASPs, a </FONT><BR><FONT size=2>&gt; dynamic list of</FONT> 
  <BR><FONT size=2>&gt; SGPs in an SG can be maintained, taking into account
the 
  </FONT><BR><FONT size=2>&gt; availability status</FONT> <BR><FONT
size=2>&gt; 
  of the individual SGPs, configuration changes and fail-over
</FONT><BR><FONT 
  size=2>&gt; mechanisms.</FONT> <BR><FONT size=2>&gt; There is, however, no
SUA 
  messaging to manage the status of </FONT><BR><FONT size=2>&gt; an SGP. 
  Whenever</FONT> <BR><FONT size=2>&gt; an SCTP association to an SGP
exists, it 
  is assumed to be </FONT><BR><FONT size=2>&gt; available.&nbsp;
Also,</FONT> 
  <BR><FONT size=2>&gt; every SGP of one SG communicating with one ASP
regarding 
  one </FONT><BR><FONT size=2>&gt; AS provides</FONT> <BR><FONT size=2>&gt; 
  identical SS7 connectivity to this ASP.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 1.5.3 SCTP Stream Mapping</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; The SUA supports SCTP streams.
The 
  SG/AS needs to maintain a </FONT><BR><FONT size=2>&gt; list of SCTP</FONT>

  <BR><FONT size=2>&gt; and SUA-users for mapping purposes.&nbsp; SCCP-users

  requiring </FONT><BR><FONT size=2>&gt; sequenced message</FONT> <BR><FONT 
  size=2>&gt; transfer need to be sent over a stream supporting sequenced 
  delivery.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; SUA
MUST 
  use stream 0 for SUA management messages. It is </FONT><BR><FONT
size=2>&gt; 
  recommended that</FONT> <BR><FONT size=2>&gt; sequenced delivery is usedbe
in 
  order to preserve the order </FONT><BR><FONT size=2>&gt; of
management</FONT> 
  <BR><FONT size=2>&gt; message delivery.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; ---</FONT>
<BR><FONT 
  size=2>&gt; You are currently subscribed to sigtran as: </FONT><BR><FONT 
  size=2>&gt; [email-masked]</FONT> <BR><FONT size=2>&gt; To 
  unsubscribe send a blank email to</FONT> <BR><FONT size=2>&gt; 
  [email-masked]</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; ---</FONT>
<BR><FONT 
  size=2>&gt; You are currently subscribed to sigtran as: 
  [email-masked]</FONT> <BR><FONT size=2>&gt; To unsubscribe
send a 
  blank email to </FONT><BR><FONT size=2>&gt; 
  [email-masked]</FONT> <BR><FONT size=2>&gt; 
  </FONT></P>---<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: Fri, 11 May 2001 20:46:21 -0700 (PDT)
From: Kacheong Poon <[email-masked]>
Reply-To: [email-masked]
Subject: v6 address selection
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]>
List-Unsubscribe: <mailto:[email-masked]>

Could the chairs of tsvwg and sigtran tell us the status of 2960 bis?
I believe it is going to obsolete RFC 2960, right?  May I ask Randy that he
puts his rule set in another document and removes the set from 2960 bis?  My
reason being that even in ipngwg, people are still experimenting with many
issues in this area.  We should not jump in and put a rule set in the SCTP
standard spec.  We should move on with Randy's set and experiment more at
this point.  All implementors are aware of the issue and I don't believe any
implementations will make the mistakes again.  I doubt that there will be
interoperability issues.

							K. Poon.
							[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 Version 5.1
Date: Mon, 14 May 2001 10:45:12 -0400
To: "sigtran" <[email-masked]>
From: RJ Atkinson <[email-masked]>
Subject: Fwd: I-D ACTION:draft-otis-sctp-digest-00.txt
X-SMTP-HELO: gnat.inet.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.108.254.91]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Folks,

        The draft below appears to partially replicate the already existing
IETF Standard known as the IP Authentication Header.
I say "partially", because it is no less expensive computationally but
provides less comprehensive protections than IP AH.

        IMHO, the WG needs to closely consider whether the existing text
about IP AH in SCTP RFC's "Security Considerations" section is sufficient.
Perhaps SIGTRAN does not in fact need to re-invent this particular wheel.

        There is a broad tendency of many WGs in the IETF to re-invent
wheels, either by accident or intent.  The tendency to re-invent wheels is
not very helpful in retaining broad interoperability or in having a
consistent Internet Architecture.

Cheers,

Ran
[email-masked]

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-To: [email-masked]
>Subject: I-D ACTION:draft-otis-sctp-digest-00.txt
>Date: Mon, 14 May 2001 07:35:06 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>        Title           : Integrity-Authentication Digest for SCTP
>        Author(s)       : D. Otis
>        Filename        : draft-otis-sctp-digest-00.txt
>        Pages           : 
>        Date            : 11-May-01
>        
>This document is to allow the inclusion of a digital signature within 
>the SCTP [RFC2960] packet.  This digital signature, or digest, would 
>be negotiated on a per Association basis.  The means of negotiation 
>and use is beyond the scope of this document.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Mon, 14 May 2001 20:13:49 -0500
From: "Randall R. Stewart" <[email-masked]>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.17-14 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: The site is up :)
X-SMTP-HELO: stewart.chicago.il.us
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.37.247.196]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all:

Ok, the sctp web sites are finally back online!!

And the good news is that the site is now a bit faster on the upload :)

We should be able to give a lot better servers now ..

Also you will find the latest release 4.0.4 with all the bake-off fixes.. it
has fixes on top of 4.0.3 that allow link-local addresses in v6 (yes
Kacheong, it uses the site/link local rules  I put in the bis .. soon to be
moved to another  document).

Enjoy

R
-- 
Randall R. Stewart
[email-masked] or [email-masked] 815-342-5222 (cell)
815-477-2127 (work)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Interworking Between SUA and SCCP/M3UA
Date: Mon, 14 May 2001 23:46:07 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate3.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate3.mot.com [144.189.100.103]
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=US-ASCII"> <META
NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>Interworking Between SUA and SCCP/M3UA</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Quick question regarding interworking between SUA and
SCCP/M3UA, personally I don't see any difference comparing to SUA
interworking with legacy SS7 protocols (SCCP/MTP3).&nbsp; Did I miss
anything?&nbsp; Please correct me if I am wrong.</FONT></P>

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

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>&nbsp;</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]
To: "sigtran" <[email-masked]>
Subject: RE: Interworking Between SUA and SCCP/M3UA
Date: Tue, 15 May 2001 09:59:11 +0300
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: mgw-x4.nokia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mgw-x4.nokia.com [131.228.20.27]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Michael,

Quick question regarding interworking between SUA and SCCP/M3UA, personally
I don't see any difference comparing to SUA interworking with legacy SS7
protocols (SCCP/MTP3).  Did I miss anything?  Please correct me if I am
wrong.

[<JAL> ] I don't think so.
 
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Chiang Robin-RCHIANG2 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Interworking Between SUA and SCCP/M3UA
Date: Tue, 15 May 2001 10:58:14 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate.mot.com [129.188.136.100]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Michael,

In the case of SUA interworking with legacy SS7 protocol, the two endpoints
are in different domains i.e. IP and SS7.
As for interworking between SUA and SCCP/M3UA, the two endpoints are in the
IP domains. One difference is the routing using MTP3 and SCTP.

Regards,

Robin Chiang Cher Nung
[email-masked] <mailto:[email-masked]> Motorola GSM Systems
Division
GSM Research Group
16 Euroway, Blagrove, Swindon,
Wiltshire SN5 8YQ.
Tel: +44 1793 566237
Mobile: 07808 949599
Fax: +44 1793 566225

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent:
Tuesday, May 15, 2001 7:59 AM
To: sigtran
Subject: RE: Interworking Between SUA and SCCP/M3UA

Hi Michael,

Quick question regarding interworking between SUA and SCCP/M3UA, personally
I don't see any difference comparing to SUA interworking with legacy SS7
protocols (SCCP/MTP3).  Did I miss anything?  Please correct me if I am
wrong.

[<JAL> ] I don't think so.
 
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]
To: "sigtran" <[email-masked]>
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-hou-sigtran-tua-00.txt
Date: Tue, 15 May 2001 07:01:46 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: SS7 TCAP-User Adaptation Layer (TUA)
	Author(s)	: J. Hou, M. Lin
	Filename	: draft-hou-sigtran-tua-00.txt
	Pages		: 75
	Date		: 14-May-01
	
This document defines a protocol for the transport of any SS7 TCAP-User
signaling (e.g.,INAP,MAP , etc.) over IP using the Stream Control Transport
Protocol.  The protocol  should be modular and symmetric, to allow it to
work in diverse architectures, such as a Signaling Gateway to IP Signaling
Endpoint architecture .  Protocol elements are added to allow seamless
operation between  peers in the SS7 and IP domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hou-sigtran-tua-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-hou-sigtran-tua-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hou-sigtran-tua-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hou-sigtran-tua-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-hou-sigtran-tua-00.txt> ---
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: Interworking Between SUA and SCCP/M3UA
Date: Tue, 15 May 2001 11:41:16 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

<meta name=ProgId content=Word.Document> <meta name=Generator
content="Microsoft Word 9"> <meta name=Originator content="Microsoft Word
9"> <link rel=File-List href="cid:[email-masked]">
<title>Interworking Between SUA and SCCP/M3UA</title> <!--[if gte mso
9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>  <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}  /* Style
Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";} p.MsoAutoSig,
li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";} p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";} span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=EN-US style='tab-interval:.5in'>

<div class=Section1>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Hi
Michael,<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I don't
see a protocol issue.<span style="mso-spacerun: yes">&nbsp; </span>If we are
interworking SCCP/M3UA/SCTP to SUA/SCTP then the SUA draft should cover this
case &#8211; it is the same as SCCP to SUA interworking at an SG.<span
style="mso-spacerun: yes">&nbsp; </span><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Archite
cturally the interworking point (an SG?) ends up looking like an IP GTT
server for the IP nodes using SCCP/M3UA.<span style="mso-spacerun:
yes">&nbsp; </span>The nodes using SCCP/M3UA address the SCCP layer at the
interworking point to get to the other IP nodes that are using
SUA.<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Hope
this helps.<o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Greg<o:
p></o:p></span></font></span></p>

<p class=MsoNormal><span class=EmailStyle16><font size=2 color=navy
face=Arial><span
style='font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 color=black
face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Young Michael-Y10724
[mailto:[email-masked]]<br> <b><span
style='font-weight:bold'>Sent:</span></b> Monday, May 14, 2001 11:46 PM<br>
<b><span style='font-weight:bold'>To:</span></b> sigtran<br> <b><span
style='font-weight:bold'>Subject:</span></b> Interworking Between SUA and
SCCP/M3UA</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New
Roman"><span style='font-size:12.0pt'><![if
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style='margin-left:.5in'><font size=2 color=black face="Times New
Roman"><span style='font-size:10.0pt;color:black'>Hi All,</span></font><font
color=black><span style='color:black'> </span></font><font color=black><span
style='color:black; mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style='margin-left:.5in'><font size=2 color=black face="Times New
Roman"><span style='font-size:10.0pt;color:black'>Quick question regarding
interworking between SUA and SCCP/M3UA, personally I don't see any
difference comparing to SUA interworking with legacy SS7 protocols
(SCCP/MTP3).&nbsp; Did I miss anything?&nbsp; Please correct me if I am
wrong.</span></font><font color=black><span
style='color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style='margin-left:.5in'><font size=2 color=black face="Times New
Roman"><span style='font-size:10.0pt;color:black'>Thanks,</span></font><font
color=black><span style='color:black'> </span></font><font color=black><span
style='color:black; mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style='margin-left:.5in'><font size=2 color=black face="Times New
Roman"><span style='font-size:10.0pt;color:black'>Michael Young
</span></font><font color=black><span style='color:black'><br>
</span></font><font size=2 color=black><span style='font-size:10.0pt;
color:black'>---------------------------------------------------------------
</span></font><font color=black><span style='color:black'><br>
</span></font><font size=2 color=black><span style='font-size:10.0pt;
color:black'>System Design, GTSS Vancouver, Motorola </span></font><font
color=black><span style='color:black'><br> </span></font><font size=2
color=black><span style='font-size:10.0pt; color:black'>Tel: +1
(604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609 </span></font><font
color=black><span style='color:black'><br> </span></font><font size=2
color=black><span style='font-size:10.0pt; color:black'>Email:
[email-masked] </span></font><font color=black><span
style='color:black'><br>
</span></font><font size=2 color=black><span style='font-size:10.0pt;
color:black'>---------------------------------------------------------------
</span></font><font color=black><span style='color:black'><br>
</span></font><font size=2 color=black><span style='font-size:10.0pt;
color:black'>&nbsp;</span></font><font color=black><span
style='color:black'> </span></font><font color=black><span
style='color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt;color:black'>---<br>
You are currently subscribed to sigtran as: [email-masked]<br>
To unsubscribe send a blank email to
[email-masked] </span></font><font
color=black><span
style='color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</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>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SUA5: Address Mapping text
Date: Tue, 15 May 2001 11:55:40 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: SUA5: Address Mapping text</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>] </FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Friday, May 11, 2001 8:03
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; RE:
SUA5: Address Mapping text</FONT> </P>

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

<P><FONT SIZE=2>- with DPC or IP address, ALWAYS a valid SSN has to be
present. With this</FONT> <BR><FONT SIZE=2>the end-SUA has to address it's
user; we have to keep this interface with</FONT> <BR><FONT SIZE=2>the
user.</FONT>
</P>

<P><FONT SIZE=2>- does an ASP still have to know the concept of SG-SGP
?</FONT> </P>

<P><FONT SIZE=2>[Greg] The consensus on the list is that an ASP does not
have to know the concept of SG/SGP.&nbsp; There was an M3UA thread on this -
I think it would also apply to the SUA.</FONT></P>

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

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

<P><FONT SIZE=2>greetings,</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:
[email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>Sent: donderdag 10 mei 2001 12:17</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: SUA5: Address Mapping text</FONT> </P>
<BR>

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

<P><FONT SIZE=2>There has been some discussion as of late on SUA / GTT /
ENUM / etc.&nbsp; I have</FONT> <BR><FONT SIZE=2>updated the text.&nbsp;
Please comment.</FONT> </P>

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

<P><FONT SIZE=2>1.5 Internal Functions Provided in the SUA Layer </FONT>
</P>

<P><FONT SIZE=2>It is assumed that Global Title Translation (GTT) occurs
outside of SUA.</FONT> <BR><FONT SIZE=2>However, SUA will need to map the
output of the GTT process, when</FONT> <BR><FONT SIZE=2>applicable, to an
ASP via an Address Mapping Function (AMF).&nbsp; </FONT> </P>

<P><FONT SIZE=2>When SS7 addressing is used by the upper layer protocol, SUA
will need to</FONT> <BR><FONT SIZE=2>determine the correct signaling
endpoint.&nbsp; How this is done is</FONT> <BR><FONT SIZE=2>implementation
specific, but it could involve DNS [ENUM] or local</FONT> <BR><FONT
SIZE=2>configuration information.</FONT> </P>

<P><FONT SIZE=2>1.5.1 Address Translation and Mapping at the SG</FONT> </P>

<P><FONT SIZE=2>The SG MUST provide address translation and mapping
functions to direct</FONT> <BR><FONT SIZE=2>messages received from the SS7
network to the appropriate IP destination.</FONT> </P>

<P><FONT SIZE=2>In order to support message distribution, the SG maintains
an address</FONT> <BR><FONT SIZE=2>translation table, which maps the
incoming SS7 messages to the appropriate</FONT> <BR><FONT SIZE=2>AS.&nbsp;
The relevant fields of the incoming SS7 message is compared to the</FONT>
<BR><FONT SIZE=2>existing Routing Keys.&nbsp; The Routing Keys reference an
Application Server,</FONT> <BR><FONT SIZE=2>which will have one or more ASPs
processing traffic for the AS.&nbsp; The</FONT> <BR><FONT
SIZE=2>availability and status of the ASPs is handled by SUA ASP
management</FONT> <BR><FONT SIZE=2>messages.</FONT>
</P>

<P><FONT SIZE=2>Possible SS7 address/routing information that comprise
</FONT> <BR><FONT SIZE=2>a Routing Key entry includes, for example, OPC,
DPC, SIO found in </FONT> <BR><FONT SIZE=2>the MTP3 routing label, or other
specific fields such as the </FONT> <BR><FONT SIZE=2>SCCP subsystem number,
or TCAP transaction ID. Some possibilities include:</FONT> </P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Global Title (+
SSN optionally)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
SIZE=2>PC (+ SSN optionally)</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Host Name (+ SSN
optionally)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
SIZE=2>IP Address(es) (+ SSN optionally)</FONT> </P>

<P><FONT SIZE=2>An Application Server maintains a list of ASPs that are
available to process</FONT> <BR><FONT SIZE=2>the traffic.&nbsp; The list is
dynamic, based upon the availability of the</FONT> <BR><FONT
SIZE=2>individual ASPs in the list.&nbsp; SUA ASP management messages are
used to convey</FONT> <BR><FONT SIZE=2>the status of these ASPs and their
availability in failover situations.</FONT> </P>

<P><FONT SIZE=2>Normally, one or more ASPs areis active in the ASP (i.e.,
currently</FONT> <BR><FONT SIZE=2>processing traffic) but in certain failure
and transition cases it is</FONT> <BR><FONT SIZE=2>possible that there may
not be an active ASP available. The SG will buffer</FONT> <BR><FONT
SIZE=2>the message destined for this AS for a time T(r) or until an ASP
becomes</FONT> <BR><FONT SIZE=2>available. When no ASP becomes available
before expiry of t(r), the SG will</FONT> <BR><FONT SIZE=2>flush the
buffered messages and initiate the appropriate return or refusal</FONT>
<BR><FONT SIZE=2>procedures. </FONT>
</P>

<P><FONT SIZE=2>Both load-sharing and backup scenarios are supported.</FONT>
</P>

<P><FONT SIZE=2>If there is no Routing Key match for an incoming SS7
message, a default</FONT> <BR><FONT SIZE=2>treatment MUST be
specified.&nbsp; Possible solutions are to provide a default</FONT>
<BR><FONT SIZE=2>Application Server to direct all unallocated traffic to a
(set of) default</FONT> <BR><FONT SIZE=2>ASP(s), or to drop the messages and
provide a notification to management.</FONT> <BR><FONT SIZE=2>The treatment
of unallocated traffic is implementation dependent.</FONT> </P>

<P><FONT SIZE=2>1.5.2 Address Translation and Mapping at the ASP</FONT> </P>

<P><FONT SIZE=2>In order to direct messages to the SS7 network, the ASP must
also perform an</FONT> <BR><FONT SIZE=2>address translation and mapping
function in order to choose the proper SG or</FONT> <BR><FONT SIZE=2>SGP for
a given message.&nbsp; This is accomplished by observing the
Destination</FONT> <BR><FONT SIZE=2>Point Code and other elements of the
outgoing message, SS7 network status,</FONT> <BR><FONT SIZE=2>SG and SGP
availability, and network appearance configuration tables.</FONT> </P>

<P><FONT SIZE=2>A remote Signaling Gateway may be composed of one or more
SGPs.&nbsp; that are</FONT> <BR><FONT SIZE=2>capable of routing SS7
traffic.&nbsp; As is the case with ASPs, a dynamic list of</FONT> <BR><FONT
SIZE=2>SGPs in an SG can be maintained, taking into account the availability
status</FONT> <BR><FONT SIZE=2>of the individual SGPs, configuration changes
and fail-over mechanisms.</FONT> <BR><FONT SIZE=2>There is, however, no SUA
messaging to manage the status of an SGP. Whenever</FONT> <BR><FONT
SIZE=2>an SCTP association to an SGP exists, it is assumed to be
available.&nbsp; Also,</FONT> <BR><FONT SIZE=2>every SGP of one SG
communicating with one ASP regarding one AS provides</FONT> <BR><FONT
SIZE=2>identical SS7 connectivity to this ASP.</FONT> </P>

<P><FONT SIZE=2>1.5.3 SCTP Stream Mapping</FONT> </P>

<P><FONT SIZE=2>The SUA supports SCTP streams. The SG/AS needs to maintain a
list of SCTP</FONT> <BR><FONT SIZE=2>and SUA-users for mapping
purposes.&nbsp; SCCP-users requiring sequenced message</FONT> <BR><FONT
SIZE=2>transfer need to be sent over a stream supporting sequenced
delivery.</FONT> </P>

<P><FONT SIZE=2>SUA MUST use stream 0 for SUA management messages. It is
recommended that</FONT> <BR><FONT SIZE=2>sequenced delivery is usedbe in
order to preserve the order of management</FONT> <BR><FONT SIZE=2>message
delivery.</FONT> </P>
<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>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Tue, 15 May 2001 14:31:25 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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.2654.59">
<TITLE>RE: [M3UA] AS state machine sharing between SGPs</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>I'm tying to close out on this item for Issue 7.&nbsp;
There's been a few e-mails with excellent input, but they do not all line
up.&nbsp; Further, we've had no input from any SG vendor who is implementing
this multiple SGP in an SG architecture to help us with the issues.&nbsp; I
think it is worth pointing out that unless there is more than one
implementation of this and it is deemed interoperable in a
&quot;bay-cough&quot; this functionality would have to be dropped out of the
protocol eventually.</FONT></P>

<P><FONT SIZE=2>I liked the way Gery separated the issues out below.&nbsp;
Comments and proposed conclusions below ...</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Verwimp Gery [<A
HREF="mailto:[email-masked]">mailto:[email-masked].
be</A>] </FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 02, 2001
8:17 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; RE:
[M3UA] AS state machine sharing between SGPs</FONT> </P>

<P><FONT SIZE=2>Maybe I'll add to everyone's confusion (or brain status),
but I'll give my 2</FONT> <BR><FONT SIZE=2>cents on this topic anyway
;-))</FONT> </P>

<P><FONT SIZE=2>We're talking about redundancy on three different levels, I
think :</FONT> </P>

<P><FONT SIZE=2>- network redundancy : redundancy of routes between SG and
ASP, that's why</FONT> <BR><FONT SIZE=2>we have the SCTP multihoming
feature, no ? So whether the physical</FONT> <BR><FONT SIZE=2>interfaces are
all connected to a single SGP or more SGP's is transparent</FONT> <BR><FONT
SIZE=2>for an ASP. And this is the main reason for having multiple SGPs at
an SG as</FONT> <BR><FONT SIZE=2>well, or am I missing something here ?
(Multiple routes, handled by multiple</FONT> <BR><FONT SIZE=2>processors on
the SG-host to avoid single points of failure). A single SG</FONT> <BR><FONT
SIZE=2>only has a single management view of it's SCTP associations, and each
SGP is</FONT> <BR><FONT SIZE=2>responsible of informing layer management of
it's part of the view (status</FONT> <BR><FONT SIZE=2>of physical
connections).</FONT> </P>

<P><FONT SIZE=2>[Greg] I think that the &quot;multiple SGP in an SG&quot;
view is really only useful to support a &quot;Distributed SG&quot;
implementation.&nbsp; This Distributed SG would be implemented with SGPs on
two or more Hosts, probably in different locations to get geographical
redundancy.&nbsp; Otherwise, the SCTP multi-homing functionality can be used
to handle this part of the redundancy, implementing multiple processors and
routes as Gery points out.&nbsp; (Although Kazuo Watanabe correctly pointed
out that if we are using TCP instead of SCTP we wouldn't have this SCTP
multi-homing and would need a further remedy) </FONT></P>

<P><FONT SIZE=2>In other words, why would I build two local SGPs on a Host
and go through all the pain of coordinating their MTP3 and SPMC state to the
SS7 network and AS/ASP state to the IP side, when all I have to do is use
SCTP's multi-homing feature to get the same redundancy.&nbsp; </FONT></P>
<BR>

<P><FONT SIZE=2>- platform/host redundancy : that's why we may want to
connect an ASP to 2</FONT> <BR><FONT SIZE=2>SGs (2 SCTP associations) in
case an entire SG breaks down (no matter how</FONT> <BR><FONT SIZE=2>many
SGPs it has, there might always be central errors or an earthquake or</FONT>
<BR><FONT SIZE=2>whatever). And also, for ANY kind of traffic, there has to
be more than 1</FONT> <BR><FONT SIZE=2>ASP available to each SG.</FONT> </P>

<P><FONT SIZE=2>[Greg] Agreed.&nbsp; For this redundancy, I have previously
mentioned that the Operator must ensure that the ASPs use SGPs or SGs that
are on different Hosts.&nbsp; Gery adds that the SGPs would probably also
need to be in different locations.&nbsp; So this is covered either
way.</FONT></P> <BR>

<P><FONT SIZE=2>- application redundancy : that's why we have multiple ASPs
in an AS to</FONT> <BR><FONT SIZE=2>handle a PARTICULAR portion of the
traffic.</FONT> </P>

<P><FONT SIZE=2>[Greg] Agreed.&nbsp; This has no bearing on the SGP / SG
issue.</FONT> </P>

<P><FONT SIZE=2>At least from a functional point of view, an SGP doesn't add
anything. An</FONT> <BR><FONT SIZE=2>ASP does, while it may be configured to
support multiple AS's ! I don't see</FONT> <BR><FONT SIZE=2>an SGP servicing
more than one SG ??? So I think it's wrong to search for a</FONT> <BR><FONT
SIZE=2>parallel between the two.</FONT> </P>

<P><FONT SIZE=2>Any views on this ?</FONT> </P>

<P><FONT SIZE=2>[Greg] I think it is fair to conclude that having multiple
SGPs in an SG does not in itself buy any extra functionality in terms of
redundancy over the multiple SG model.&nbsp; I think we've been bending over
backwards in the protocol description to accommodate an implementation
option (the &quot;distributed multi-site SG&quot; described
above).&nbsp;&nbsp; So where does this implementation option make sense? - I
think the answer is for the case where the signalling between the PSTN and
IP networks is to go through a single SG with a single SS7 Point code but
with site/processor redundancy for the SG.&nbsp; Paired SGs won' t do
because two Point Codes would be required.&nbsp;&nbsp; I don't really have
problem with supporting this case.&nbsp;&nbsp;&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=2>I think we can change a few things in the spec to support
this but remove some of the confusion that it brings:</FONT> </P>

<P><FONT SIZE=2>1) Simplify the protocol description so it is described as
between an SGP and ASP only.&nbsp; That is, SCTP associations are always
between SGPs and ASPs.&nbsp; Today the spec goes back and forth between the
SGP and SG terms and adds qualifying text in various places. </FONT></P>

<P><FONT SIZE=2>2) The SG becomes explicitly a virtual thing not unlike an
AS, containing one or more SGPs.&nbsp; The spec today seems to shade back
and forth on whether an SG is a physical thing or not.&nbsp; Of course if an
SG is implemented using a single SGP, then that is fine&nbsp;
2;^)</FONT></P>

<P><FONT SIZE=2>So a paired SG architecture is now two SGPs on different
hosts represented to the SS7 network with a Point Code per host.&nbsp; No
coordination of MTP3, SPMC or AS/ASP states between the SGPs is
required.&nbsp; A single distributed SG is the same except that it is
represented to the SS7 network with a single SS7 Point Code for the set of
SGPs.&nbsp; The SGPs SHOULD support MTP3, SPMC and AS/ASP state sharing and
re-routing of traffic between the two SGPs.&nbsp; How the inter-SGP protocol
accomplishes this is not described in the protocol spec.&nbsp;&nbsp;
</FONT></P>

<P><FONT SIZE=2>3) The ASPs do not need to know the grouping of SGPs in
virtual SGs so they treat each SGP as an independent route out to the SS7
network.&nbsp; But an ASP MAY choose to maintain such knowledge.&nbsp;&nbsp;
The SSNM messaging from the SGPs to the ASP is therefore processed
independently.&nbsp; Note that for Operators that choose not to combine SGPs
into virtual SGs (i.e., use paired physical SGs), then nothing has really
changed here.&nbsp;&nbsp; ASPs that choose to keep knowledge of SGP
groupings into virtual SGs MAY interpret SSNM messaging from one of the SGPs
so as to apply to all the SGPs in the virtual SG but should only do so if
the SGPs coordinate their SSNM messaging to the ASPs.</FONT></P>

<P><FONT SIZE=2>Hope this helps,</FONT> </P>

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

<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:
Kazuo Watanabe [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>Sent: dinsdag 1 mei 2001 6:27</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>Subject: RE: [M3UA] AS state machine sharing between
SGPs</FONT> </P>
<BR>

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

<P><FONT SIZE=2>&gt; In the case where there are multiple SGPs in an SG, and
the SGPs have</FONT> <BR><FONT SIZE=2>&gt; magically determined in their
coordinated MTP3 route management logic that</FONT> <BR><FONT SIZE=2>&gt; an
SS7 destination is now unavailable, should the SSNM message (i.e.,
DUPU</FONT> <BR><FONT SIZE=2>&gt; in this case) be sent from ALL SGPs to the
concerned ASPs.&nbsp; I assume the</FONT> </P>

<P><FONT SIZE=2>no.</FONT>
<BR><FONT SIZE=2>i think all concerned ASPs should receive but not all SGPs
should send.</FONT> <BR><FONT SIZE=2>because DUNA indicates SS7 route state
not SG/SGP state.</FONT> </P>

<P><FONT SIZE=2>&gt; answer is yes given the logic of the discussion on this
thread.&nbsp; So that</FONT> <BR><FONT SIZE=2>&gt; means that if the
triggering event is reception of TFP(s) from the SS7</FONT> <BR><FONT
SIZE=2>&gt; network, then all SGPs in an SG must coordinate their MTP3 view
of the</FONT> <BR><FONT SIZE=2>&gt; availability of the SS7
destination.&nbsp;&nbsp; Equivalent arguments can be made</FONT> <BR><FONT
SIZE=2>for</FONT>
<BR><FONT SIZE=2>&gt; virtually any SS7 link or route management
event.</FONT> </P>

<P><FONT SIZE=2>yes.</FONT>
<BR><FONT SIZE=2>i think this is `multiple SGPs in an SG.'</FONT> </P>

<P><FONT SIZE=2>i guess the difference between multiple SGs and multiple
SGPs in an SG is</FONT> <BR><FONT SIZE=2>mainly single Signalling Point or
multiple Signalling Points from SS7</FONT> <BR><FONT SIZE=2>point of
view.</FONT>
<BR><FONT SIZE=2>therefore the SG which has multiple SGPs should have one
MTP3 network</FONT> <BR><FONT SIZE=2>management function not per SGP.</FONT>
</P>

<P><FONT SIZE=2>in that case, each SGP could have different AS state and
should have</FONT> <BR><FONT SIZE=2>the same SS7 state.</FONT> </P>

<P><FONT SIZE=2>&gt; Also, if one SGP has determined an SS7 destination is
unavailable, but the</FONT> <BR><FONT SIZE=2>&gt; destination is still
available via other SGPs (a link event?), then I</FONT> <BR><FONT
SIZE=2>assume</FONT>
</P>

<P><FONT SIZE=2>according to my understanding, this is multiple SGs not
multiple SGPs in</FONT> <BR><FONT SIZE=2>an SG.</FONT>
</P>

<P><FONT SIZE=2>&gt; that the SGP would optionally send an DRST - although
we could make the</FONT> <BR><FONT SIZE=2>case</FONT>
<BR><FONT SIZE=2>&gt; that a DUPU could be used by SGP implementations that
don't redirect any</FONT> <BR><FONT SIZE=2>&gt; traffic received to the
other SGPs.&nbsp; I wouldn't recommend it though as</FONT> <BR><FONT
SIZE=2>this</FONT>
<BR><FONT SIZE=2>&gt; implies message loss.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Does this sound right?</FONT> </P>

<P><FONT SIZE=2>if you are saying about STP-like SGs configuration, it
sounds right to me.</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Kazuo Watanabe</FONT>
</P>
<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>
X-Lotus-FromDomain: TEKELEC
From: Joe Keller <[email-masked]>
To: "sigtran" <[email-masked]>
Date: Tue, 15 May 2001 15:47:59 -0400
Subject: RE: FW: M3UA Iss7 - Routing Key Overlap
X-SMTP-HELO: domino2.nc.tekelec.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: domino2.nc.tekelec.com [198.89.40.41]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

    Interesting problem.  The problem I have with this are what is sent to
the ASP1 when ASP2 asks for the "split".  I would expect the SG needs to
inform ASP1 that the routing key it registered for using some
Local-RK-Identifier is now two (at least two, I can think of more complex
scenarios) separate routing contexts.  After all, how would ASP1 indicate it
wanted to deregister for the original key?

Would you want to add a new RKM message just for this case?  Does the ASP
care how the routing keys are broken up?  I am sure the problem can be
solved and the SG will guarantee unique routing.
It seems like it needs more text than just changing the MUST to a SHOULD.

Joe

 -----Original Message-----

>Hi Joe,
>
>The application I seem to remember is where an SG could accept an
>overlapping RK and rearrange the configuration data to ensure unique
>routing.  For example, if ASP1 registered for DPC=X, CIC codes 1 - 100.
>Then later ASP2 came in and registered for DPC=x, CIC codes 1 - 50.  The SG
>could react by creating internally RK structures that allow both ASP1and
>ASP2 to receive traffic for CICs 1-50 and ASP1 to get 51-100.  How the
>actual traffic is distributed is determined by the traffic modes in the
>ASP-Actives.
>
>All this assumes that there is no change to the protocol needed (i.e., the
>SG handles this internally).  If so then how an SG does this is probably
>implementation dependent.  The key is that if an SG can do this and still
>ensure unique routing, then we should allow it.
>
>Hope this helps,
>
>   Greg
>
> -----Original Message-----
>From:    Joe Keller [mailto:[email-masked]]
>Sent:    Thursday, May 10, 2001 12:56 PM
>To: sigtran
>Subject: Re: FW: M3UA Iss7 - Routing Key Overlap
>
> << File: Internet HTML >> << File: footer >>
>Greg,
>
>    Can you clarify the valid cases for allowing overlapped routing key?
>We may need to add text to what you have already proposed.
>
>Thanks,
>Joe
>
>
>
>
>
>"Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]> on
>05/10/2001
>09:36:09 AM
>
>Please respond to [email-masked]
>
>To:   "sigtran" <[email-masked]>
>cc:    (bcc: Joe Keller/Raleigh/TEKELEC)
>Subject:  FW: M3UA Iss7 - Routing Key Overlap
>
>
>
>
>Resending - I sent (and resent) some e-some mails out yesterday and didn't
>see anything on the list, except for my test e-mail!.  Perhaps all my mails
>are being sent to "my sigtran archive" instead   2;^)
>
> -----Original Message-----
>From:     Sidebottom, Greg [BCNR:7M01:EXCH]
>Sent:     Wednesday, May 09, 2001 11:32 AM
>To:  [email-masked]'
>Subject:  M3UA Iss7 - Routing Key Overlap
>
>Greetings,
>
>An issue was raised against the current text where we explicitly mention
>that overlap of Routing Key information is not allowed.
>
>From Section 1.4.2.2:
>
>    "Routing Keys MUST be unique in the sense that a received SS7
>     signalling message cannot be matched to more than one Routing
>     Key."
>
>And in 4.3.4.1:
>
>    "If the SG determines that the Routing Key parameter overlaps
>     with an existing Routing Key entry, the SG returns a
>     Registration Response message to the ASP, with a Registration
>     Status of "Error - Overlapping (Non-Unique) Routing Key".  An
>     incoming signalling message received at an SG cannot match
>     against more than one Routing Key."
>
>I have heard the view that there may be some valid cases where a Routing
Key
>overlap is OK.  If so then perhaps we could replace the MUST with a SHOULD
>in 1.4.2.2.  For 4.3.4.1 the last line could be deleted and we could
>generalize the error response from "Overlapping (Non-Unique) RK" to
>something like "Cannot Support Routing on RK" and change the text around a
>bit to reflect that the problem is that the SG can't route if it allows
this
>RK.
>
>So to close on this - Is there support for this idea?  If so, are the above
>changes OK?
>
>Cheers,
>
>   Greg

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Asveren, Tolga" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Tue, 15 May 2001 15:06:09 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: smtp.adc.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp.adc.com [155.226.10.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,
 
I think the below discussion is about whether we need SGP concept or not.
Unless we say that they are sharing AS states, I don't see any reason to
have the SGP concept (According to me, practically it is the same to say
there is no SGP concept or to say every SG consist of one SGP).
But I believe on the importance of sharing AS states between SGPs.In fact it
is for sure, that some information should be shared, on SG level or on ASP
level or on both. If as an ASP, which is functioning as standby for some
ASs, I receive some AS-DOWN notification message there are two choices. If I
know, that all of SGP, I am connected (and also the active ASP for this AS,
is connected to) are sharing AS state, then I am sure, the active ASP is not
reachable via any of these SGPs (otherwise I wouldn't receive ASDOWN
message). So, I don't need to check anything with the other ASP and can send
an ASPAC. 
But, if SGPs are not sharing AS state, then after receiving the ASDOWN, I
should check with active ASP to see, whether it is reachable via another SG
or not, i.e. this time we should share SG-ASP connectivity per AS basis
between ASPs.
So, I think it is unavoidable sharing states at some level. When I think
conceptually, SG is functioning like a router on IP domain, so all of the
message routing responsibility should be there, i.e. every SGP, which is
serving the same AS should share the AS states. I also agree, that for
practical purposes, this will bring more complications to SG-developers. 
 
   Regards,
   Tolga

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:31 PM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Greetings, 

I'm tying to close out on this item for Issue 7.  There's been a few e-mails
with excellent input, but they do not all line up.  Further, we've had no
input from any SG vendor who is implementing this multiple SGP in an SG
architecture to help us with the issues.  I think it is worth pointing out
that unless there is more than one implementation of this and it is deemed
interoperable in a "bay-cough" this functionality would have to be dropped
out of the protocol eventually.

I liked the way Gery separated the issues out below.  Comments and proposed
conclusions below ... 

 -----Original Message----- 
From:   Verwimp Gery [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent:   Wednesday, May 02, 2001 8:17
AM To:     sigtran 
Subject:        RE: [M3UA] AS state machine sharing between SGPs 

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2
cents on this topic anyway ;-)) 

We're talking about redundancy on three different levels, I think : 

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as
well, or am I missing something here ? (Multiple routes, handled by multiple
processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is
responsible of informing layer management of it's part of the view (status
of physical connections). 

[Greg] I think that the "multiple SGP in an SG" view is really only useful
to support a "Distributed SG" implementation.  This Distributed SG would be
implemented with SGPs on two or more Hosts, probably in different locations
to get geographical redundancy.  Otherwise, the SCTP multi-homing
functionality can be used to handle this part of the redundancy,
implementing multiple processors and routes as Gery points out.  (Although
Kazuo Watanabe correctly pointed out that if we are using TCP instead of
SCTP we wouldn't have this SCTP multi-homing and would need a further
remedy) 

In other words, why would I build two local SGPs on a Host and go through
all the pain of coordinating their MTP3 and SPMC state to the SS7 network
and AS/ASP state to the IP side, when all I have to do is use SCTP's
multi-homing feature to get the same redundancy.  

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG. 

[Greg] Agreed.  For this redundancy, I have previously mentioned that the
Operator must ensure that the ASPs use SGPs or SGs that are on different
Hosts.  Gery adds that the SGPs would probably also need to be in different
locations.  So this is covered either way.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic. 

[Greg] Agreed.  This has no bearing on the SGP / SG issue. 

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two. 

Any views on this ? 

[Greg] I think it is fair to conclude that having multiple SGPs in an SG
does not in itself buy any extra functionality in terms of redundancy over
the multiple SG model.  I think we've been bending over backwards in the
protocol description to accommodate an implementation option (the
"distributed multi-site SG" described above).   So where does this
implementation option make sense? - I think the answer is for the case where
the signalling between the PSTN and IP networks is to go through a single SG
with a single SS7 Point code but with site/processor redundancy for the SG.
Paired SGs won' t do because two Point Codes would be required.   I don't
really have problem with supporting this case.     

I think we can change a few things in the spec to support this but remove
some of the confusion that it brings: 

1) Simplify the protocol description so it is described as between an SGP
and ASP only.  That is, SCTP associations are always between SGPs and ASPs.
Today the spec goes back and forth between the SGP and SG terms and adds
qualifying text in various places. 

2) The SG becomes explicitly a virtual thing not unlike an AS, containing
one or more SGPs.  The spec today seems to shade back and forth on whether
an SG is a physical thing or not.  Of course if an SG is implemented using a
single SGP, then that is fine  2;^)

So a paired SG architecture is now two SGPs on different hosts represented
to the SS7 network with a Point Code per host.  No coordination of MTP3,
SPMC or AS/ASP states between the SGPs is required.  A single distributed SG
is the same except that it is represented to the SS7 network with a single
SS7 Point Code for the set of SGPs.  The SGPs SHOULD support MTP3, SPMC and
AS/ASP state sharing and re-routing of traffic between the two SGPs.  How
the inter-SGP protocol accomplishes this is not described in the protocol
spec.   

3) The ASPs do not need to know the grouping of SGPs in virtual SGs so they
treat each SGP as an independent route out to the SS7 network.  But an ASP
MAY choose to maintain such knowledge.   The SSNM messaging from the SGPs to
the ASP is therefore processed independently.  Note that for Operators that
choose not to combine SGPs into virtual SGs (i.e., use paired physical SGs),
then nothing has really changed here.   ASPs that choose to keep knowledge
of SGP groupings into virtual SGs MAY interpret SSNM messaging from one of
the SGPs so as to apply to all the SGPs in the virtual SG but should only do
so if the SGPs coordinate their SSNM messaging to the ASPs.

Hope this helps, 

   Greg Sidebottom 

____________________________ 

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

-----Original Message----- 
From: Kazuo Watanabe [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent: dinsdag 1 mei 2001 6:27 
To: sigtran 
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs 

Greg, 

> In the case where there are multiple SGPs in an SG, and the SGPs have 
> magically determined in their coordinated MTP3 route management logic that

> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU

> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the 

no. 
i think all concerned ASPs should receive but not all SGPs should send. 
because DUNA indicates SS7 route state not SG/SGP state. 

> answer is yes given the logic of the discussion on this thread.  So that 
> means that if the triggering event is reception of TFP(s) from the SS7 
> network, then all SGPs in an SG must coordinate their MTP3 view of the 
> availability of the SS7 destination.   Equivalent arguments can be made
for 
> virtually any SS7 link or route management event. 

yes. 
i think this is `multiple SGPs in an SG.' 

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view. 
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP. 

in that case, each SGP could have different AS state and should have the
same SS7 state. 

> Also, if one SGP has determined an SS7 destination is unavailable, but the

> destination is still available via other SGPs (a link event?), then I
assume 

according to my understanding, this is multiple SGs not multiple SGPs in an
SG. 

> that the SGP would optionally send an DRST - although we could make the
case 
> that a DUPU could be used by SGP implementations that don't redirect any 
> traffic received to the other SGPs.  I wouldn't recommend it though as
this 
> implies message loss. 
> Does this sound right? 

if you are saying about STP-like SGs configuration, it sounds right to me. 

-- 
Kazuo Watanabe 

---
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, 15 May 2001 18:19:02 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Public Linux Kernel implementation of SCTP
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
User-Agent: Mutt/1.2i
Organization: OpenSS7 Corporation
Dsn-Notification-To: <[email-masked]>
X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      SAA07566
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-230.dallas.net [209.44.42.230]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

We are pleased to announce the public release of the OpenSS7 SCTP
implementation for the Native Linux Kernel.  This release of the
implementation is essentially the code which was tested at the 3rd SCTP
Bakeoff at ETSI April 23-27.

This code is an Alpha release (somewhat stable but still hangs and crashes
ocassionally, so be warned).

The code can be downloaded from

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

in the file:

        http://www.openss7.org/linux-sctp-0.1.tgz

The code is released under Linux Kernel (modified) GPL and includes a patch
to the RedHat Linux 2.2.12-20 kernel (but should work for others).  Also
included is a Linux man page and the test programs and some Ethereal dumps
from the ETSI Bakeoff.

Comments and contributions are welcome, but please use our mailing list
rather than the WG lists for questions and comments related to the code.

-- 
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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Tue, 15 May 2001 16:57:10 -0700
To: "sigtran" <[email-masked]>
From: Lyndon Ong <[email-masked]>
Subject: RFC 2960bis Issues
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]>
Reply-To: [email-masked]

<x-flowed>Folks,

There has been a slew of messages, mostly on two SCTP issues: IPv6
addressing and the checksum.

Regarding the IPv6 addressing issue, the immediate answer is to move the
entire scoping discussion to a separate document, as RFC2960bis is probably
not the right place to cover this.  The bis document should provide the
formats for IPv6, and at most perhaps some note to guide people away from
the most serious problems.

Regarding the checksum, let's go back to the original issue:

-- we settled on checksum rather than CRC in the original spec because we
felt that checksum was significantly easier to support and that other
mechanisms such as link level CRC and (if present) digital signatures would
provide added error detection capability.

-- the issue was raised as to whether the Adler-32 that was in RFC 2960 had
some serious error detection drawbacks, especially for short signaling
messages.  We are therefore reconsidering the Adler-32.

We need to revisit these questions:

a) was the original decision correct to use checksum rather than CRC?
current view seems to be yes. although ips would prefer CRC, they can live
with checksum.

b) is there a problem with the original Adler-32?  current view was yes,
although Doug's email raises some questions.
(We could, of course, solve the whole bis issue by deciding that Adler-32
was fine)

c) if not the Adler-32, then what would be better?  we have modified Adler
and Fletcher under consideration.  It shouldn't be extremely hard to pick an
alternative.

Cheers,

L. Ong

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked] </x-flowed>
Date: Tue, 15 May 2001 18:20:42 -0700 (PDT)
From: Mailing List <[email-masked]>
Subject: BICC vs. ISUP???
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web14304.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [216.136.173.80]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all:

I recently come across BICC, and found that it's actually pretty similar to
ISUP (in fact, it's just a few exceptions to ISUP).  

Why does BICC exist as a new protocol?  How is it going to be used to
replace ISUP?

Thanks very much in advance,

Patrick.

__________________________________________________ Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: =?ks_c_5601-1987?B?wMzA57/4?= <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Routing Key Management in SUA
Date: Wed, 16 May 2001 11:51:33 +0900
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-SMTP-HELO: telcoin.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [211.47.132.29]
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=ks_c_5601-1987" http-equiv=Content-Type>
<META content="MSHTML 5.00.2920.0" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>Hi all. </FONT></DIV> <DIV><FONT size=2>May I ask two
questions?</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT size=2>First, Is there any reason for not using RKM messages in
SUA?</FONT></DIV>
<DIV><FONT size=2>How can I bind the routing key in SG and routing context
in ASP without RKM messages? manually?</FONT></DIV> <DIV><FONT
size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Second, </FONT><FONT size=2>in the end of SUA-v5 1.3.1.1,
</FONT></DIV>
<DIV><FONT size=2>"Further messages from the SEP belonging to the same TCAP
transaction will now reach the same ASP"&nbsp; is mensioned.</FONT></DIV>
<DIV><FONT size=2>BUT, I wonder&nbsp;if&nbsp;that&nbsp;is
possible.</FONT>&nbsp;</DIV>
<DIV><FONT size=2>If&nbsp;that is possible by storing &amp; comparing TCAP
Transaction ID, is that a violation of the layered
architecture?</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>Thanks</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>Lee, Jae Won</FONT></DIV></BODY></HTML>
b<sç.®·§¶\¬¹»®&ÞvÚ,S
kjv¬-)Ý¢z'EURE9'Â8Äèº{.nÇ+?·¬zwZnV§'ésS[h*æ¯zÈ ¶¶§Û^:R\«SÉè®×¥ëp¢¹,
</x-html>
From: Young Michael-Y10724 <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Interworking Between SUA and SCCP/M3UA
Date: Wed, 16 May 2001 01:28:49 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: motgate2.mot.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: motgate2.mot.com [136.182.1.10]
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.2654.19">
<TITLE>RE: Interworking Between SUA and SCCP/M3UA</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Assume if the interworking is done at SGW, there is no
difference in terms of protocol.&nbsp; To SCCP-user layer, it doesn't
care.</FONT></P>

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

<P><FONT SIZE=2>Michael Young </FONT>
<BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> <BR><FONT SIZE=2>System Design, GTSS Vancouver, Motorola </FONT>
<BR><FONT SIZE=2>Tel: +1 (604)241-6032&nbsp;&nbsp; Cel: +1 (604)726-6609
</FONT> <BR><FONT SIZE=2>Email: [email-masked] </FONT> <BR><FONT
SIZE=2>---------------------------------------------------------------
</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt;
From: Chiang Robin-RCHIANG2 </FONT> <BR><FONT SIZE=2>&gt; [<A
HREF="mailto:[email-masked]">mailto:Robin_Chiang-RCHIAN
[email-masked]</A>]</FONT> <BR><FONT SIZE=2>&gt; Sent: Tuesday, May 15,
2001 2:58 AM</FONT> <BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT
SIZE=2>&gt; Subject: RE: Interworking Between SUA and SCCP/M3UA</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Michael,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the case of SUA interworking with legacy SS7
protocol, the </FONT> <BR><FONT SIZE=2>&gt; two endpoints</FONT> <BR><FONT
SIZE=2>&gt; are in different domains i.e. IP and SS7.</FONT> <BR><FONT
SIZE=2>&gt; As for interworking between SUA and SCCP/M3UA, the two </FONT>
<BR><FONT SIZE=2>&gt; endpoints are in the</FONT> <BR><FONT SIZE=2>&gt; IP
domains. One difference is the routing using MTP3 and SCTP.</FONT> <BR><FONT
SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Robin Chiang Cher Nung</FONT> <BR><FONT SIZE=2>&gt;
[email-masked] &lt;<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>&gt;
</FONT> <BR><FONT SIZE=2>&gt; Motorola GSM Systems Division</FONT> <BR><FONT
SIZE=2>&gt; GSM Research Group</FONT> <BR><FONT SIZE=2>&gt; 16 Euroway,
Blagrove, Swindon,</FONT> <BR><FONT SIZE=2>&gt; Wiltshire SN5 8YQ.</FONT>
<BR><FONT SIZE=2>&gt; Tel: +44 1793 566237</FONT> <BR><FONT SIZE=2>&gt;
Mobile: 07808 949599</FONT> <BR><FONT SIZE=2>&gt; Fax: +44 1793
566225</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt; From: [email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>&gt; Sent: Tuesday, May 15, 2001 7:59 AM</FONT>
<BR><FONT SIZE=2>&gt; To: sigtran</FONT> <BR><FONT SIZE=2>&gt; Subject: RE:
Interworking Between SUA and SCCP/M3UA</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Michael,</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Quick question regarding interworking between SUA and
</FONT> <BR><FONT SIZE=2>&gt; SCCP/M3UA, personally</FONT> <BR><FONT
SIZE=2>&gt; I don't see any difference comparing to SUA interworking with
</FONT> <BR><FONT SIZE=2>&gt; legacy SS7</FONT> <BR><FONT SIZE=2>&gt;
protocols (SCCP/MTP3).&nbsp; Did I miss anything?&nbsp; Please correct
</FONT> <BR><FONT SIZE=2>&gt; me if I am</FONT> <BR><FONT SIZE=2>&gt;
wrong.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [&lt;JAL&gt; ] I don't think so.</FONT> <BR><FONT
SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send a
blank email to</FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---</FONT>
<BR><FONT SIZE=2>&gt; You are currently subscribed to sigtran as:
[email-masked]</FONT> <BR><FONT SIZE=2>&gt; To unsubscribe send
a blank email to </FONT> <BR><FONT SIZE=2>&gt;
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;
</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]
To: "sigtran" <[email-masked]>
Subject: RE: [Tsvwg] RFC 2960bis Issues
Date: Wed, 16 May 2001 09:26:31 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Lyndon,

> Regarding the IPv6 addressing issue, the immediate answer is 
> to move the entire scoping discussion to a separate document, as 
> RFC2960bis is probably not the right place to cover this.  
> The bis document should provide the formats for IPv6, and at most 
> perhaps some note to guide people away from the most serious problems.

I think we should have some minimum text about the IPv6 addresses.
Do we have a schedule for the the bis draft?  Is there a time frame for
getting it published, last called, etc?

Thanks,
John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Kiely, Gareth" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)
Date: Wed, 16 May 2001 04:33:00 -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]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi all,

Any implicit assumptions about how the spec is going to be implemented is
going to put the credibility of the whole standard at risk.

We have particular reasons for wishing to keep our SCTP in user-land
(including a requirement to support many operating systems) and are already
developing products based on our user-land implementation which we expect to
be around for ten years.

----------------------------------------------------------------------
Gareth Kiely            Principal Engineer            DataKinetics Ltd Tel:
+44 (0)1425 651329                        Fax: +44 (0)1425 655075 21 Green
Lane       Fordingbridge       Hants       SP6 1HU         UK
---------------------------------------------------------------------- 

> -----Original Message-----
> From: Jim Bound [mailto:[email-masked]]
> Sent: 15 May 2001 19:05
> To: sigtran
> Cc: Kacheong Poon; Randall Stewart at work;
> [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)
> 
> 
> Qiaobing,
> 
> Do you really believe SCTP user space implementation will 
> exist 3 years
> from now or the telcos will buy a platform from a vendor who 
> has a user
> space SCTP implementation over a kernel based implementation.  A user
> space SCTP can never run as fast as a kernel based one.  
> Unless user space
> is defined as the VM370 arch was in the past or possibly MACH 4.0+.
> 
> thanks
> 
> /jim
> 
> On Tue, 15 May 2001, Qiaobing Xie wrote:
> 
> > Jim and others:
> > 
> > As far as the SCTP bis is concerned, I think we are getting 
> closer to a
> > conclusion on this issue.
> > 
> > One observation I'd like to make is: for the most part of this
> > discussion we seem to have overlooked the fact that SCTP is 
> NOT solely a
> > kernel protocol, and as a matter of fact there exists many user-land
> > implementations today and they will continue to exist in 
> the future. If
> > we put restrictions in the base spec to disallow certain behavior or
> > way-of-use only because it makes little sense or is hard to 
> implement in
> > the context of a kernel implementation, we may 
> inadvertently harm the
> > usability of the protocol in a broader scope.
> > 
> > regards,
> > -Qiaobing
> > 
> > Jim Bound wrote:
> > > 
> > > right???   are folks still writing code or what?  we are 
> saying we are
> > > going to jump into the transport space or have an extra 
> search on the
> > > common client in the kernel to whack the associations 
> address parameters
> > > because we don't want to adheer to Randys' rule set for 
> the NAT case in
> > > IPv6 where there are plenty of global addresses.  This is 
> plain wrong.
> > > I thought for sure the right thing would be done.  Oh 
> well. Very bogus.
> > > 
> > > /jim
> > > 
> > > On Mon, 14 May 2001, Kacheong Poon wrote:
> > > 
> > > > > Hmm, I have thought on this... and yes it might be 
> worth it... but
> > > > > in the case of v4 we also have NAT's murking up the 
> picture. In the
> > > > > case you illustrate... most likely if the sender does 
> send outside of
> > > > > his private address space a big ugly NAT will grab 
> and change his
> > > > > INIT addresses in at minimum the source address and 
> more likely
> > > > > it will strip all the TLV's out (yuck.. how ugly).
> > > >
> > > > I am not familiar with the latest NAT stuff.  So do 
> they also modify
> > > > transport level content now?  The problem we are 
> talking here is in
> > > > the address param list.  So the NAT has to understand 
> SCTP and how
> > > > to modify the address param list.  Is NAT really doing 
> this kind of
> > > > things now, say on the TCP bits?  I know they may 
> reject ECN bits,
> > > > but to modify them, I don't know.
> > > >
> > > > > IPV4 is convoluted by definition since many things 
> are broken with
> > > > > addressing aka NAT's etc.
> > > >
> > > > Well, even without NAT, we still need to solve the problem.  And
> > > > treating private v4 addresses as v6 site local will not 
> work here.
> > > >
> > > > > This does not remove control from the application... 
> If I only bind
> > > > > a link local address in my SCTP endpoint I will only 
> be able to
> > > > > talk to peer link-locals.. Same for site-local.. bind only a
> > > > > site-local and you only talk to peer site-locals... Its when
> > > > > you bind INADDR_ANY that this whole mess begins to 
> play out. In
> > > > > this case the user is punting, or for that matter if 
> the user makes
> > > > > a grevious error... having the rules in places does 
> exactly what
> > > > > Erik's statement above requests..... they may need to 
> be refined
> > > > > as Erik as pointed out by using source and 
> destination addresses...
> > > >
> > > > Using your wordings, the app loses its control if it tries to do
> > > > what your rules prohibit but may be perfectly legal in 
> a certain setup.
> > > > The SCTP stack should fail those special binding when 
> it is forming the
> > > > address param list.  That's the reason why I think we 
> should not put
> > > > the rule in the bis at this point.
> > > >
> > > > Glad to hear that we seem to have a conclusion on this issue.
> > > >
> > > >                                                       K. Poon.
> > > >                                                       
> [email-masked]
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > > >
> > > 
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > 
> 
> 
> 
> ---
> 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: "Rosen, Brian" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: BICC vs. ISUP???
Date: Wed, 16 May 2001 07:48:09 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: mailgate.pit.comms.marconi.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [169.144.68.6]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

This is the wrong list to discuss BICC.
Try the ITU SG11 list.

The answer is that BICC is an extension to ISUP to allow it to describe
IP/ATM/FR bearers.  It allows you to use ISUP signalling (on the existing
SS7/C7 signalling network if you wish), but packet/cell-over-voice bearers
instead of TDM bearers.

Brian

-----Original Message-----
From: Mailing List
To: sigtran
Sent: 5/15/01 9:20 PM
Subject: BICC vs. ISUP???

Hi all:

I recently come across BICC, and found that it's actually pretty similar to
ISUP (in fact, it's just a few exceptions to ISUP).  

Why does BICC exist as a new protocol?  How is it going to be used to
replace ISUP?

Thanks very much in advance,

Patrick.

__________________________________________________ Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---
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: Routing Key Management in SUA
Date: Wed, 16 May 2001 14:48:43 +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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Jae Won,

> First, Is there any reason for not using RKM messages in SUA?

The main reason is because the RKM functions are quite complex.  My feeling
is that SUA can take advantage of the Address Mapping Function (currently
under discussion) to map to the correct signaling endpoints.

I'm not so sure that the RKM messages will provide enough useful
functionality
to include them.  Comments would be appreciated.

> How can I bind the routing key in SG and routing context in ASP 
> without RKM messages? manually?

Right now, it seems that Routing Keys would not be needed.  

> Second, in the end of SUA-v5 1.3.1.1, 
>"Further messages from the SEP belonging to the same TCAP transaction
> will now reach the same ASP"  is mensioned.
>
> BUT, I wonder if that is possible. 
> If that is possible by storing & comparing TCAP Transaction ID, is 
> that a violation of the layered architecture?

It is possible, Signaling Gateways already do all sorts of tricks. This is
something
that would be implementation specific, however.

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 16 May 2001 08:37:16 -0400 (EDT)
From: Scott Bradner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [Tsvwg] SCTP and NAT traversal in the Applicability Statement .
X-SMTP-HELO: newdev.harvard.edu
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: newdev.eecs.harvard.edu [140.247.60.212]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> If comments from IESG indicates changes to upper or lower case, then we'll
> take that into account, but up till now, no indication has appeared that
> this uppercase stuff is mandatory for a applicability statement.

(MUST etc)
it is not mandatory for a applicability statement in general it is not even
a good idea in a applicability statement

Scott

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Sender: [email-masked]
Date: Wed, 16 May 2001 07:37:45 -0500
From: "Randall R. Stewart" <[email-masked]>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.17-14 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-otis-sctp-digest-00.txt
X-SMTP-HELO: stewart.chicago.il.us
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: user196.64.37.247.dsli.com [64.37.247.196]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ran:

Has usual I agree with you.. I have not read the draft (shame on me) but we
can already use a IP Auth header to provide the same thing. Why would we
want to re-invent the wheel.

I think the issue Doug is trying to address is the CRC issue... but if the
AH works for this lets use it :/

R

RJ Atkinson wrote:
> 
> Folks,
> 
>         The draft below appears to partially replicate the already
> existing IETF Standard known as the IP Authentication Header.
> I say "partially", because it is no less expensive computationally
> but provides less comprehensive protections than IP AH.
> 
>         IMHO, the WG needs to closely consider whether the existing
> text about IP AH in SCTP RFC's "Security Considerations"
> section is sufficient.  Perhaps SIGTRAN does not in fact need
> to re-invent this particular wheel.
> 
>         There is a broad tendency of many WGs in the IETF to
> re-invent wheels, either by accident or intent.  The tendency
> to re-invent wheels is not very helpful in retaining broad
> interoperability or in having a consistent Internet Architecture.
> 
> Cheers,
> 
> Ran
> [email-masked]
> 
> >To: IETF-Announce: ;
> >From: [email-masked]
> >Reply-To: [email-masked]
> >Subject: I-D ACTION:draft-otis-sctp-digest-00.txt
> >Date: Mon, 14 May 2001 07:35:06 -0400
> >Sender: [email-masked]
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> >
> >
> >        Title           : Integrity-Authentication Digest for SCTP
> >        Author(s)       : D. Otis
> >        Filename        : draft-otis-sctp-digest-00.txt
> >        Pages           :
> >        Date            : 11-May-01
> >
> >This document is to allow the inclusion of a digital signature within
> >the SCTP [RFC2960] packet.  This digital signature, or digest, would
> >be negotiated on a per Association basis.  The means of negotiation
> >and use is beyond the scope of this document.
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to
[email-masked]

-- 
Randall R. Stewart
[email-masked] or [email-masked] 815-342-5222 (cell)
815-477-2127 (work)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Adams, Russell" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [Tsvwg] RFC 2960bis Issues
Date: Wed, 16 May 2001 08:39:08 -0700
X-Mailer: Internet Mail Service (5.5.2652.78)
X-SMTP-HELO: zcamail05.zca.compaq.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: zcamail05.zca.compaq.com [161.114.32.105]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Is the BIS posted for review?    -Russell

-----Original Message-----
From: Randall R. Stewart [mailto:[email-masked]] Sent:
Wednesday, May 16, 2001 06:32
To: sigtran
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Tsvwg] RFC 2960bis Issues

John:

My current plan/thoughts are as follows:

1) Get a new BIS out today with NO text on IPv6 2) Talk to Steve D next
week.
3) Post a detailed explanation to the NG working group
   with a proposed set of rules.
4) See if we can reach an agreement within a week or so.
5) If we can include the agreed text into the next BIS.

I do have the feeling it will be along the lines of Erik's comments.

R

[email-masked] wrote:
> 
> Hi Lyndon,
> 
> > Regarding the IPv6 addressing issue, the immediate answer is
> > to move the entire scoping discussion to a separate document, as
> > RFC2960bis is probably not the right place to cover this.
> > The bis document should provide the formats for IPv6, and at most
> > perhaps some note to guide people away from the most serious problems.
> 
> I think we should have some minimum text about the IPv6 addresses.
> Do we have a schedule for the the bis draft?  Is there a time
> frame for getting it published, last called, etc?
> 
> Thanks,
> John
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[email-masked] or [email-masked] 815-342-5222 (cell)
815-477-2127 (work)

---
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: Wed, 16 May 2001 10:44:10 -0500
From: "Randall R. Stewart" <[email-masked]>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.17-14 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: [Tsvwg] RFC 2960bis Issues
X-SMTP-HELO: stewart.chicago.il.us
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.37.247.196]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Russell:

The BIS was sent in at 10:40 last Friday... it appears there may have been
some mix-up with the drafts editor though.. or maybe it was my lack of DSL
:<

Anyway we are working the issues out and it should appear shortly..

R

"Adams, Russell" wrote:
> 
> Is the BIS posted for review?    -Russell
> 
> -----Original Message-----
> From: Randall R. Stewart [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 06:32
> To: sigtran
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] RFC 2960bis Issues
> 
> John:
> 
> My current plan/thoughts are as follows:
> 
> 1) Get a new BIS out today with NO text on IPv6
> 2) Talk to Steve D next week.
> 3) Post a detailed explanation to the NG working group
>    with a proposed set of rules.
> 4) See if we can reach an agreement within a week or so.
> 5) If we can include the agreed text into the next BIS.
> 
> I do have the feeling it will be along the lines of Erik's comments.
> 
> R
> 
> [email-masked] wrote:
> >
> > Hi Lyndon,
> >
> > > Regarding the IPv6 addressing issue, the immediate answer is
> > > to move the entire scoping discussion to a separate document, as
> > > RFC2960bis is probably not the right place to cover this.
> > > The bis document should provide the formats for IPv6, and at most
> > > perhaps some note to guide people away from the most serious problems.
> >
> > I think we should have some minimum text about the IPv6 addresses.
> > Do we have a schedule for the the bis draft?  Is there a time
> > frame for getting it published, last called, etc?
> >
> > Thanks,
> > John
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
> 
> --
> Randall R. Stewart
> [email-masked] or [email-masked]
> 815-342-5222 (cell) 815-477-2127 (work)
> 
> ---
> 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]

-- 
Randall R. Stewart
[email-masked] or [email-masked] 815-342-5222 (cell)
815-477-2127 (work)

---
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 5.1
Date: Wed, 16 May 2001 12:00:28 -0400
To: "sigtran" <[email-masked]>
From: RJ Atkinson <[email-masked]>
Subject: RE: [Tsvwg] Re: IPsec AH
Cc: [email-masked]
X-SMTP-HELO: gnat.inet.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [63.108.254.91]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

At 11:41 16/05/01, Fairlie-Cuninghame, Robert wrote:

>Also IPSEC AH requires Security Associations for all permutations of source
and destination addresses in an association as well as a key-management and
distribution mechanisms.

        True in a pedantic sense, but misleading.  IN_ADDR_ANY is a possible
valid address for any IPsec address binding, either source or destination.
If the same key (e.g. all 1s) were used when the goal were checksum but not
security, then key management/distribution is not an issue either.

        That noted, I'm not advocating using AH to provide a mundane
checksum, just noting that the computational costs of *any* cryptographic
MAC will be unduly high when a mundane checksum is all we need.

        To be honest, I think a Fletcher checksum would be more than
adequate here.  I don't think we need perfection for our mundane checksums.

Ran

---
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: Routing Key Management in SUA
Date: Wed, 16 May 2001 12:26:32 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
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=KS_C_5601-1987">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: Routing Key Management in SUA</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Greetings John,</FONT>
</P>

<P><FONT SIZE=2>Comments, concerns below ...</FONT> </P>

<P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From:
[email-masked] [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</F
ONT> <BR><FONT SIZE=2>Sent: Wednesday, May 16, 2001 7:49 AM</FONT> <BR><FONT
SIZE=2>To: sigtran</FONT>
<BR><FONT SIZE=2>Subject: RE: Routing Key Management in SUA</FONT> </P>

<P><FONT SIZE=2>Hi Jae Won,</FONT>
</P>

<P><FONT SIZE=2>&gt; First, Is there any reason for not using RKM messages
in SUA?</FONT> </P>

<P><FONT SIZE=2>The main reason is because the RKM functions are quite
complex.&nbsp; My feeling</FONT> <BR><FONT SIZE=2>is that SUA can take
advantage of the Address Mapping Function (currently</FONT> <BR><FONT
SIZE=2>under discussion) to map to the correct signaling endpoints.</FONT>
</P>

<P><FONT SIZE=2>[Greg] I believe RK management and Address Mapping is
(mostly) orthogonal so I don't think it is one or the other here.&nbsp; The
Address Mapping defines how the messages are routed to the appropriate
AS/ASP.&nbsp; The RKM function would allow ASPs to register/deregister as an
entity in an AS pool.&nbsp; In the process of registering/deregistering it
is possible to allow creation/deletion of the RK configuration data that
defines the AS.</FONT></P>

<P><FONT SIZE=2>I'm not so sure that the RKM messages will provide enough
useful</FONT> <BR><FONT SIZE=2>functionality</FONT>
<BR><FONT SIZE=2>to include them.&nbsp; Comments would be
appreciated.</FONT> </P>

<P><FONT SIZE=2>&gt; How can I bind the routing key in SG and routing
context in ASP</FONT> <BR><FONT SIZE=2>&gt; without RKM messages?
manually?</FONT> </P>

<P><FONT SIZE=2>Right now, it seems that Routing Keys would not be needed.
</FONT> </P>

<P><FONT SIZE=2>[Greg] Whoa!&nbsp; This is a huge difference from saying we
don't need RKM.&nbsp; So lets be very clear here.&nbsp; The Routing Key
defines the set of SS7 parameters/ranges to be used for uniquely routing
incoming messages to an AS.&nbsp;&nbsp; It now sounds like you are not just
thinking about not using RKM but completely changing the routing and also to
do away with all (or some) of ASP management?&nbsp; Or are you proposing
that we need to collapse the process of selecting the AS (based on the RK)
and then the ASP (based on ASP management) into a single step AMF (based on
the Called Address from the SCCP-User or SUA Destination Address and ASP
management)?&nbsp; To me this implies are now designing a new SCCP+ rather
than an adaptation layer.</FONT></P>

<P><FONT SIZE=2>Remembering some e-mail threads form Lode, Gery, yourself
and others I think it is finally dawning on me that it is probably the
latter.&nbsp;&nbsp; Either way this is a major change in direction here that
we should bring out for explicit discussion on the list.&nbsp;&nbsp; I think
this could be a major problem for the SG architecture.&nbsp; Sorry if I am
over-reacting but a switch went off in my head and I see all kinds of
problems for the SG architecture case where I would effectively have an SCCP
layer and now an SUA layer that is an SCCP+.</FONT></P>

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

<P><FONT SIZE=2>&gt; Second, in the end of SUA-v5 1.3.1.1,</FONT> <BR><FONT
SIZE=2>&gt;&quot;Further messages from the SEP belonging to the same TCAP
transaction</FONT> <BR><FONT SIZE=2>&gt; will now reach the same
ASP&quot;&nbsp; is mensioned.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; BUT, I wonder if that is possible.</FONT> <BR><FONT
SIZE=2>&gt; If that is possible by storing &amp; comparing TCAP Transaction
ID, is</FONT> <BR><FONT SIZE=2>&gt; that a violation of the layered
architecture?</FONT> </P>

<P><FONT SIZE=2>It is possible, Signaling Gateways already do all sorts of
tricks. This is</FONT> <BR><FONT SIZE=2>something</FONT>
<BR><FONT SIZE=2>that would be implementation specific, however.</FONT> </P>

<P><FONT SIZE=2>John</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]
To: "sigtran" <[email-masked]>
Subject: RE: Routing Key Management in SUA
Date: Wed, 16 May 2001 14:48:43 +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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Jae Won,

> First, Is there any reason for not using RKM messages in SUA?

The main reason is because the RKM functions are quite complex.  My feeling
is that SUA can take advantage of the Address Mapping Function (currently
under discussion) to map to the correct signaling endpoints.

I'm not so sure that the RKM messages will provide enough useful
functionality
to include them.  Comments would be appreciated.

> How can I bind the routing key in SG and routing context in ASP 
> without RKM messages? manually?

Right now, it seems that Routing Keys would not be needed.  

> Second, in the end of SUA-v5 1.3.1.1, 
>"Further messages from the SEP belonging to the same TCAP transaction
> will now reach the same ASP"  is mensioned.
>
> BUT, I wonder if that is possible. 
> If that is possible by storing & comparing TCAP Transaction ID, is 
> that a violation of the layered architecture?

It is possible, Signaling Gateways already do all sorts of tricks. This is
something
that would be implementation specific, however.

John

---
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, 16 May 2001 22:46:31 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Draft 7 - Assorted Queries
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]

Mark,

I'm on vacation till next Monday.  Will respond to your email then.

Regards,

Ken

At 01:59 PM 5/11/01 +0100, you wrote:
>Hi,
>
>I have a few queries with the M2UA spec.
>
>1) Section 1.4.2. The first paragraph reads as though there might be
>something missing immediately following the paragraph. More specifically 
>the last sentence reads "These primitives are shown below:" but there are 
>none listed.
>
>Or is this referring to the primitives in section 1.4.3?
>
>2) Section 3.3.3.2. When an AS sends out a AS_State_Change Notify message
>does it send it to all ASPs (except the ones that are Down) or just the 
>active one(s)?
>
>3) Section 4.2.1 first para. Does the "(Error)" in the first sentence
>refer to the Error Message? If so it makes little sense in the context.
>
>Cheers,
>Mark
>
>
>
>---
>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, 17 May 2001 10:39:34 +0200 (MEST)
From: ecejoz <[email-masked]>
Reply-To: [email-masked]
Subject: M3UA participants list
To: "sigtran" <[email-masked]>
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Hi Kevin,

The following companies were at the 1st M3UA Interop Test.

Adax
Datakinetics
Ericsson Spain (host of the event)
Ericsson USA
Hughes
Intellinet
Nec
Performance Tech.
Open Telecom
OpenSS7
Radisys
Siemens
Telesoft
Telesys
Trillium
Ulticom

For further information you can visit the Interop's home page at

http://standards.ericsson.net/m3ua-interop/  
but I can not be sure about how long this information is going to be on
line. 

If I can help you in something more, please do not hesitate in contact me
again.

Regards

/Jaime Olivares

>From: Kevin McCandless <[email-masked]>
>To: "'ecejoz'" <[email-masked]>
>Subject: RE: Final report from the Interop Test
>Date: Wed, 16 May 2001 08:38:06 -0700
>MIME-Version: 1.0
>Content-Transfer-Encoding: quoted-printable
>
>Do you have a list of participating companies from the M3UA interop?
>
>Sincerely,
>
>Kevin McCandless 
>Senior Network Planner 
>Illuminet 
>913-814-6397 
>[email-masked] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 17 May 2001 09:13:34 -0400 (EDT)
From: Scott Bradner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: RFC 2960bis Issues
X-SMTP-HELO: newdev.harvard.edu
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [140.247.60.212]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

please move ALL discussions of SCTP to the tsvwg mailing list

Mailing Lists: 

General Discussion:[email-masked] 
To Subscribe: [email-masked] 
In Body: subscribe email_address 
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/ 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 17 May 2001 09:36:05 -0700 (PDT)
From: Lyndon Ong <[email-masked]>
Subject: M3UA Bakeoff
To: "sigtran" <[email-masked]>
X-SMTP-HELO: web13908.mail.yahoo.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [216.136.175.71]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Folks,

I'd just like to give a personal note of thanks to Jaime Olivares for
keeping the list up-to-date on the M3UA bakeoff testing, and to the rest of
the folks at Ericsson for sponsoring what looks to have been a very
successful test event.

Cheers,

L. Ong

__________________________________________________ Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "May, Howard" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Thu, 17 May 2001 08:18:09 -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]

Hello,

I have inserted comments in more than one of the previous emails, there are
some at the bottom of Gery's

I recognise your comments about input from vendors implementing a
distributed SGP.  I think to drop this would be a great shame, I will try
and add my pennies worth.

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 15 May 2001 21:06
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,
 
> I think the below discussion is about whether we need SGP concept or not.
Unless we say that they are sharing AS states, I don't see any reason to
have the SGP concept (According to me, practically it is the same to say
there is no SGP concept or to say every SG consist of one SGP).

[Howard] My current thinking is that the main reason to have multiple SGPs
in an SG is to support a distributed MTP implementation over a number of
hosts allowing a single SS7 PC presence in a network.  It is important to be
aware that network operators often like to avoid using to many PCs.  Bases
on this the question I am asking is not why we want multiple SGPs in an SG
but what we need to do to make it work well, i.e. possibly sharing AS state
information over SGPs.

> But I believe on the importance of sharing AS states between SGPs.In fact
it is for sure, that some information should be shared, on SG level or on
ASP level or on both. If as an ASP, which is functioning as standby for some
ASs, I receive some AS-DOWN notification message there are two choices. 

[Howard] I think the situation you are describing is an ASP receiving an
AS-DOWN message from an SGP.  Having looked at the spec my understanding is
that an ASP-DOWN would only be sent from an ASP to an SGP.  Can someone else
comment on this to confirm.

> If I know, that all of SGP, I am connected (and also the active ASP for
this AS, is connected to) are sharing AS state, then I am sure, the active
ASP is not reachable via any of these SGPs (otherwise I wouldn't receive
ASDOWN message). So, I don't need to check anything with the other ASP and
can send an ASPAC. 
But, if SGPs are not sharing AS state, then after receiving the ASDOWN, I
should check with active ASP to see, whether it is reachable via another SG
or not, i.e. this time we should share SG-ASP connectivity per AS basis
between ASPs.
So, I think it is unavoidable sharing states at some level. When I think
conceptually, SG is functioning like a router on IP domain, so all of the
message routing responsibility should be there, i.e. every SGP, which is
serving the same AS should share the AS states. I also agree, that for
practical purposes, this will bring more complications to SG-developers. 

[Howard] I agree that SGPs must share AS state info.  Consider the following
simple system:  An SG consisting of 2 SGPs; an AS consisting of one ASP; the
AS is the only AS within an SPMC; the SPMC has a different PC to the SG.
Now consider the following event: The SCTP association between SGP1 and ASP1
fails.  Should SGP1 send a TFP message for the SPMC to the network?  In this
situation SGP2 can still send messages to the AS and SGP1 can send messages
for the AS to SGP2 (I am not going to consider the case where inter-SGP
comms fail!).  I don't think it is appropriate for SGP1 to send a TFP
message but SGP1 can only know this if it knows the state of the AS at SGP2.

   Regards,
   Tolga

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:31 PM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Greetings, 

I'm tying to close out on this item for Issue 7.  There's been a few e-mails
with excellent input, but they do not all line up.  Further, we've had no
input from any SG vendor who is implementing this multiple SGP in an SG
architecture to help us with the issues.  I think it is worth pointing out
that unless there is more than one implementation of this and it is deemed
interoperable in a "bay-cough" this functionality would have to be dropped
out of the protocol eventually.

I liked the way Gery separated the issues out below.  Comments and proposed
conclusions below ... 

 -----Original Message----- 
From:   Verwimp Gery [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent:   Wednesday, May 02, 2001 8:17
AM To:     sigtran 
Subject:        RE: [M3UA] AS state machine sharing between SGPs 

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2

cents on this topic anyway ;-)) 

We're talking about redundancy on three different levels, I think : 

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as

well, or am I missing something here ? (Multiple routes, handled by multiple

processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is

responsible of informing layer management of it's part of the view (status
of physical connections). 

[Greg] I think that the "multiple SGP in an SG" view is really only useful
to support a "Distributed SG" implementation.  This Distributed SG would be
implemented with SGPs on two or more Hosts, probably in different locations
to get geographical redundancy.  Otherwise, the SCTP multi-homing
functionality can be used to handle this part of the redundancy,
implementing multiple processors and routes as Gery points out.  (Although
Kazuo Watanabe correctly pointed out that if we are using TCP instead of
SCTP we wouldn't have this SCTP multi-homing and would need a further
remedy) 

In other words, why would I build two local SGPs on a Host and go through
all the pain of coordinating their MTP3 and SPMC state to the SS7 network
and AS/ASP state to the IP side, when all I have to do is use SCTP's
multi-homing feature to get the same redundancy.  

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG. 

[Greg] Agreed.  For this redundancy, I have previously mentioned that the
Operator must ensure that the ASPs use SGPs or SGs that are on different
Hosts.  Gery adds that the SGPs would probably also need to be in different
locations.  So this is covered either way.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic. 

[Greg] Agreed.  This has no bearing on the SGP / SG issue. 

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two. 

Any views on this ? 

[Greg] I think it is fair to conclude that having multiple SGPs in an SG
does not in itself buy any extra functionality in terms of redundancy over
the multiple SG model.  I think we've been bending over backwards in the
protocol description to accommodate an implementation option (the
"distributed multi-site SG" described above).   So where does this
implementation option make sense? - I think the answer is for the case where
the signalling between the PSTN and IP networks is to go through a single SG
with a single SS7 Point code but with site/processor redundancy for the SG.
Paired SGs won' t do because two Point Codes would be required.   I don't
really have problem with supporting this case.     

I think we can change a few things in the spec to support this but remove
some of the confusion that it brings: 

1) Simplify the protocol description so it is described as between an SGP
and ASP only.  That is, SCTP associations are always between SGPs and ASPs.
Today the spec goes back and forth between the SGP and SG terms and adds
qualifying text in various places. 

[Howard] I'm not clear what you mean here, certainly both ASPs and SGPs
contain SCTP endpoints and associations are between SCTP endpoints e.g.
between SGPs and ASPs.  Are you suggesting messages like PC availability
should be communicated to an ASP on a per SGP basis?  

2) The SG becomes explicitly a virtual thing not unlike an AS, containing
one or more SGPs.  The spec today seems to shade back and forth on whether
an SG is a physical thing or not.  Of course if an SG is implemented using a
single SGP, then that is fine  2;^)

[Howard] I agree SGs are virtual things.  (Could you not also describe SGPs
as virtual things?  Particularly if implemented over a number of distinct
operating system tasks?)

So a paired SG architecture is now two SGPs on different hosts represented
to the SS7 network with a Point Code per host.  No coordination of MTP3,
SPMC or AS/ASP states between the SGPs is required.  A single distributed SG
is the same except that it is represented to the SS7 network with a single
SS7 Point Code for the set of SGPs.  The SGPs SHOULD support MTP3, SPMC and
AS/ASP state sharing and re-routing of traffic between the two SGPs.  How
the inter-SGP protocol accomplishes this is not described in the protocol
spec.   

[Howard] I agree a distributed SG needs to coordinate the state info you
have identified and should re-route messages between SGPs.  I don't think we
have to restrict an SG to having a single SS7 Point Code it might have a PC
per link-set.

3) The ASPs do not need to know the grouping of SGPs in virtual SGs so they
treat each SGP as an independent route out to the SS7 network.  But an ASP
MAY choose to maintain such knowledge.   The SSNM messaging from the SGPs to
the ASP is therefore processed independently.  Note that for Operators that
choose not to combine SGPs into virtual SGs (i.e., use paired physical SGs),
then nothing has really changed here.   ASPs that choose to keep knowledge
of SGP groupings into virtual SGs MAY interpret SSNM messaging from one of
the SGPs so as to apply to all the SGPs in the virtual SG but should only do
so if the SGPs coordinate their SSNM messaging to the ASPs.

[Howard] I guess if an SGP loses a direct route to a remote PC but can still
access it via a 'partner' SGP then it might send a DRST to an ASP.  In this
case the ASP MUST know that the scope of the DRST message does not extend
beyond the originating SGP.  I think this seems to work well but I would be
uncomfortable about having a choice as to whether the scope of a such a SSNM
message is for the SG or SGP.

Hope this helps, 

   Greg Sidebottom 

____________________________ 

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

-----Original Message----- 
From: Kazuo Watanabe [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: dinsdag 1 mei 2001 6:27 
To: sigtran 
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs 

Greg, 

> In the case where there are multiple SGPs in an SG, and the SGPs have 
> magically determined in their coordinated MTP3 route management logic that

> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU

> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the 

no. 
i think all concerned ASPs should receive but not all SGPs should send. 
because DUNA indicates SS7 route state not SG/SGP state. 

> answer is yes given the logic of the discussion on this thread.  So that 
> means that if the triggering event is reception of TFP(s) from the SS7 
> network, then all SGPs in an SG must coordinate their MTP3 view of the 
> availability of the SS7 destination.   Equivalent arguments can be made
for 
> virtually any SS7 link or route management event. 

yes. 
i think this is `multiple SGPs in an SG.' 

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view. 
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP. 

in that case, each SGP could have different AS state and should have the
same SS7 state. 

> Also, if one SGP has determined an SS7 destination is unavailable, but the

> destination is still available via other SGPs (a link event?), then I
assume 

according to my understanding, this is multiple SGs not multiple SGPs in an
SG. 

> that the SGP would optionally send an DRST - although we could make the
case 
> that a DUPU could be used by SGP implementations that don't redirect any 
> traffic received to the other SGPs.  I wouldn't recommend it though as
this 
> implies message loss. 
> Does this sound right? 

if you are saying about STP-like SGs configuration, it sounds right to me. 

-- 
Kazuo Watanabe 

---
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-Sent: 17 May 2001 18:00:55 GMT
From: Douglas Otis <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: [Tsvwg] Re: IPsec AH
Date: Thu, 17 May 2001 10:58:33 -0700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: c007.snv.cp.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: c007-h012.c007.snv.cp.net [209.228.33.219]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ran,

From my testing, Fletcher-16 can only detect one out 50 stuck bit errors.
If you view the checksum's job is to provide a level of protection from
hardware related errors not associated with the actual transfer of the
information which is typically checked with CRC-32, then Fletcher-16 is
perhaps the worst check you can make.  Adler-32 is many many orders of
magnitude better at that function.  Adler-32 is weaker in respect to burst
errors, but is that the check that needs to be made here?  I ague no.  The
digest chunk was defined to allow parity with iSCSI.  I'll make a new
proposal to be a means to select either Adler-32 or CRC-32 with reserve bits
that may be used to track iSCSI if they create their own level of security
that then requires this flexibility.  If you are running digests, then these
checksums are redundant.  I am not suggesting that digests will be used in
preference to simpler checksums if security is not required.  It also allows
checksums to be elevated if the processor can support it.

Doug

> At 11:41 16/05/01, Fairlie-Cuninghame, Robert wrote:
>
> >Also IPSEC AH requires Security Associations for all
> permutations of source and destination addresses in an
> association as well as a key-management and distribution mechanisms.
>
>         True in a pedantic sense, but misleading.  IN_ADDR_ANY is
> a possible valid address for any IPsec address binding, either
> source or destination.  If the same key (e.g. all 1s) were
> used when the goal were checksum but not security, then
> key management/distribution is not an issue either.
>
>         That noted, I'm not advocating using AH to provide a
> mundane checksum, just noting that the computational costs
> of *any* cryptographic MAC will be unduly high when a mundane
> checksum is all we need.
>
>         To be honest, I think a Fletcher checksum would be more
> than adequate here.  I don't think we need perfection for our
> mundane checksums.
>
> Ran

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Sent: 17 May 2001 18:13:57 GMT
From: Douglas Otis <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: [Tsvwg] Re: IPsec AH
Date: Thu, 17 May 2001 11:11:35 -0700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-SMTP-HELO: c007.snv.cp.net
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: c007-h011.c007.snv.cp.net [209.228.33.217]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sorry,

Fails to detect one of 50 stuck bit errors.

> Ran,
>
> >From my testing, Fletcher-16 can only detect one out 50 stuck bit errors.
> If you view the checksum's job is to provide a level of protection from
> hardware related errors not associated with the actual transfer of the
> information which is typically checked with CRC-32, then Fletcher-16 is
> perhaps the worst check you can make.  Adler-32 is many many orders of
> magnitude better at that function.  Adler-32 is weaker in respect to burst
> errors, but is that the check that needs to be made here?  I ague no.  The
> digest chunk was defined to allow parity with iSCSI.  I'll make a new
> proposal to be a means to select either Adler-32 or CRC-32 with
> reserve bits
> that may be used to track iSCSI if they create their own level of security
> that then requires this flexibility.  If you are running digests,
> then these
> checksums are redundant.  I am not suggesting that digests will be used in
> preference to simpler checksums if security is not required.  It
> also allows
> checksums to be elevated if the processor can support it.
>
> Doug
>
>
> > At 11:41 16/05/01, Fairlie-Cuninghame, Robert wrote:
> >
> > >Also IPSEC AH requires Security Associations for all
> > permutations of source and destination addresses in an
> > association as well as a key-management and distribution mechanisms.
> >
> >         True in a pedantic sense, but misleading.  IN_ADDR_ANY is
> > a possible valid address for any IPsec address binding, either
> > source or destination.  If the same key (e.g. all 1s) were
> > used when the goal were checksum but not security, then
> > key management/distribution is not an issue either.
> >
> >         That noted, I'm not advocating using AH to provide a
> > mundane checksum, just noting that the computational costs
> > of *any* cryptographic MAC will be unduly high when a mundane
> > checksum is all we need.
> >
> >         To be honest, I think a Fletcher checksum would be more
> > than adequate here.  I don't think we need perfection for our
> > mundane checksums.
> >
> > Ran
>
>
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: m2ua - interface identifier
Date: Thu, 17 May 2001 14:05:40 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[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>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>Dear M2ua's,</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>we have some conflict in our data model with
the term *interface identifier* and thus would like to ask 1) whether we are
the only one? and (if so) 2) whether we could, should change the m2ua draft
to use a different name. The problem is, it does not really identify an
interface (the way the mib2 for example uses the term), but could mean a
timeslot within a t1/e1 interface, or according to ITU Q.751 a Signaling
Link Termination or a Signaling Link (the draft explicitly states that
*interface* is used for *SS7 Signaling Link* so why not using signaling link
for signaling link?). The problem with *identifier* is, it gets confused
with the identifier's used to identify a&nbsp;interface within one system
(e.g. a t1 interface id in a signaling gateway) while the *interface
identifier* enumerates accross systems and means something different. (Uff,
even describing the confusion is confusing). We would like to
propose&nbsp;to use *Link Reference* instead.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV>Until Ken comes back
from vacation it would be interesting to get response on question 1)
above.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks,</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>Heinz Prantner</FONT></DIV> <DIV><FONT
face=Arial size=2>System Architect Signaling Technology</FONT></DIV>
<DIV><FONT face=Arial size=2>RadiSys, Corp.<BR>Signaling Products Design
Center<BR><A 
href="mailto:[email-masked]">[email-masked]</A></FON
T></DIV> <DIV><FONT face=Arial size=2>+1-856-642-9229
x235</FONT></DIV></FONT></DIV></FONT></DIV></FONT></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>
From: "Asveren, Tolga" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Fri, 18 May 2001 13:02:53 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: smtp.adc.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp.adc.com [155.226.10.207]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

The AS-DOWN in my message is  in fact ASP-INACTIVE. As-DOWN is even not
existing in the protocol ;)

 Sorry for that mistake,
    Tolga

-----Original Message-----
From: May, Howard [mailto:[email-masked]] Sent: Thursday, May 17, 2001
11:18 AM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hello,

I have inserted comments in more than one of the previous emails, there are
some at the bottom of Gery's

I recognise your comments about input from vendors implementing a
distributed SGP.  I think to drop this would be a great shame, I will try
and add my pennies worth.

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 15 May 2001 21:06
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,
 
> I think the below discussion is about whether we need SGP concept or not.
Unless we say that they are sharing AS states, I don't see any reason to
have the SGP concept (According to me, practically it is the same to say
there is no SGP concept or to say every SG consist of one SGP).

[Howard] My current thinking is that the main reason to have multiple SGPs
in an SG is to support a distributed MTP implementation over a number of
hosts allowing a single SS7 PC presence in a network.  It is important to be
aware that network operators often like to avoid using to many PCs.  Bases
on this the question I am asking is not why we want multiple SGPs in an SG
but what we need to do to make it work well, i.e. possibly sharing AS state
information over SGPs.

> But I believe on the importance of sharing AS states between SGPs.In fact
it is for sure, that some information should be shared, on SG level or on
ASP level or on both. If as an ASP, which is functioning as standby for some
ASs, I receive some AS-DOWN notification message there are two choices. 

[Howard] I think the situation you are describing is an ASP receiving an
AS-DOWN message from an SGP.  Having looked at the spec my understanding is
that an ASP-DOWN would only be sent from an ASP to an SGP.  Can someone else
comment on this to confirm.

> If I know, that all of SGP, I am connected (and also the active ASP for
this AS, is connected to) are sharing AS state, then I am sure, the active
ASP is not reachable via any of these SGPs (otherwise I wouldn't receive
ASDOWN message). So, I don't need to check anything with the other ASP and
can send an ASPAC. 
But, if SGPs are not sharing AS state, then after receiving the ASDOWN, I
should check with active ASP to see, whether it is reachable via another SG
or not, i.e. this time we should share SG-ASP connectivity per AS basis
between ASPs.
So, I think it is unavoidable sharing states at some level. When I think
conceptually, SG is functioning like a router on IP domain, so all of the
message routing responsibility should be there, i.e. every SGP, which is
serving the same AS should share the AS states. I also agree, that for
practical purposes, this will bring more complications to SG-developers. 

[Howard] I agree that SGPs must share AS state info.  Consider the following
simple system:  An SG consisting of 2 SGPs; an AS consisting of one ASP; the
AS is the only AS within an SPMC; the SPMC has a different PC to the SG.
Now consider the following event: The SCTP association between SGP1 and ASP1
fails.  Should SGP1 send a TFP message for the SPMC to the network?  In this
situation SGP2 can still send messages to the AS and SGP1 can send messages
for the AS to SGP2 (I am not going to consider the case where inter-SGP
comms fail!).  I don't think it is appropriate for SGP1 to send a TFP
message but SGP1 can only know this if it knows the state of the AS at SGP2.

   Regards,
   Tolga

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:31 PM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Greetings, 

I'm tying to close out on this item for Issue 7.  There's been a few e-mails
with excellent input, but they do not all line up.  Further, we've had no
input from any SG vendor who is implementing this multiple SGP in an SG
architecture to help us with the issues.  I think it is worth pointing out
that unless there is more than one implementation of this and it is deemed
interoperable in a "bay-cough" this functionality would have to be dropped
out of the protocol eventually.

I liked the way Gery separated the issues out below.  Comments and proposed
conclusions below ... 

 -----Original Message----- 
From:   Verwimp Gery [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent:   Wednesday, May 02, 2001 8:17
AM To:     sigtran 
Subject:        RE: [M3UA] AS state machine sharing between SGPs 

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2

cents on this topic anyway ;-)) 

We're talking about redundancy on three different levels, I think : 

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as

well, or am I missing something here ? (Multiple routes, handled by multiple

processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is

responsible of informing layer management of it's part of the view (status
of physical connections). 

[Greg] I think that the "multiple SGP in an SG" view is really only useful
to support a "Distributed SG" implementation.  This Distributed SG would be
implemented with SGPs on two or more Hosts, probably in different locations
to get geographical redundancy.  Otherwise, the SCTP multi-homing
functionality can be used to handle this part of the redundancy,
implementing multiple processors and routes as Gery points out.  (Although
Kazuo Watanabe correctly pointed out that if we are using TCP instead of
SCTP we wouldn't have this SCTP multi-homing and would need a further
remedy) 

In other words, why would I build two local SGPs on a Host and go through
all the pain of coordinating their MTP3 and SPMC state to the SS7 network
and AS/ASP state to the IP side, when all I have to do is use SCTP's
multi-homing feature to get the same redundancy.  

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG. 

[Greg] Agreed.  For this redundancy, I have previously mentioned that the
Operator must ensure that the ASPs use SGPs or SGs that are on different
Hosts.  Gery adds that the SGPs would probably also need to be in different
locations.  So this is covered either way.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic. 

[Greg] Agreed.  This has no bearing on the SGP / SG issue. 

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two. 

Any views on this ? 

[Greg] I think it is fair to conclude that having multiple SGPs in an SG
does not in itself buy any extra functionality in terms of redundancy over
the multiple SG model.  I think we've been bending over backwards in the
protocol description to accommodate an implementation option (the
"distributed multi-site SG" described above).   So where does this
implementation option make sense? - I think the answer is for the case where
the signalling between the PSTN and IP networks is to go through a single SG
with a single SS7 Point code but with site/processor redundancy for the SG.
Paired SGs won' t do because two Point Codes would be required.   I don't
really have problem with supporting this case.     

I think we can change a few things in the spec to support this but remove
some of the confusion that it brings: 

1) Simplify the protocol description so it is described as between an SGP
and ASP only.  That is, SCTP associations are always between SGPs and ASPs.
Today the spec goes back and forth between the SGP and SG terms and adds
qualifying text in various places. 

[Howard] I'm not clear what you mean here, certainly both ASPs and SGPs
contain SCTP endpoints and associations are between SCTP endpoints e.g.
between SGPs and ASPs.  Are you suggesting messages like PC availability
should be communicated to an ASP on a per SGP basis?  

2) The SG becomes explicitly a virtual thing not unlike an AS, containing
one or more SGPs.  The spec today seems to shade back and forth on whether
an SG is a physical thing or not.  Of course if an SG is implemented using a
single SGP, then that is fine  2;^)

[Howard] I agree SGs are virtual things.  (Could you not also describe SGPs
as virtual things?  Particularly if implemented over a number of distinct
operating system tasks?)

So a paired SG architecture is now two SGPs on different hosts represented
to the SS7 network with a Point Code per host.  No coordination of MTP3,
SPMC or AS/ASP states between the SGPs is required.  A single distributed SG
is the same except that it is represented to the SS7 network with a single
SS7 Point Code for the set of SGPs.  The SGPs SHOULD support MTP3, SPMC and
AS/ASP state sharing and re-routing of traffic between the two SGPs.  How
the inter-SGP protocol accomplishes this is not described in the protocol
spec.   

[Howard] I agree a distributed SG needs to coordinate the state info you
have identified and should re-route messages between SGPs.  I don't think we
have to restrict an SG to having a single SS7 Point Code it might have a PC
per link-set.

3) The ASPs do not need to know the grouping of SGPs in virtual SGs so they
treat each SGP as an independent route out to the SS7 network.  But an ASP
MAY choose to maintain such knowledge.   The SSNM messaging from the SGPs to
the ASP is therefore processed independently.  Note that for Operators that
choose not to combine SGPs into virtual SGs (i.e., use paired physical SGs),
then nothing has really changed here.   ASPs that choose to keep knowledge
of SGP groupings into virtual SGs MAY interpret SSNM messaging from one of
the SGPs so as to apply to all the SGPs in the virtual SG but should only do
so if the SGPs coordinate their SSNM messaging to the ASPs.

[Howard] I guess if an SGP loses a direct route to a remote PC but can still
access it via a 'partner' SGP then it might send a DRST to an ASP.  In this
case the ASP MUST know that the scope of the DRST message does not extend
beyond the originating SGP.  I think this seems to work well but I would be
uncomfortable about having a choice as to whether the scope of a such a SSNM
message is for the SG or SGP.

Hope this helps, 

   Greg Sidebottom 

____________________________ 

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

-----Original Message----- 
From: Kazuo Watanabe [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: dinsdag 1 mei 2001 6:27 
To: sigtran 
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs 

Greg, 

> In the case where there are multiple SGPs in an SG, and the SGPs have 
> magically determined in their coordinated MTP3 route management logic that

> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU

> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the 

no. 
i think all concerned ASPs should receive but not all SGPs should send. 
because DUNA indicates SS7 route state not SG/SGP state. 

> answer is yes given the logic of the discussion on this thread.  So that 
> means that if the triggering event is reception of TFP(s) from the SS7 
> network, then all SGPs in an SG must coordinate their MTP3 view of the 
> availability of the SS7 destination.   Equivalent arguments can be made
for 
> virtually any SS7 link or route management event. 

yes. 
i think this is `multiple SGPs in an SG.' 

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view. 
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP. 

in that case, each SGP could have different AS state and should have the
same SS7 state. 

> Also, if one SGP has determined an SS7 destination is unavailable, but the

> destination is still available via other SGPs (a link event?), then I
assume 

according to my understanding, this is multiple SGs not multiple SGPs in an
SG. 

> that the SGP would optionally send an DRST - although we could make the
case 
> that a DUPU could be used by SGP implementations that don't redirect any 
> traffic received to the other SGPs.  I wouldn't recommend it though as
this 
> implies message loss. 
> Does this sound right? 

if you are saying about STP-like SGs configuration, it sounds right to me. 

-- 
Kazuo Watanabe 

---
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, 21 May 2001 01:38:20 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SG - SG communication
Reply-To: [email-masked]
Mail-Followup-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.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Srivats,

M2PA supports SG to SG peer communication.  All other UAs are client-server
(so far).

--Brian

On Mon, 21 May 2001, Srivats P. wrote:

> Hi,
> 
> The Framework Architecture for Signaling Transport (RFC 2719) mentions
that
> SIGTRAN could be used for SG - SG communication. The only example of this
> usage mentioned in the RFC is when the two SGs are adapting different
layers.
> Is there any other example usage possible and useful ?
> 
> In such a case when there's SG - SG communication via SIGTRAN, will the SG
> contain both the server and the client components of each adaptation layer
?
> If yes, is anyone implementing SG in this way ?
> 
> Regards,
> Srivats P.
> 

-- 
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, 21 May 2001 11:52:0 +0500
From: "Srivats P." <[email-masked]>
Reply-To: [email-masked]
To: "sigtran" <[email-masked]>
Subject: SG - SG communication
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]>
List-Unsubscribe: <mailto:[email-masked]>

Hi,

The Framework Architecture for Signaling Transport (RFC 2719) mentions that
SIGTRAN could be used for SG - SG communication. The only example of this
usage mentioned in the RFC is when the two SGs are adapting different
layers.
Is there any other example usage possible and useful ?

In such a case when there's SG - SG communication via SIGTRAN, will the SG
contain both the server and the client components of each adaptation layer ?
If yes, is anyone implementing SG in this way ?

Regards,
Srivats P.

---
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, 21 May 2001 12:40:36 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA Question ..
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sandeep,

I can't answer the question as to why an ASP would send a subset of
Interface Identifiers in the ASP Active message.
However, I can note how this case should be handled is discussed in Section
3.3.2.5 of the draft.

Regards,

Ken

At 10:26 AM 5/9/01 -0700, Balani, Sandeep wrote:

>Hi All, 
>    I have a question about M2UA. 
>It is possible to have a subset of interface-id's in an ASP-ACTIVE messages
>from ASP to SG.
>I was wondering could anyone please tell me why an ASP might want to do
such
>a thing ? 
>
>For ex :
>                           [ SG ]
>[ASP]
>
>            IID1 -----
>                         AS-1 ----------------- ASP1
><------------------------      ASP
>            IID2 -----                          |       ASP-ACT (with IID1
>and IID3)
>                                                |
>                                                |
>            IID3 ------                         |
>                         AS-2-------------------|
>    
>            IID4 ------
>
>According to figure above if IID-1 and IID2 belong to AS-1 and IID3, IID4
>belong to AS-2. Now the ASP is sending ASP-ACT to SG with IID-1 and IID-3,
>which will mark the AS-1 and AS-2 both active for ASP1. 
>My question is why would ASP want to include a subset of IID's ? Can an ASP
>intentionally be allowed to include a subsetof IID's in ASP-ATIVE messages
?
>Or it should just be considered an accidental case ?
>
>Thanks
>Sandeep  
>
>
>
>   
>
>
>
>---
>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, 21 May 2001 13:23:35 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: FW: M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive "
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

One possible way this behavior would be seen is the case of a M3UA process
that died, then restarted (SCTP association does not fail).  The problem
with the state not being changed is that the SG and ASP would then be hung
(ASP states out of sync).  The only way to clear the hang would be to reset
the state of the ASP at the SG.  

At the M3UA editing meeting (last IETF), there was talk of taking the
following action(s) by the SG:

1)  send Error Unexpected Msg

2)  send ASP Up Ack, transition ASP state

3)  send ASP Active Ack (if ASP was Active/Standby) with Routing Contexts

I'm not sure if item 3 was agreed to, but items 1 and 2 seemed to have the
consensus of the group.

Regards,

Ken

At 09:36 AM 5/10/01 -0400, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:

>Resending ...
>
>  -----Original Message-----
>
>From:  Sidebottom, Greg [BCNR:7M01:EXCH]  
>
>Sent:   Wednesday, May 09, 2001 10:20 AM
>
>To:     [email-masked]'
>
>Subject:        M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive"
>
>Hi,
>
>I'm getting close to finishing off Iss7.  I meant to close this open issue
but forgot - thanks to Ken for reminding me.
>
>Per 4.3.3.1:
>
>     "If an ASP-Up is received and internally the remote ASP 
>
>      is in the "Active" or "Standby" state, an Error 
>
>      ("Unexpected Message) is returned and the remote ASP 
>
>      state is not changed.
>
>     If an ASP-Up is received and internally the remote ASP 
>
>      is already in the "Inactive" state, and ASP-Up Ack is 
>
>      returned and no action is taken."
>
>  
>
>Now there was discussion at the IETF meeting as to whether an ASP-Up in
this case could actually be a kind of reset by the ASP.  If so, that would
mean that the SG should change the state of the ASP to "inactive" and send
an ASP-UP Ack.  I guess the answer depends on how people think the ASPs will
behave - i.e. are there valid cases, other than a software error, where an
ASP would send an ASP-Up after going "active" or "standby"?
>
>We need to close on this issue - any support for changing this behavior?
>
>Greg Sidebottom
>
>---
>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, 21 May 2001 14:30:49 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA: Draft 7 - Assorted Queries
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Mark,

Thanks again for your excellent comments.  Pls see below.

Ken

At 01:59 PM 5/11/01 +0100, Mark Kobine wrote:
>Hi,
>
>I have a few queries with the M2UA spec.
>
>1) Section 1.4.2. The first paragraph reads as though there might be
>something missing immediately following the paragraph. More specifically 
>the last sentence reads "These primitives are shown below:" but there are 
>none listed.
>
>Or is this referring to the primitives in section 1.4.3?

removed sentence.

>2) Section 3.3.3.2. When an AS sends out a AS_State_Change Notify message
>does it send it to all ASPs (except the ones that are Down) or just the 
>active one(s)?

all ASPs in Inactive/Active state.

>3) Section 4.2.1 first para. Does the "(Error)" in the first sentence
>refer to the Error Message? If so it makes little sense in the context.

Re-written:

"On receiving primitives from the local Layer Management, the M2UA layer
will take the requested action and provide an appropriate response primitive
to Layer Management."

>Cheers,
>Mark
>
>
>
>---
>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, 21 May 2001 18:40:30 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or "Inactive "
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Barry,

I was not referring to the case of SCTP Restart.  I was referring to a M3UA
"restart" (i.e. the M3UA process dies but the SCTP association does not).

I agree that the SCTP Restart case needs to be handled correctly and, if it
is not, can be considered an implementation error.

But, it is always good to provide a means for two sides to get re-sync in
terms of state.  The current text does not provide a means to do so.

Regards,

Ken

At 05:16 PM 5/21/01 -0400, Barry Nagelberg wrote:
>At the M3UA bakeoff, there were some "hung" pairs, as described by Ken,
>after an SCTP restart occurred, but only because some of the M3UA
>implementations were not handling the SCTP_RESTART notification correctly.
>
>If the SCTP_RESTART notification is handled correctly, i.e. resetting the
>peer's state to DOWN, then no "hang" should occur, and no special state
>transition must occur when an ASPUP msg is received for a peer which is
>thought to be ACTIVE. 
>
>Barry Nagelberg
>Staff Software Engineer
>RadiSys, Corp.
>Signaling Products Design Center
>[email-masked]
>+1-856-642-9229 x237
>
>
> > -----Original Message-----
> > From: Ken Morneault [mailto:[email-masked]]
> > Sent: Monday, May 21, 2001 1:24 PM
> > To: sigtran
> > Subject: Re: FW: M3UA Iss7 - ASP-Up received when ASP is "active" or
> > "Inactive "
> > 
> > 
> > 
> > 
> > Greg,
> > 
> > One possible way this behavior would be seen is the case of a 
> > M3UA process
> > that died, then restarted (SCTP association does not fail).  
> > The problem with the 
> > state not being changed is that the SG and ASP would then be 
> > hung (ASP states 
> > out of sync).  The only way to clear the hang would be to 
> > reset the state of the 
> > ASP at the SG.  
> > 
> > At the M3UA editing meeting (last IETF), there was talk of 
> > taking the following action(s)
> > by the SG:
> > 
> > 1)  send Error Unexpected Msg
> > 
> > 2)  send ASP Up Ack, transition ASP state
> > 
> > 3)  send ASP Active Ack (if ASP was Active/Standby) with 
> > Routing Contexts
> > 
> > I'm not sure if item 3 was agreed to, but items 1 and 2 
> > seemed to have the
> > consensus of the group.
> > 
> > Regards,
> > 
> > Ken
> > 
> > 
> > 
> > At 09:36 AM 5/10/01 -0400, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:
> > 
> > >Resending ...
> > >
> > >  -----Original Message-----
> > >
> > >From:  Sidebottom, Greg [BCNR:7M01:EXCH]  
> > >
> > >Sent:   Wednesday, May 09, 2001 10:20 AM
> > >
> > >To:     [email-masked]'
> > >
> > >Subject:        M3UA Iss7 - ASP-Up received when ASP is 
> > "active" or "Inactive"
> > >
> > >Hi,
> > >
> > >I'm getting close to finishing off Iss7.  I meant to close 
> > this open issue but forgot - thanks to Ken for reminding me.
> > >
> > >Per 4.3.3.1:
> > >
> > >     "If an ASP-Up is received and internally the remote ASP 
> > >
> > >      is in the "Active" or "Standby" state, an Error 
> > >
> > >      ("Unexpected Message) is returned and the remote ASP 
> > >
> > >      state is not changed.
> > >
> > >     If an ASP-Up is received and internally the remote ASP 
> > >
> > >      is already in the "Inactive" state, and ASP-Up Ack is 
> > >
> > >      returned and no action is taken."
> > >
> > >  
> > >
> > >Now there was discussion at the IETF meeting as to whether 
> > an ASP-Up in this case could actually be a kind of reset by 
> > the ASP.  If so, that would mean that the SG should change 
> > the state of the ASP to "inactive" and send an ASP-UP Ack.  I 
> > guess the answer depends on how people think the ASPs will 
> > behave - i.e. are there valid cases, other than a software 
> > error, where an ASP would send an ASP-Up after going "active" 
> > or "standby"?
> > >
> > >We need to close on this issue - any support for changing 
> > this behavior?
> > >
> > >Greg Sidebottom
> > >
> > >---
> > >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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 21 May 2001 18:43:13 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA Notify message
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hanping,

I agree that "Insufficient ASP Resources Active in AS" is not required for
M2UA.  I will remove it.

Regards,

Ken

At 03:03 PM 5/21/01 -0700, Long, Hanping wrote:
>Hi all:
>
>Since only over-ride mode is supported in M2UA, I think the Notify message
>with staus information (Insufficient ASP resources active in AS) is not
>needed any more. In the case when the original active ASP sends ASP
Inactive
>message to SG, the AS state in the SG will change from AS-Active to
>AS-Pending, and the Notify message (AS_State_Change) will be sent to all
>inactive ASP. In this scenario, the additional Notify message (Status Type:
>Other; Status Info.: Insufficient ASP active in AS) is not informative,
thus
>not needed  because ASP could get this information from the Notify message
>indicating the AS state change.
>
>I would appreciate if somebody could identify and resolve this issue.
>
>thanks,
>hanping
>
>
>
>---
>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]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive "
X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3
Date: Tue, 22 May 2001 10:06:08 +0900
From: Kazuo Watanabe <[email-masked]>
X-SMTP-HELO: TYO202.gate.nec.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: TYO202.gate.nec.co.jp [202.247.6.41]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

From: Ken Morneault <[email-masked]> Subject: RE: M3UA Iss7 - ASP-Up
received when ASP is "active" or "Inactive " Date: Mon, 21 May 2001 18:40:30
-0400

> I was not referring to the case of SCTP Restart.  I was referring
> to a M3UA "restart" (i.e. the M3UA process dies but the
> SCTP association does not).

i'm not sure such behaviour is correct.

> I agree that the SCTP Restart case needs to be handled correctly
> and, if it is not, can be considered an implementation error.
> 
> But, it is always good to provide a means for two sides to get
> re-sync in terms of state.  The current text does not provide 
> a means to do so.

you can do that by aborting the association?
but anyway, i agree re-sync by ASP-UP.

> > > At the M3UA editing meeting (last IETF), there was talk of 
> > > taking the following action(s)
> > > by the SG:
> > > 
> > > 1)  send Error Unexpected Msg
> > > 
> > > 2)  send ASP Up Ack, transition ASP state
> > > 
> > > 3)  send ASP Active Ack (if ASP was Active/Standby) with 
> > > Routing Contexts
> > > 
> > > I'm not sure if item 3 was agreed to, but items 1 and 2 
> > > seemed to have the
> > > consensus of the group.

i don't think we had the consensus on item 3.

-- 
Kazuo Watanabe

---
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, 21 May 2001 23:31:52 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive "
Cc: [email-masked]
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Kazuo,

Pls see comments below.

Regards,

Ken

At 10:06 AM 5/22/01 +0900, Kazuo Watanabe wrote:
>From: Ken Morneault <[email-masked]>
>Subject: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or "Inactive
"
>Date: Mon, 21 May 2001 18:40:30 -0400
>
> > I was not referring to the case of SCTP Restart.  I was referring
> > to a M3UA "restart" (i.e. the M3UA process dies but the
> > SCTP association does not).
>
>i'm not sure such behaviour is correct.
>
> > I agree that the SCTP Restart case needs to be handled correctly
> > and, if it is not, can be considered an implementation error.
> > 
> > But, it is always good to provide a means for two sides to get
> > re-sync in terms of state.  The current text does not provide 
> > a means to do so.
>
>you can do that by aborting the association?

I came to the same realization earlier this evening.

>but anyway, i agree re-sync by ASP-UP.

what do you mean by this sentence.

> > > > At the M3UA editing meeting (last IETF), there was talk of 
> > > > taking the following action(s)
> > > > by the SG:
> > > > 
> > > > 1)  send Error Unexpected Msg
> > > > 
> > > > 2)  send ASP Up Ack, transition ASP state
> > > > 
> > > > 3)  send ASP Active Ack (if ASP was Active/Standby) with 
> > > > Routing Contexts
> > > > 
> > > > I'm not sure if item 3 was agreed to, but items 1 and 2 
> > > > seemed to have the
> > > > consensus of the group.
>
>i don't think we had the consensus on item 3.
>
>-- 
>Kazuo Watanabe 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: M2UA bakeoff.
Date: Tue, 22 May 2001 02:19:43 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: exchange1.nuera.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [204.216.240.98]
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 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>M2UA bakeoff.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hi,</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">Are there any plans to have an M2UA bakeoff (or
any of the other adaptation layers such as M2PA) ? To me, it would seem
logical</FONT> <FONT SIZE=2 FACE="Arial">to co-locate</FONT> <FONT SIZE=2
FACE="Arial">such an event</FONT><FONT SIZE=2 FACE="Arial"> with</FONT><FONT
SIZE=2 FACE="Arial"> the next M3UA bakeoff. What are peoples feelings on
this?</FONT><FONT SIZE=2 FACE="Arial"> Is there enough interest</FONT><FONT
SIZE=2 FACE="Arial"> in any case</FONT><FONT SIZE=2
FACE="Arial">?</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Robert.</FONT> </P>

<P><A NAME="_MailData"><FONT SIZE=2 FACE="Arial">-----Original
Message-----</FONT></A> <BR><B><FONT SIZE=2 FACE="Arial">From:&nbsp;&nbsp;
Ken Morneault [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT></B>
<BR><B><FONT SIZE=2 FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=2
FACE="Arial">Monday, May 21, 2001 11:43 PM</FONT> <BR><B><FONT SIZE=2
FACE="Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=2
FACE="Arial">sigtran</FONT> <BR><B><FONT SIZE=2
FACE="Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B>
<FONT SIZE=2 FACE="Arial">Re: M2UA Notify message</FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2 FACE="Arial">Hanping,</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">I agree that &quot;Insufficient ASP Resources
Active in AS&quot; is not</FONT> <BR><FONT SIZE=2 FACE="Arial">required for
M2UA.&nbsp; I will remove it.</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">Regards,</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">Ken</FONT> </P>

<P><FONT SIZE=2 FACE="Arial">At 03:03 PM 5/21/01 -0700, Long, Hanping
wrote:</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;Hi all:</FONT> <BR><FONT
SIZE=2 FACE="Arial">&gt;</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;Since only
over-ride mode is supported in M2UA, I think the Notify message</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;with staus information (Insufficient ASP
resources active in AS) is not</FONT> <BR><FONT SIZE=2
FACE="Arial">&gt;needed any more. In the case when the original active ASP
sends ASP Inactive</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;message to SG,
the AS state in the SG will change from AS-Active to</FONT> <BR><FONT SIZE=2
FACE="Arial">&gt;AS-Pending, and the Notify message (AS_State_Change) will
be sent to all</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;inactive ASP. In
this scenario, the additional Notify message (Status Type:</FONT> <BR><FONT
SIZE=2 FACE="Arial">&gt;Other; Status Info.: Insufficient ASP active in AS)
is not informative, thus</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;not
needed&nbsp; because ASP could get this information from the Notify
message</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;indicating the AS state
change.</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;</FONT> <BR><FONT SIZE=2
FACE="Arial">&gt;I would appreciate if somebody could identify and resolve
this issue.</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;</FONT> <BR><FONT
SIZE=2 FACE="Arial">&gt;thanks,</FONT> <BR><FONT SIZE=2
FACE="Arial">&gt;hanping</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;</FONT> <BR><FONT SIZE=2
FACE="Arial">&gt;</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;---</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;You are currently subscribed to sigtran
as: [email-masked]</FONT> <BR><FONT SIZE=2 FACE="Arial">&gt;To
unsubscribe send a blank email to
[email-masked] </FONT> </P>
<BR>
<BR>

<P><FONT SIZE=2 FACE="Arial">---</FONT> <BR><FONT SIZE=2 FACE="Arial">You
are currently subscribed to sigtran as: [email-masked]</FONT> <BR><FONT
SIZE=2 FACE="Arial">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>
From: [email-masked]
To: "sigtran" <[email-masked]>
Subject: Other bakeoffs was: M2UA bakeoff.
Date: Tue, 22 May 2001 12:29:43 +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,

> Are there any plans to have an M2UA bakeoff 
> (or any of the other adaptation layers such as M2PA) ? 
> To me, it would seem logical to co-locate such an 
> event with the next M3UA bakeoff. What are peoples 
> feelings on this? Is there enough interest in any case?

And is there interested in an SUA bakeoff?

John

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "May, Howard" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Tue, 22 May 2001 10:44:52 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: odin.isw.intel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: swfdns01.isw.intel.com [192.55.37.143]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

If the situation you are describing is an ASP receiving an ASP-INACTIVE
message from an SGP then my previous comment still stands.  That is my
understanding is that an ASP-INACTIVE would only be sent from an ASP to an
SGP.  Can someone else
comment on this to confirm.

Cheers,

Howard

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 18 May 2001 19:03
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,

The AS-DOWN in my message is  in fact ASP-INACTIVE. As-DOWN is even not
existing in the protocol ;)

 Sorry for that mistake,
    Tolga

-----Original Message-----
From: May, Howard [mailto:[email-masked]] Sent: Thursday, May 17, 2001
11:18 AM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hello,

I have inserted comments in more than one of the previous emails, there are
some at the bottom of Gery's

I recognise your comments about input from vendors implementing a
distributed SGP.  I think to drop this would be a great shame, I will try
and add my pennies worth.

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 15 May 2001 21:06
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,
 
> I think the below discussion is about whether we need SGP concept or not.
Unless we say that they are sharing AS states, I don't see any reason to
have the SGP concept (According to me, practically it is the same to say
there is no SGP concept or to say every SG consist of one SGP).

[Howard] My current thinking is that the main reason to have multiple SGPs
in an SG is to support a distributed MTP implementation over a number of
hosts allowing a single SS7 PC presence in a network.  It is important to be
aware that network operators often like to avoid using to many PCs.  Bases
on this the question I am asking is not why we want multiple SGPs in an SG
but what we need to do to make it work well, i.e. possibly sharing AS state
information over SGPs.

> But I believe on the importance of sharing AS states between SGPs.In fact
it is for sure, that some information should be shared, on SG level or on
ASP level or on both. If as an ASP, which is functioning as standby for some
ASs, I receive some AS-DOWN notification message there are two choices. 

[Howard] I think the situation you are describing is an ASP receiving an
AS-DOWN message from an SGP.  Having looked at the spec my understanding is
that an ASP-DOWN would only be sent from an ASP to an SGP.  Can someone else
comment on this to confirm.

> If I know, that all of SGP, I am connected (and also the active ASP for
this AS, is connected to) are sharing AS state, then I am sure, the active
ASP is not reachable via any of these SGPs (otherwise I wouldn't receive
ASDOWN message). So, I don't need to check anything with the other ASP and
can send an ASPAC. 
But, if SGPs are not sharing AS state, then after receiving the ASDOWN, I
should check with active ASP to see, whether it is reachable via another SG
or not, i.e. this time we should share SG-ASP connectivity per AS basis
between ASPs.
So, I think it is unavoidable sharing states at some level. When I think
conceptually, SG is functioning like a router on IP domain, so all of the
message routing responsibility should be there, i.e. every SGP, which is
serving the same AS should share the AS states. I also agree, that for
practical purposes, this will bring more complications to SG-developers. 

[Howard] I agree that SGPs must share AS state info.  Consider the following
simple system:  An SG consisting of 2 SGPs; an AS consisting of one ASP; the
AS is the only AS within an SPMC; the SPMC has a different PC to the SG.
Now consider the following event: The SCTP association between SGP1 and ASP1
fails.  Should SGP1 send a TFP message for the SPMC to the network?  In this
situation SGP2 can still send messages to the AS and SGP1 can send messages
for the AS to SGP2 (I am not going to consider the case where inter-SGP
comms fail!).  I don't think it is appropriate for SGP1 to send a TFP
message but SGP1 can only know this if it knows the state of the AS at SGP2.

   Regards,
   Tolga

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:31 PM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Greetings, 

I'm tying to close out on this item for Issue 7.  There's been a few e-mails
with excellent input, but they do not all line up.  Further, we've had no
input from any SG vendor who is implementing this multiple SGP in an SG
architecture to help us with the issues.  I think it is worth pointing out
that unless there is more than one implementation of this and it is deemed
interoperable in a "bay-cough" this functionality would have to be dropped
out of the protocol eventually.

I liked the way Gery separated the issues out below.  Comments and proposed
conclusions below ... 

 -----Original Message----- 
From:   Verwimp Gery [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent:   Wednesday, May 02, 2001 8:17
AM To:     sigtran 
Subject:        RE: [M3UA] AS state machine sharing between SGPs 

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2

cents on this topic anyway ;-)) 

We're talking about redundancy on three different levels, I think : 

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as

well, or am I missing something here ? (Multiple routes, handled by multiple

processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is

responsible of informing layer management of it's part of the view (status
of physical connections). 

[Greg] I think that the "multiple SGP in an SG" view is really only useful
to support a "Distributed SG" implementation.  This Distributed SG would be
implemented with SGPs on two or more Hosts, probably in different locations
to get geographical redundancy.  Otherwise, the SCTP multi-homing
functionality can be used to handle this part of the redundancy,
implementing multiple processors and routes as Gery points out.  (Although
Kazuo Watanabe correctly pointed out that if we are using TCP instead of
SCTP we wouldn't have this SCTP multi-homing and would need a further
remedy) 

In other words, why would I build two local SGPs on a Host and go through
all the pain of coordinating their MTP3 and SPMC state to the SS7 network
and AS/ASP state to the IP side, when all I have to do is use SCTP's
multi-homing feature to get the same redundancy.  

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG. 

[Greg] Agreed.  For this redundancy, I have previously mentioned that the
Operator must ensure that the ASPs use SGPs or SGs that are on different
Hosts.  Gery adds that the SGPs would probably also need to be in different
locations.  So this is covered either way.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic. 

[Greg] Agreed.  This has no bearing on the SGP / SG issue. 

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two. 

Any views on this ? 

[Greg] I think it is fair to conclude that having multiple SGPs in an SG
does not in itself buy any extra functionality in terms of redundancy over
the multiple SG model.  I think we've been bending over backwards in the
protocol description to accommodate an implementation option (the
"distributed multi-site SG" described above).   So where does this
implementation option make sense? - I think the answer is for the case where
the signalling between the PSTN and IP networks is to go through a single SG
with a single SS7 Point code but with site/processor redundancy for the SG.
Paired SGs won' t do because two Point Codes would be required.   I don't
really have problem with supporting this case.     

I think we can change a few things in the spec to support this but remove
some of the confusion that it brings: 

1) Simplify the protocol description so it is described as between an SGP
and ASP only.  That is, SCTP associations are always between SGPs and ASPs.
Today the spec goes back and forth between the SGP and SG terms and adds
qualifying text in various places. 

[Howard] I'm not clear what you mean here, certainly both ASPs and SGPs
contain SCTP endpoints and associations are between SCTP endpoints e.g.
between SGPs and ASPs.  Are you suggesting messages like PC availability
should be communicated to an ASP on a per SGP basis?  

2) The SG becomes explicitly a virtual thing not unlike an AS, containing
one or more SGPs.  The spec today seems to shade back and forth on whether
an SG is a physical thing or not.  Of course if an SG is implemented using a
single SGP, then that is fine  2;^)

[Howard] I agree SGs are virtual things.  (Could you not also describe SGPs
as virtual things?  Particularly if implemented over a number of distinct
operating system tasks?)

So a paired SG architecture is now two SGPs on different hosts represented
to the SS7 network with a Point Code per host.  No coordination of MTP3,
SPMC or AS/ASP states between the SGPs is required.  A single distributed SG
is the same except that it is represented to the SS7 network with a single
SS7 Point Code for the set of SGPs.  The SGPs SHOULD support MTP3, SPMC and
AS/ASP state sharing and re-routing of traffic between the two SGPs.  How
the inter-SGP protocol accomplishes this is not described in the protocol
spec.   

[Howard] I agree a distributed SG needs to coordinate the state info you
have identified and should re-route messages between SGPs.  I don't think we
have to restrict an SG to having a single SS7 Point Code it might have a PC
per link-set.

3) The ASPs do not need to know the grouping of SGPs in virtual SGs so they
treat each SGP as an independent route out to the SS7 network.  But an ASP
MAY choose to maintain such knowledge.   The SSNM messaging from the SGPs to
the ASP is therefore processed independently.  Note that for Operators that
choose not to combine SGPs into virtual SGs (i.e., use paired physical SGs),
then nothing has really changed here.   ASPs that choose to keep knowledge
of SGP groupings into virtual SGs MAY interpret SSNM messaging from one of
the SGPs so as to apply to all the SGPs in the virtual SG but should only do
so if the SGPs coordinate their SSNM messaging to the ASPs.

[Howard] I guess if an SGP loses a direct route to a remote PC but can still
access it via a 'partner' SGP then it might send a DRST to an ASP.  In this
case the ASP MUST know that the scope of the DRST message does not extend
beyond the originating SGP.  I think this seems to work well but I would be
uncomfortable about having a choice as to whether the scope of a such a SSNM
message is for the SG or SGP.

Hope this helps, 

   Greg Sidebottom 

____________________________ 

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

-----Original Message----- 
From: Kazuo Watanabe [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: dinsdag 1 mei 2001 6:27 
To: sigtran 
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs 

Greg, 

> In the case where there are multiple SGPs in an SG, and the SGPs have 
> magically determined in their coordinated MTP3 route management logic that

> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU

> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the 

no. 
i think all concerned ASPs should receive but not all SGPs should send. 
because DUNA indicates SS7 route state not SG/SGP state. 

> answer is yes given the logic of the discussion on this thread.  So that 
> means that if the triggering event is reception of TFP(s) from the SS7 
> network, then all SGPs in an SG must coordinate their MTP3 view of the 
> availability of the SS7 destination.   Equivalent arguments can be made
for 
> virtually any SS7 link or route management event. 

yes. 
i think this is `multiple SGPs in an SG.' 

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view. 
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP. 

in that case, each SGP could have different AS state and should have the
same SS7 state. 

> Also, if one SGP has determined an SS7 destination is unavailable, but the

> destination is still available via other SGPs (a link event?), then I
assume 

according to my understanding, this is multiple SGs not multiple SGPs in an
SG. 

> that the SGP would optionally send an DRST - although we could make the
case 
> that a DUPU could be used by SGP implementations that don't redirect any 
> traffic received to the other SGPs.  I wouldn't recommend it though as
this 
> implies message loss. 
> Does this sound right? 

if you are saying about STP-like SGs configuration, it sounds right to me. 

-- 
Kazuo Watanabe 

---
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]
From: John Townsend <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2UA bakeoff.
Date: Tue, 22 May 2001 11:26:02 +0100
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-SMTP-HELO: mail.tduk.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [195.13.87.121]
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><TITLE>M2UA bakeoff.</TITLE> <META http-equiv=Content-Type
content="text/html; charset=iso-8859-1"> <META content="MSHTML
5.50.4611.1300" name=GENERATOR></HEAD> <BODY>
<DIV><SPAN class=874332310-22052001><FONT face=Arial color=#0000ff size=2>We
would certainly wish to attend an M2UA Bakeoff ASAP.</FONT></SPAN></DIV>
<DIV><SPAN class=874332310-22052001><FONT face=Arial color=#0000ff
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=874332310-22052001><FONT face=Arial color=#0000ff
size=2>John Townsend.</FONT></SPAN></DIV>
<DIV><SPAN class=874332310-22052001><FONT face=Arial color=#0000ff
size=2>Telesoft Technologies Ltd.</FONT></SPAN></DIV> <BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Fairlie-Cuninghame,
Robert 
  [mailto:[email-masked]]<BR><B>Sent:</B> 22 May 2001
10:20<BR><B>To:</B> 
  sigtran<BR><B>Subject:</B> M2UA bakeoff.<BR><BR></FONT></DIV>
  <P><FONT face=Arial size=2>Hi,</FONT> </P>
  <P><FONT face=Arial size=2>Are there any plans to have an M2UA bakeoff (or
any 
  of the other adaptation layers such as M2PA) ? To me, it would seem 
  logical</FONT> <FONT face=Arial size=2>to co-locate</FONT> <FONT
face=Arial 
  size=2>such an event</FONT><FONT face=Arial size=2> with</FONT><FONT 
  face=Arial size=2> the next M3UA bakeoff. What are peoples feelings on 
  this?</FONT><FONT face=Arial size=2> Is there enough interest</FONT><FONT 
  face=Arial size=2> in any case</FONT><FONT face=Arial size=2>?</FONT></P>
  <P><FONT face=Arial size=2>Robert.</FONT> </P>
  <P><A name=_MailData><FONT face=Arial size=2>-----Original 
  Message-----</FONT></A> <BR><B><FONT face=Arial size=2>From:&nbsp;&nbsp;
Ken 
  Morneault [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT></B>

  <BR><B><FONT face=Arial size=2>Sent:&nbsp;&nbsp;</FONT></B> <FONT
face=Arial 
  size=2>Monday, May 21, 2001 11:43 PM</FONT> <BR><B><FONT face=Arial 
  size=2>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial 
  size=2>sigtran</FONT> <BR><B><FONT face=Arial 
  size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT

  face=Arial size=2>Re: M2UA Notify message</FONT> </P><BR><BR>
  <P><FONT face=Arial size=2>Hanping,</FONT> </P>
  <P><FONT face=Arial size=2>I agree that "Insufficient ASP Resources Active
in 
  AS" is not</FONT> <BR><FONT face=Arial size=2>required for M2UA.&nbsp; I
will 
  remove it.</FONT> </P>
  <P><FONT face=Arial size=2>Regards,</FONT> </P>
  <P><FONT face=Arial size=2>Ken</FONT> </P>
  <P><FONT face=Arial size=2>At 03:03 PM 5/21/01 -0700, Long, Hanping 
  wrote:</FONT> <BR><FONT face=Arial size=2>&gt;Hi all:</FONT> <BR><FONT 
  face=Arial size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt;Since only 
  over-ride mode is supported in M2UA, I think the Notify message</FONT> 
  <BR><FONT face=Arial size=2>&gt;with staus information (Insufficient ASP 
  resources active in AS) is not</FONT> <BR><FONT face=Arial
size=2>&gt;needed 
  any more. In the case when the original active ASP sends ASP
Inactive</FONT> 
  <BR><FONT face=Arial size=2>&gt;message to SG, the AS state in the SG will

  change from AS-Active to</FONT> <BR><FONT face=Arial
size=2>&gt;AS-Pending, 
  and the Notify message (AS_State_Change) will be sent to all</FONT>
<BR><FONT 
  face=Arial size=2>&gt;inactive ASP. In this scenario, the additional
Notify 
  message (Status Type:</FONT> <BR><FONT face=Arial size=2>&gt;Other; Status

  Info.: Insufficient ASP active in AS) is not informative, thus</FONT> 
  <BR><FONT face=Arial size=2>&gt;not needed&nbsp; because ASP could get
this 
  information from the Notify message</FONT> <BR><FONT face=Arial 
  size=2>&gt;indicating the AS state change.</FONT> <BR><FONT face=Arial 
  size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt;I would appreciate if 
  somebody could identify and resolve this issue.</FONT> <BR><FONT
face=Arial 
  size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt;thanks,</FONT>
<BR><FONT 
  face=Arial size=2>&gt;hanping</FONT> <BR><FONT face=Arial
size=2>&gt;</FONT> 
  <BR><FONT face=Arial size=2>&gt;</FONT> <BR><FONT face=Arial 
  size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt;---</FONT> <BR><FONT 
  face=Arial size=2>&gt;You are currently subscribed to sigtran as: 
  [email-masked]</FONT> <BR><FONT face=Arial size=2>&gt;To unsubscribe
send 
  a blank email to [email-masked] 
  </FONT></P><BR><BR>
  <P><FONT face=Arial size=2>---</FONT> <BR><FONT face=Arial size=2>You are 
  currently subscribed to sigtran as: [email-masked]</FONT> <BR><FONT 
  face=Arial 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] </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: Coene Lode <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
Date: Tue, 22 May 2001 12:50:17 +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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: dinsdag 22 mei 2001 11:30
> To: sigtran
> Subject: Other bakeoffs was: M2UA bakeoff.
> 
> 
> Hi,
> 
> > Are there any plans to have an M2UA bakeoff 
> > (or any of the other adaptation layers such as M2PA) ? 
> > To me, it would seem logical to co-locate such an 
> > event with the next M3UA bakeoff. What are peoples 
> > feelings on this? Is there enough interest in any case?
> 
> And is there interested in an SUA bakeoff?
>
Yes, certainly.

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium Tel +32-14-25-2081   /  Fax +32-14-25-3212
E-mail:   [email-masked]

> 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: "Asveren, Tolga" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: [M3UA] AS state machine sharing between SGPs
Date: Tue, 22 May 2001 07:01:14 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: smtp.adc.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp.adc.com [155.226.10.207]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi,

You are right, when I am writing the comments I should look to the name of
the specific message from now on,
really sorry for this. The situation I meant was, when SG informs ASP that
the SG wants this ASP to be active for an AS. And then -this time I have
looked to the spec :) - it sends NTFY to indicate this. I think in this
case, AS state sharing makes sense. What are the opinions about this
scenario? And also is there a conclusion now for SGP concept and sharing of
AS states between them?

    Tolga

-----Original Message-----
From: May, Howard [mailto:[email-masked]] Sent: Tuesday, May 22, 2001
5:45 AM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,

If the situation you are describing is an ASP receiving an ASP-INACTIVE
message from an SGP then my previous comment still stands.  That is my
understanding is that an ASP-INACTIVE would only be sent from an ASP to an
SGP.  Can someone else
comment on this to confirm.

Cheers,

Howard

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 18 May 2001 19:03
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,

The AS-DOWN in my message is  in fact ASP-INACTIVE. As-DOWN is even not
existing in the protocol ;)

 Sorry for that mistake,
    Tolga

-----Original Message-----
From: May, Howard [mailto:[email-masked]] Sent: Thursday, May 17, 2001
11:18 AM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hello,

I have inserted comments in more than one of the previous emails, there are
some at the bottom of Gery's

I recognise your comments about input from vendors implementing a
distributed SGP.  I think to drop this would be a great shame, I will try
and add my pennies worth.

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] Sent: 15 May 2001 21:06
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Hi,
 
> I think the below discussion is about whether we need SGP concept or not.
Unless we say that they are sharing AS states, I don't see any reason to
have the SGP concept (According to me, practically it is the same to say
there is no SGP concept or to say every SG consist of one SGP).

[Howard] My current thinking is that the main reason to have multiple SGPs
in an SG is to support a distributed MTP implementation over a number of
hosts allowing a single SS7 PC presence in a network.  It is important to be
aware that network operators often like to avoid using to many PCs.  Bases
on this the question I am asking is not why we want multiple SGPs in an SG
but what we need to do to make it work well, i.e. possibly sharing AS state
information over SGPs.

> But I believe on the importance of sharing AS states between SGPs.In fact
it is for sure, that some information should be shared, on SG level or on
ASP level or on both. If as an ASP, which is functioning as standby for some
ASs, I receive some AS-DOWN notification message there are two choices. 

[Howard] I think the situation you are describing is an ASP receiving an
AS-DOWN message from an SGP.  Having looked at the spec my understanding is
that an ASP-DOWN would only be sent from an ASP to an SGP.  Can someone else
comment on this to confirm.

> If I know, that all of SGP, I am connected (and also the active ASP for
this AS, is connected to) are sharing AS state, then I am sure, the active
ASP is not reachable via any of these SGPs (otherwise I wouldn't receive
ASDOWN message). So, I don't need to check anything with the other ASP and
can send an ASPAC. 
But, if SGPs are not sharing AS state, then after receiving the ASDOWN, I
should check with active ASP to see, whether it is reachable via another SG
or not, i.e. this time we should share SG-ASP connectivity per AS basis
between ASPs.
So, I think it is unavoidable sharing states at some level. When I think
conceptually, SG is functioning like a router on IP domain, so all of the
message routing responsibility should be there, i.e. every SGP, which is
serving the same AS should share the AS states. I also agree, that for
practical purposes, this will bring more complications to SG-developers. 

[Howard] I agree that SGPs must share AS state info.  Consider the following
simple system:  An SG consisting of 2 SGPs; an AS consisting of one ASP; the
AS is the only AS within an SPMC; the SPMC has a different PC to the SG.
Now consider the following event: The SCTP association between SGP1 and ASP1
fails.  Should SGP1 send a TFP message for the SPMC to the network?  In this
situation SGP2 can still send messages to the AS and SGP1 can send messages
for the AS to SGP2 (I am not going to consider the case where inter-SGP
comms fail!).  I don't think it is appropriate for SGP1 to send a TFP
message but SGP1 can only know this if it knows the state of the AS at SGP2.

   Regards,
   Tolga

-----Original Message-----
From: Sidebottom, Greg [BCNR:7M01:EXCH] [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:31 PM
To: sigtran
Subject: RE: [M3UA] AS state machine sharing between SGPs

Greetings, 

I'm tying to close out on this item for Issue 7.  There's been a few e-mails
with excellent input, but they do not all line up.  Further, we've had no
input from any SG vendor who is implementing this multiple SGP in an SG
architecture to help us with the issues.  I think it is worth pointing out
that unless there is more than one implementation of this and it is deemed
interoperable in a "bay-cough" this functionality would have to be dropped
out of the protocol eventually.

I liked the way Gery separated the issues out below.  Comments and proposed
conclusions below ... 

 -----Original Message----- 
From:   Verwimp Gery [ mailto:[email-masked]
<mailto:[email-masked]> ] Sent:   Wednesday, May 02, 2001 8:17
AM To:     sigtran 
Subject:        RE: [M3UA] AS state machine sharing between SGPs 

Maybe I'll add to everyone's confusion (or brain status), but I'll give my 2

cents on this topic anyway ;-)) 

We're talking about redundancy on three different levels, I think : 

- network redundancy : redundancy of routes between SG and ASP, that's why
we have the SCTP multihoming feature, no ? So whether the physical
interfaces are all connected to a single SGP or more SGP's is transparent
for an ASP. And this is the main reason for having multiple SGPs at an SG as

well, or am I missing something here ? (Multiple routes, handled by multiple

processors on the SG-host to avoid single points of failure). A single SG
only has a single management view of it's SCTP associations, and each SGP is

responsible of informing layer management of it's part of the view (status
of physical connections). 

[Greg] I think that the "multiple SGP in an SG" view is really only useful
to support a "Distributed SG" implementation.  This Distributed SG would be
implemented with SGPs on two or more Hosts, probably in different locations
to get geographical redundancy.  Otherwise, the SCTP multi-homing
functionality can be used to handle this part of the redundancy,
implementing multiple processors and routes as Gery points out.  (Although
Kazuo Watanabe correctly pointed out that if we are using TCP instead of
SCTP we wouldn't have this SCTP multi-homing and would need a further
remedy) 

In other words, why would I build two local SGPs on a Host and go through
all the pain of coordinating their MTP3 and SPMC state to the SS7 network
and AS/ASP state to the IP side, when all I have to do is use SCTP's
multi-homing feature to get the same redundancy.  

- platform/host redundancy : that's why we may want to connect an ASP to 2
SGs (2 SCTP associations) in case an entire SG breaks down (no matter how
many SGPs it has, there might always be central errors or an earthquake or
whatever). And also, for ANY kind of traffic, there has to be more than 1
ASP available to each SG. 

[Greg] Agreed.  For this redundancy, I have previously mentioned that the
Operator must ensure that the ASPs use SGPs or SGs that are on different
Hosts.  Gery adds that the SGPs would probably also need to be in different
locations.  So this is covered either way.

- application redundancy : that's why we have multiple ASPs in an AS to
handle a PARTICULAR portion of the traffic. 

[Greg] Agreed.  This has no bearing on the SGP / SG issue. 

At least from a functional point of view, an SGP doesn't add anything. An
ASP does, while it may be configured to support multiple AS's ! I don't see
an SGP servicing more than one SG ??? So I think it's wrong to search for a
parallel between the two. 

Any views on this ? 

[Greg] I think it is fair to conclude that having multiple SGPs in an SG
does not in itself buy any extra functionality in terms of redundancy over
the multiple SG model.  I think we've been bending over backwards in the
protocol description to accommodate an implementation option (the
"distributed multi-site SG" described above).   So where does this
implementation option make sense? - I think the answer is for the case where
the signalling between the PSTN and IP networks is to go through a single SG
with a single SS7 Point code but with site/processor redundancy for the SG.
Paired SGs won' t do because two Point Codes would be required.   I don't
really have problem with supporting this case.     

I think we can change a few things in the spec to support this but remove
some of the confusion that it brings: 

1) Simplify the protocol description so it is described as between an SGP
and ASP only.  That is, SCTP associations are always between SGPs and ASPs.
Today the spec goes back and forth between the SGP and SG terms and adds
qualifying text in various places. 

[Howard] I'm not clear what you mean here, certainly both ASPs and SGPs
contain SCTP endpoints and associations are between SCTP endpoints e.g.
between SGPs and ASPs.  Are you suggesting messages like PC availability
should be communicated to an ASP on a per SGP basis?  

2) The SG becomes explicitly a virtual thing not unlike an AS, containing
one or more SGPs.  The spec today seems to shade back and forth on whether
an SG is a physical thing or not.  Of course if an SG is implemented using a
single SGP, then that is fine  2;^)

[Howard] I agree SGs are virtual things.  (Could you not also describe SGPs
as virtual things?  Particularly if implemented over a number of distinct
operating system tasks?)

So a paired SG architecture is now two SGPs on different hosts represented
to the SS7 network with a Point Code per host.  No coordination of MTP3,
SPMC or AS/ASP states between the SGPs is required.  A single distributed SG
is the same except that it is represented to the SS7 network with a single
SS7 Point Code for the set of SGPs.  The SGPs SHOULD support MTP3, SPMC and
AS/ASP state sharing and re-routing of traffic between the two SGPs.  How
the inter-SGP protocol accomplishes this is not described in the protocol
spec.   

[Howard] I agree a distributed SG needs to coordinate the state info you
have identified and should re-route messages between SGPs.  I don't think we
have to restrict an SG to having a single SS7 Point Code it might have a PC
per link-set.

3) The ASPs do not need to know the grouping of SGPs in virtual SGs so they
treat each SGP as an independent route out to the SS7 network.  But an ASP
MAY choose to maintain such knowledge.   The SSNM messaging from the SGPs to
the ASP is therefore processed independently.  Note that for Operators that
choose not to combine SGPs into virtual SGs (i.e., use paired physical SGs),
then nothing has really changed here.   ASPs that choose to keep knowledge
of SGP groupings into virtual SGs MAY interpret SSNM messaging from one of
the SGPs so as to apply to all the SGPs in the virtual SG but should only do
so if the SGPs coordinate their SSNM messaging to the ASPs.

[Howard] I guess if an SGP loses a direct route to a remote PC but can still
access it via a 'partner' SGP then it might send a DRST to an ASP.  In this
case the ASP MUST know that the scope of the DRST message does not extend
beyond the originating SGP.  I think this seems to work well but I would be
uncomfortable about having a choice as to whether the scope of a such a SSNM
message is for the SG or SGP.

Hope this helps, 

   Greg Sidebottom 

____________________________ 

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

-----Original Message----- 
From: Kazuo Watanabe [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: dinsdag 1 mei 2001 6:27 
To: sigtran 
Cc: [email-masked] Subject: RE: [M3UA] AS state
machine sharing between SGPs 

Greg, 

> In the case where there are multiple SGPs in an SG, and the SGPs have 
> magically determined in their coordinated MTP3 route management logic that

> an SS7 destination is now unavailable, should the SSNM message (i.e., DUPU

> in this case) be sent from ALL SGPs to the concerned ASPs.  I assume the 

no. 
i think all concerned ASPs should receive but not all SGPs should send. 
because DUNA indicates SS7 route state not SG/SGP state. 

> answer is yes given the logic of the discussion on this thread.  So that 
> means that if the triggering event is reception of TFP(s) from the SS7 
> network, then all SGPs in an SG must coordinate their MTP3 view of the 
> availability of the SS7 destination.   Equivalent arguments can be made
for 
> virtually any SS7 link or route management event. 

yes. 
i think this is `multiple SGPs in an SG.' 

i guess the difference between multiple SGs and multiple SGPs in an SG is
mainly single Signalling Point or multiple Signalling Points from SS7 point
of view. 
therefore the SG which has multiple SGPs should have one MTP3 network
management function not per SGP. 

in that case, each SGP could have different AS state and should have the
same SS7 state. 

> Also, if one SGP has determined an SS7 destination is unavailable, but the

> destination is still available via other SGPs (a link event?), then I
assume 

according to my understanding, this is multiple SGs not multiple SGPs in an
SG. 

> that the SGP would optionally send an DRST - although we could make the
case 
> that a DUPU could be used by SGP implementations that don't redirect any 
> traffic received to the other SGPs.  I wouldn't recommend it though as
this 
> implies message loss. 
> Does this sound right? 

if you are saying about STP-like SGs configuration, it sounds right to me. 

-- 
Kazuo Watanabe 

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

---
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: Interworking Between SUA and SCCP/M3UA
Date: Tue, 22 May 2001 14:03:22 +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]

Hi,
 
To SCCP, it is irrelevant whether it runs on MTP3 or M3UA. Also in the
IP-domain (M3UA), SCCP still routes on point codes and/or GTs as if IP
addresses never existed.
 
So from SUA's point of view, it's interworking with SCCP whether this is on
top of MTP or M3UA.
 
Regards,

____________________________ 

Gery Verwimp 
SIEMENS ATEA 
ICN D CS D5 

Tel. : +32 14 25 3424 
Fax : +32 14 25 3212 
mailto:g <mailto:g> [email-masked]
____________________________________ 

-----Original Message-----
From: Young Michael-Y10724 [mailto:[email-masked]] Sent:
woensdag 16 mei 2001 7:29
To: sigtran
Subject: RE: Interworking Between SUA and SCCP/M3UA

Robin, 

Assume if the interworking is done at SGW, there is no difference in terms
of protocol.  To SCCP-user layer, it doesn't care.

BR, 

Michael Young 
--------------------------------------------------------------- System
Design, GTSS Vancouver, Motorola Tel: +1 (604)241-6032   Cel: +1
(604)726-6609 Email: [email-masked] 
--------------------------------------------------------------- 

> -----Original Message----- 
> From: Chiang Robin-RCHIANG2 
> [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, May 15, 2001 2:58 AM 
> To: sigtran 
> Subject: RE: Interworking Between SUA and SCCP/M3UA 
> 
> 
> Michael, 
> 
> In the case of SUA interworking with legacy SS7 protocol, the 
> two endpoints 
> are in different domains i.e. IP and SS7. 
> As for interworking between SUA and SCCP/M3UA, the two 
> endpoints are in the 
> IP domains. One difference is the routing using MTP3 and SCTP. 
> 
> Regards, 
> 
> Robin Chiang Cher Nung 
> [email-masked] < mailto:[email-masked]
<mailto:[email-masked]> > 
> Motorola GSM Systems Division 
> GSM Research Group 
> 16 Euroway, Blagrove, Swindon, 
> Wiltshire SN5 8YQ. 
> Tel: +44 1793 566237 
> Mobile: 07808 949599 
> Fax: +44 1793 566225 
> 
> 
> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, May 15, 2001 7:59 AM 
> To: sigtran 
> Subject: RE: Interworking Between SUA and SCCP/M3UA 
> 
> 
> Hi Michael, 
> 
> Quick question regarding interworking between SUA and 
> SCCP/M3UA, personally 
> I don't see any difference comparing to SUA interworking with 
> legacy SS7 
> protocols (SCCP/MTP3).  Did I miss anything?  Please correct 
> me if I am 
> wrong. 
> 
> [<JAL> ] I don't think so. 
>  
> 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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Rosen, Brian" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
Date: Tue, 22 May 2001 08:31:01 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: mailgate.pit.comms.marconi.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [169.144.68.6]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I was thinking of trying to so a SUA test at the next Megaco Interop Event,
which would be September at University of New Hampshire.  While we wanted to
try Megaco/SCTP-SUA combinations to support ISDN PRI gateways we could
certainly expand to supporting just the SCTP-SUA standalone.

This gets you the facility, the infrastructure, and the logistics support
with minimal effort.  At present MSF will sponsor this event, ISC
(Softswitch Consortium) has supported Megaco Interop Events in the past, but
I don't know what they will do going forward.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:30 AM
> To: sigtran
> Subject: Other bakeoffs was: M2UA bakeoff.
> 
> 
> Hi,
> 
> > Are there any plans to have an M2UA bakeoff 
> > (or any of the other adaptation layers such as M2PA) ? 
> > To me, it would seem logical to co-locate such an 
> > event with the next M3UA bakeoff. What are peoples 
> > feelings on this? Is there enough interest in any case?
> 
> And is there interested in an SUA bakeoff?
> 
> 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: Verwimp Gery <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Coene Lode <[email-masked]>, [email-masked]
Subject: RE: Routing Key Management in SUA
Date: Tue, 22 May 2001 14:47:56 +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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Greg,

I wonder what problems you see ... At least I can see the following reasons
why not to use RKM procedures in SUA :

- specifying GT parameters to register for traffic seems way too complex
(overlapping scenario's ? management procedures ??) - SPCs make no sense
anymore in the IP-domain. Remember there are basically 2 scenario's :

	=> SG performs GTT to cross domains : by definition, SPCs cannot be
used for any management purposes in the IP-domain.
	=> SG routes on DPC + SSN : by definition, the AS is considered as a
local SCCP-user of the SG; RKM would consist of network appearance + SSN by
default. (Remember definition of network appearance for SUA !!)

Granted, a OPC can be present in the calling party address to enable the SG
to route back a response (North American networks ?), but to the ASP this
may just as well be any 3-byte opaque value ...

- RKM is not used in an all-IP environment (no SG).

Now, using RKM would mean building up the GTT database of SCCP at the SG
dynamically : I can imagine this creates a lot more problems for the SG
unless you have some SCCP++ ;-)

SCCP and SUA have to work end-to-end, not in a link-by-link fashion.
Therefor it seems logical to me that a relay functionality would exist in
SUA as well. Since more than GTs can be used by the relay function (also
hostnames, perhaps even IP addresses since these are only a handle to the
appropriate SCTP association ?) we came up with the AMF (address mapping
function); to perform this relay functionality in an all-IP environment.
RKM seems already "inherent" to the SUA procedures.

Indeed, there are some fundamental differences between M3UA and SUA.

Best regards,

____________________________

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent: vrijdag
18 mei 2001 14:30
To: [email-masked]
Cc: [email-masked]; [email-masked] Subject: RE:
Routing Key Management in SUA

Hi Greg,

I have been thinking about these issues quite alot - though my processing
power has been cut (I've been averaging 4 hours of sleep a night ...).  

Maybe Gery, Lode & I can have a pow-wow on this.  Gery & Lode, let me know
when you are available.  You can join too, Greg, but I suspect that you are
quite busy.

Anyhow, just to throw a few thoughts down.

I've thought that an SG will use AS and ASP management messages to know the
state of the endpoints in the IP domain.  As messages come into the SG from
the SS7 network, the SG uses some sort of table in memory to key off of in
order to route the message to the proper ASP.  

I will need to ponder this in more depth ... comments appreciated.

[Greg] Remembering some e-mail threads form Lode, Gery, yourself and others
I think it is finally dawning on me that it is probably the latter.
Either way this is a major change in direction here that we should bring out
for explicit discussion on the list.   I think this could be a major problem
for the SG architecture.  Sorry if I am over-reacting but a switch went off
in my head and I see all kinds of problems for the SG architecture case
where I would effectively have an SCCP layer and now an SUA layer that is an
SCCP+.

I agree.

John

---
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, 22 May 2001 08:51:02 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
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 think you are interested in testing IUA with Megaco.  I agree that it
would be very beneficial to test them together.

What does the Sigtran group need to do to get IUA included at this bakeoff
event?

Regards,

Ken

At 08:31 AM 5/22/01 -0400, Rosen, Brian wrote:
>I was thinking of trying to so a SUA test at the next Megaco
>Interop Event, which would be September at University of
>New Hampshire.  While we wanted to try Megaco/SCTP-SUA combinations
>to support ISDN PRI gateways we could certainly expand to supporting
>just the SCTP-SUA standalone.
>
>This gets you the facility, the infrastructure, and the logistics
>support with minimal effort.  At present MSF will sponsor this
>event, ISC (Softswitch Consortium) has supported Megaco Interop
>Events in the past, but I don't know what they will do going forward.
>
>Brian
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 5:30 AM
> > To: sigtran
> > Subject: Other bakeoffs was: M2UA bakeoff.
> > 
> > 
> > Hi,
> > 
> > > Are there any plans to have an M2UA bakeoff 
> > > (or any of the other adaptation layers such as M2PA) ? 
> > > To me, it would seem logical to co-locate such an 
> > > event with the next M3UA bakeoff. What are peoples 
> > > feelings on this? Is there enough interest in any case?
> > 
> > And is there interested in an SUA bakeoff?
> > 
> > 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]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive "
X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3
Date: Tue, 22 May 2001 21:58:09 +0900
From: Kazuo Watanabe <[email-masked]>
X-SMTP-HELO: TYO201.gate.nec.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: TYO201.gate.nec.co.jp [202.32.8.214]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

resend

---------------------------------------- Ken,

> >but anyway, i agree re-sync by ASP-UP.
> 
> what do you mean by this sentence.

i mean i can live with SG always acknowledging ASP-UP.
ie. ASP-UP forces SG's ASP status INACTIVE.

-- 
Kazuo Watanabe

---
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, 22 May 2001 09:13:54 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: RE: M3UA Iss7 - ASP-Up received when ASP is "active" or
"Inactive "
Cc: [email-masked]
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Kazuo,

That's what I thought you meant, but wanted to verify before I agreed.  It
seems best to ensure that SG and ASP stay in-sync regarding ASP state.

Regards,

Ken

At 09:58 PM 5/22/01 +0900, Kazuo Watanabe wrote:
>resend
>
>----------------------------------------
>Ken,
>
> > >but anyway, i agree re-sync by ASP-UP.
> > 
> > what do you mean by this sentence.
>
>i mean i can live with SG always acknowledging ASP-UP.
>ie. ASP-UP forces SG's ASP status INACTIVE.
>
>-- 
>Kazuo Watanabe
>
>
>---
>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, 22 May 2001 10:27:17 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: M2UA draft 7 questions
Cc: "Patel, Chirayu" <[email-masked]>
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Sorry for the delayed response.  I've been on vacation.

Please see below for feedback.

Regards,

Ken

At 07:45 PM 4/25/01 -0700, Jacob Heitz wrote:
>"Patel, Chirayu" wrote:
> > 
> > Hi,
> > 
> > While going through draft 7 of M2UA, I came across the following issues
> > which I think need more clarification :
> > 
> > 1. SCTP congestion in the SG. The draft suggests that M2UA should inform
> > MTP2 about LPO. Is this enough? Since MTP3 (on the ASP) is unaware of
LPO it
> > is going to send data, which will result in removal of LPO state at the
> > remote end.
>
>Sending of LPO is disputed by me and a number of others on this list.
>I suggest to delete the 2 paragraphs in 1.5.5 that say LPO should be sent.

SCTP congestion is the last remaining issue as noted in Section 10 of the
draft.  The text regarding LPO was a placeholder because we have not reached
a consensus on the list.  LPO was one of the ideas discussed quite awhile
ago.

I'd love to draw this discussion to a conclusion (see more below).

>There is no precedent for sending LPO on congestion. In fact, the
>precedent is to take the link down. MTP2 takes the link down if
acknowledements
>are withheld for longer than T7 or longer than T6 in the presence of SIB.

In an email dated 2/7/01, you suggested the following for handling SCTP
congestion:

The MGC will remember the last Congestion Indication message it received
from the SG. If, at the MGC, SCTP indicates congestion to M2UA, (that means
SCTP transmission and retransmission buffer fill exceeds a given congestion
onset threshold) M2UA will send the Link-Congested primitive to MTP3 for all
affected MTP2 links. The level of congestion indicated shall be the highest
possible.

If, at the MGC, SCTP indicates congestion abatement to M2UA, (that means
SCTP transmission and retransmission buffer fill falls below a given
congestion abatement threshold) M2UA will send the Link-Congested primitive
or the Link-Congestion-ceased primitive to MTP3 for all affected MTP2 links.
The level of congestion indicated shall be as indicated in the last
Congestion Indication message received from the SG.

The SG will remember the last congestion status message it received from the
MGC (that is STATUS_CONG_ACCEPT, STATUS_CONG_DISCARD or STATUS_CONG_CLEAR).
If, at the SG, SCTP indicates congestion to M2UA and the last congestion
status message received from the MGC was STATUS_CONG_CLEAR M2UA will send
the Congestion-Accept primitive to MTP2.

If, at the SG, SCTP indicates congestion abatement to M2UA, M2UA will send a
congestion primitive to MTP2. The level of congestion indicated shall be as
indicated in the last congestion status message received from the MGC.

So, we have the following options that have been discussed in the past.

1)  current text (LPO)  - could be effective if one could guarantee that MGC
and SG would enter SCTP congestion simultaneous, but since that cannot be
guaranteed....

2)  apply MTP congestion procedures (see Jacob's text above) - this option
had some positive discussion in the past (i.e. there have been others that
have suggested something similar)

3)  take the links out-of-service

It would be great if people could provide some feedback so we can bring this
issue to a close. 

> > 
> > 2. Congestion and Discard status. As per Q.704 3.8.2.1, the setting of
the
> > congestion is implementation dependent. In light of this, shouldn't the
> > Congestion status be optional?
>
>3.8.2.1 requires that an indication of the level of congestion be given.
>So the message sent by M2UA must convey a level. What is implementation
>dependent is when to send the message and what criterion to use to
>determine the level. This remains implementation dependent in M2UA.
>
>One thing I would like to have changed is that implementations that do
>not support multiple levels of congestion use LEVEL_NONE and LEVEL_3
>rather than LEVEL_NONE and LEVEL_1. If this is done, M2UA will be able
>to connect an MTP2 implementation that does not support multiple levels 
>with an MTP3 implementation that does.
>
> > 
> > regards,
> > CP 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: "Rosen, Brian" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
Date: Tue, 22 May 2001 10:33:44 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: mailgate.pit.comms.marconi.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [169.144.68.6]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Basically, just telling me you want to do it is enough to get the whole
event handled.  What we need to do that takes some effort is to define the
test scenarios and whatever documentation/scripts ... we need, plus think
through any test equipment we want to arrange (T1/E1 emulators).  We can
sometimes get some assistance from test equipment vendors on that.

I'm sure I can get UNH and MSF to agree to expand the event; it fits 100%
with what they want to do.  I'll also be working on ISC support.  Getting
sponsor support makes the cost for participation go down.  So far, with the
Megaco events, the cost has been zero to participants, but we have also had
a corporate sponsor that picked up some of the costs.  

Brian

> -----Original Message-----
> From: Ken Morneault [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 8:51 AM
> To: sigtran
> Subject: RE: Other bakeoffs was: M2UA bakeoff.
> 
> 
> 
> 
> Brian,
> 
> I think you are interested in testing IUA with Megaco.  I agree that
> it would be very beneficial to test them together.
> 
> What does the Sigtran group need to do to get IUA included at
> this bakeoff event?
> 
> Regards,
> 
> Ken
> 
> 
> At 08:31 AM 5/22/01 -0400, Rosen, Brian wrote:
> >I was thinking of trying to so a SUA test at the next Megaco
> >Interop Event, which would be September at University of
> >New Hampshire.  While we wanted to try Megaco/SCTP-SUA combinations
> >to support ISDN PRI gateways we could certainly expand to supporting
> >just the SCTP-SUA standalone.
> >
> >This gets you the facility, the infrastructure, and the logistics
> >support with minimal effort.  At present MSF will sponsor this
> >event, ISC (Softswitch Consortium) has supported Megaco Interop
> >Events in the past, but I don't know what they will do going forward.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, May 22, 2001 5:30 AM
> > > To: sigtran
> > > Subject: Other bakeoffs was: M2UA bakeoff.
> > > 
> > > 
> > > Hi,
> > > 
> > > > Are there any plans to have an M2UA bakeoff 
> > > > (or any of the other adaptation layers such as M2PA) ? 
> > > > To me, it would seem logical to co-locate such an 
> > > > event with the next M3UA bakeoff. What are peoples 
> > > > feelings on this? Is there enough interest in any case?
> > > 
> > > And is there interested in an SUA bakeoff?
> > > 
> > > 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]
> 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 22 May 2001 09:48:18 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2UA bakeoff.
Reply-To: [email-masked]
Mail-Followup-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 
                      JAA03717
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.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Gee Tom,

The interest is there... Want to pass the hat for Alcatel in Plano?

--Brian

On Tue, 22 May 2001, John Townsend wrote:

> 
>    We would certainly wish to attend an M2UA Bakeoff ASAP.
>    
>    
>    
>    John Townsend.
>    
>    Telesoft Technologies Ltd.
>    

-- 
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]
Subject: RE: Other bakeoffs was: M2UA bakeoff.
Date: Tue, 22 May 2001 17:28:59 +0200
Thread-Topic: Other bakeoffs was: M2UA bakeoff.
Thread-Index: AcDiqmCiS3Men8wEQxGwF7jpqazuugAIL+rw
From: Hong Liu <[email-masked]>
To: "sigtran" <[email-masked]>
X-SMTP-HELO: air1.airslide.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [212.150.80.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

How about M2PA? I read about it a while ago. Any update on that regard?

Cheers,

--Hong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] Sent:
2001Äê5ÔÂ22ÈÕ 5:30
To: sigtran
Subject: Other bakeoffs was: M2UA bakeoff.

Hi,

> Are there any plans to have an M2UA bakeoff 
> (or any of the other adaptation layers such as M2PA) ? 
> To me, it would seem logical to co-locate such an 
> event with the next M3UA bakeoff. What are peoples 
> feelings on this? Is there enough interest in any case?

And is there interested in an SUA bakeoff?

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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 22 May 2001 11:30:14 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Who would be interested in testing IUA (RFC 3075) at the Megaco bake-off in
September (see below)?

Regards,

Ken

At 10:33 AM 5/22/01 -0400, Rosen, Brian wrote:
>Basically, just telling me you want to do it is enough to get
>the whole event handled.  What we need to do that takes some effort
>is to define the test scenarios and whatever documentation/scripts
>... we need, plus think through any test equipment we want to
>arrange (T1/E1 emulators).  We can sometimes get some assistance
>from test equipment vendors on that.
>
>I'm sure I can get UNH and MSF to agree to expand the event; it
>fits 100% with what they want to do.  I'll also be working on ISC
>support.  Getting sponsor support makes the cost for participation
>go down.  So far, with the Megaco events, the cost has been zero
>to participants, but we have also had a corporate sponsor that picked
>up some of the costs.  
>
>Brian
>
> > -----Original Message-----
> > From: Ken Morneault [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 8:51 AM
> > To: sigtran
> > Subject: RE: Other bakeoffs was: M2UA bakeoff.
> > 
> > 
> > 
> > 
> > Brian,
> > 
> > I think you are interested in testing IUA with Megaco.  I agree that
> > it would be very beneficial to test them together.
> > 
> > What does the Sigtran group need to do to get IUA included at
> > this bakeoff event?
> > 
> > Regards,
> > 
> > Ken
> > 
> > 
> > At 08:31 AM 5/22/01 -0400, Rosen, Brian wrote:
> > >I was thinking of trying to so a SUA test at the next Megaco
> > >Interop Event, which would be September at University of
> > >New Hampshire.  While we wanted to try Megaco/SCTP-SUA combinations
> > >to support ISDN PRI gateways we could certainly expand to supporting
> > >just the SCTP-SUA standalone.
> > >
> > >This gets you the facility, the infrastructure, and the logistics
> > >support with minimal effort.  At present MSF will sponsor this
> > >event, ISC (Softswitch Consortium) has supported Megaco Interop
> > >Events in the past, but I don't know what they will do going forward.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Tuesday, May 22, 2001 5:30 AM
> > > > To: sigtran
> > > > Subject: Other bakeoffs was: M2UA bakeoff.
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > > Are there any plans to have an M2UA bakeoff 
> > > > > (or any of the other adaptation layers such as M2PA) ? 
> > > > > To me, it would seem logical to co-locate such an 
> > > > > event with the next M3UA bakeoff. What are peoples 
> > > > > feelings on this? Is there enough interest in any case?
> > > > 
> > > > And is there interested in an SUA bakeoff?
> > > > 
> > > > 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]
> > 
>
>
>---
>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, 22 May 2001 11:39:17 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: M2UA bakeoff.
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]

Any volunteers for facilities?

Regards,

Ken

At 11:26 AM 5/22/01 +0100, John Townsend wrote:
>We would certainly wish to attend an M2UA Bakeoff ASAP.
>  
>John Townsend.
>Telesoft Technologies Ltd.
>>-----Original Message----- 
>>From: Fairlie-Cuninghame, Robert [mailto:[email-masked]] 
>>Sent: 22 May 2001 10:20 
>>To: sigtran 
>>Subject: M2UA bakeoff.
>>
>>Hi, 
>>
>>Are there any plans to have an M2UA bakeoff (or any of the other
adaptation layers such as M2PA) ? To me, it would seem logical to co-locate
such an event with the next M3UA bakeoff. What are peoples feelings on this?
Is there enough interest in any case? 
>>Robert. 
>>
>>-----Original Message-----  
>>From:   Ken Morneault
[<mailto:[email-masked]>mailto:[email-masked]]  
>>Sent:   Monday, May 21, 2001 11:43 PM  
>>To:     sigtran  
>>Subject:        Re: M2UA Notify message 
>>
>>
>>
>>Hanping, 
>>
>>I agree that "Insufficient ASP Resources Active in AS" is not  
>>required for M2UA.  I will remove it. 
>>
>>Regards, 
>>
>>Ken 
>>
>>At 03:03 PM 5/21/01 -0700, Long, Hanping wrote:  
>> >Hi all:  
>> >  
>> >Since only over-ride mode is supported in M2UA, I think the Notify
message  
>> >with staus information (Insufficient ASP resources active in AS) is not

>> >needed any more. In the case when the original active ASP sends ASP
Inactive  
>> >message to SG, the AS state in the SG will change from AS-Active to  
>> >AS-Pending, and the Notify message (AS_State_Change) will be sent to all

>> >inactive ASP. In this scenario, the additional Notify message (Status
Type:  
>> >Other; Status Info.: Insufficient ASP active in AS) is not informative,
thus  
>> >not needed  because ASP could get this information from the Notify
message  
>> >indicating the AS state change.  
>> >  
>> >I would appreciate if somebody could identify and resolve this issue.  
>> >  
>> >thanks,  
>> >hanping  
>> >  
>> >  
>> >  
>> >---  
>> >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]
X-Authentication-Warning: bastion.ottawa.pt.com: bart set sender to 
                          <[email-masked]> using -f
From: "Benjamin J. Wilson" <[email-masked]>
Organization: Performance Technologies
To: "sigtran" <[email-masked]>
Subject: RE: FW: M3UA Iss7 - Routing Key Overlap
Date: Tue, 22 May 2001 12:28:32 -0400
X-Mailer: KMail [version 1.0.29]
X-SMTP-HELO: mx1.magmacom.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [206.191.0.217]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Greg,

Doesn't your statement also assume that ASP1 was activating in loadshare
mode?  I thought there was also some suggestion that Traffic Mode be added
to the REGREQ message.  If both the original RK and the new were loadshare
mode then you could "split" and loadshare on the first.
Definitely needs more text.

Ben

On Tue, 15 May 2001, Joe Keller wrote:
> Hi Greg,
> 
>     Interesting problem.  The problem I have with this are what is
> sent to the ASP1 when ASP2 asks for the "split".  I would expect the
> SG needs to inform ASP1 that the routing key it registered for using
> some Local-RK-Identifier is now two (at least two, I can think of
> more complex scenarios) separate routing contexts.  After all, how
> would ASP1 indicate it wanted to deregister for the original key?
> 
> Would you want to add a new RKM message just for this case?  Does
> the ASP care how the routing keys are broken up?  I am sure the
> problem can be solved and the SG will guarantee unique routing.
> It seems like it needs more text than just changing the MUST to a
> SHOULD.
> 
> Joe
> 
> 
> 
>  -----Original Message-----
> 
> >Hi Joe,
> >
> >The application I seem to remember is where an SG could accept an
> >overlapping RK and rearrange the configuration data to ensure unique
> >routing.  For example, if ASP1 registered for DPC=X, CIC codes 1 - 100.
> >Then later ASP2 came in and registered for DPC=x, CIC codes 1 - 50.  The
SG
> >could react by creating internally RK structures that allow both ASP1and
> >ASP2 to receive traffic for CICs 1-50 and ASP1 to get 51-100.  How the
> >actual traffic is distributed is determined by the traffic modes in the
> >ASP-Actives.
> >
> >All this assumes that there is no change to the protocol needed (i.e.,
the
> >SG handles this internally).  If so then how an SG does this is probably
> >implementation dependent.  The key is that if an SG can do this and still
> >ensure unique routing, then we should allow it.
> >
> >Hope this helps,
> >
> >   Greg
> >
> > -----Original Message-----
> >From:    Joe Keller [mailto:[email-masked]]
> >Sent:    Thursday, May 10, 2001 12:56 PM
> >To: sigtran
> >Subject: Re: FW: M3UA Iss7 - Routing Key Overlap
> >
> > << File: Internet HTML >> << File: footer >>
> >Greg,
> >
> >    Can you clarify the valid cases for allowing overlapped routing key?
> >We may need to add text to what you have already proposed.
> >
> >Thanks,
> >Joe
> >
> >
> >
> >
> >
> >"Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]> on
> >05/10/2001
> >09:36:09 AM
> >
> >Please respond to [email-masked]
> >
> >To:   "sigtran" <[email-masked]>
> >cc:    (bcc: Joe Keller/Raleigh/TEKELEC)
> >Subject:  FW: M3UA Iss7 - Routing Key Overlap
> >
> >
> >
> >
> >Resending - I sent (and resent) some e-some mails out yesterday and
didn't
> >see anything on the list, except for my test e-mail!.  Perhaps all my
mails
> >are being sent to "my sigtran archive" instead   2;^)
> >
> > -----Original Message-----
> >From:     Sidebottom, Greg [BCNR:7M01:EXCH]
> >Sent:     Wednesday, May 09, 2001 11:32 AM
> >To:  [email-masked]'
> >Subject:  M3UA Iss7 - Routing Key Overlap
> >
> >Greetings,
> >
> >An issue was raised against the current text where we explicitly mention
> >that overlap of Routing Key information is not allowed.
> >
> >From Section 1.4.2.2:
> >
> >    "Routing Keys MUST be unique in the sense that a received SS7
> >     signalling message cannot be matched to more than one Routing
> >     Key."
> >
> >And in 4.3.4.1:
> >
> >    "If the SG determines that the Routing Key parameter overlaps
> >     with an existing Routing Key entry, the SG returns a
> >     Registration Response message to the ASP, with a Registration
> >     Status of "Error - Overlapping (Non-Unique) Routing Key".  An
> >     incoming signalling message received at an SG cannot match
> >     against more than one Routing Key."
> >
> >I have heard the view that there may be some valid cases where a Routing
Key
> >overlap is OK.  If so then perhaps we could replace the MUST with a
SHOULD
> >in 1.4.2.2.  For 4.3.4.1 the last line could be deleted and we could
> >generalize the error response from "Overlapping (Non-Unique) RK" to
> >something like "Cannot Support Routing on RK" and change the text around
a
> >bit to reflect that the problem is that the SG can't route if it allows
this
> >RK.
> >
> >So to close on this - Is there support for this idea?  If so, are the
above
> >changes OK?
> >
> >Cheers,
> >
> >   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]
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 22 May 2001 14:13:32 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: RE: FW: M3UA Iss7 - Routing Key Overlap
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]

Ben,

In looking back at my notes from the M3UA editing session in Minneapolis, I
see that we discussed use of a cost basis for overlapping keys.  I think it
was you or Norm that brought up the idea of adding cost basis.  If so, are
you interested in making a proposal of how cost basis could be used with
Routing Keys?

Regards,

Ken

At 12:28 PM 5/22/01 -0400, you wrote:
>Greg,
>
>Doesn't your statement also assume that ASP1 was activating in loadshare
>mode?  I thought there was also some suggestion that Traffic Mode be
>added to the REGREQ message.  If both the original RK and the new were
>loadshare mode then you could "split" and loadshare on the first.
>Definitely needs more text.
>
>Ben
>
>On Tue, 15 May 2001, Joe Keller wrote:
> > Hi Greg,
> > 
> >     Interesting problem.  The problem I have with this are what is
> > sent to the ASP1 when ASP2 asks for the "split".  I would expect the
> > SG needs to inform ASP1 that the routing key it registered for using
> > some Local-RK-Identifier is now two (at least two, I can think of
> > more complex scenarios) separate routing contexts.  After all, how
> > would ASP1 indicate it wanted to deregister for the original key?
> > 
> > Would you want to add a new RKM message just for this case?  Does
> > the ASP care how the routing keys are broken up?  I am sure the
> > problem can be solved and the SG will guarantee unique routing.
> > It seems like it needs more text than just changing the MUST to a
> > SHOULD.
> > 
> > Joe
> > 
> > 
> > 
> >  -----Original Message-----
> > 
> > >Hi Joe,
> > >
> > >The application I seem to remember is where an SG could accept an
> > >overlapping RK and rearrange the configuration data to ensure unique
> > >routing.  For example, if ASP1 registered for DPC=X, CIC codes 1 - 100.
> > >Then later ASP2 came in and registered for DPC=x, CIC codes 1 - 50.
The SG
> > >could react by creating internally RK structures that allow both
ASP1and
> > >ASP2 to receive traffic for CICs 1-50 and ASP1 to get 51-100.  How the
> > >actual traffic is distributed is determined by the traffic modes in the
> > >ASP-Actives.
> > >
> > >All this assumes that there is no change to the protocol needed (i.e.,
the
> > >SG handles this internally).  If so then how an SG does this is
probably
> > >implementation dependent.  The key is that if an SG can do this and
still
> > >ensure unique routing, then we should allow it.
> > >
> > >Hope this helps,
> > >
> > >   Greg
> > >
> > > -----Original Message-----
> > >From:    Joe Keller [mailto:[email-masked]]
> > >Sent:    Thursday, May 10, 2001 12:56 PM
> > >To: sigtran
> > >Subject: Re: FW: M3UA Iss7 - Routing Key Overlap
> > >
> > > << File: Internet HTML >> << File: footer >>
> > >Greg,
> > >
> > >    Can you clarify the valid cases for allowing overlapped routing
key?
> > >We may need to add text to what you have already proposed.
> > >
> > >Thanks,
> > >Joe
> > >
> > >
> > >
> > >
> > >
> > >"Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]> on
> > >05/10/2001
> > >09:36:09 AM
> > >
> > >Please respond to [email-masked]
> > >
> > >To:   "sigtran" <[email-masked]>
> > >cc:    (bcc: Joe Keller/Raleigh/TEKELEC)
> > >Subject:  FW: M3UA Iss7 - Routing Key Overlap
> > >
> > >
> > >
> > >
> > >Resending - I sent (and resent) some e-some mails out yesterday and
didn't
> > >see anything on the list, except for my test e-mail!.  Perhaps all my
mails
> > >are being sent to "my sigtran archive" instead   2;^)
> > >
> > > -----Original Message-----
> > >From:     Sidebottom, Greg [BCNR:7M01:EXCH]
> > >Sent:     Wednesday, May 09, 2001 11:32 AM
> > >To:  [email-masked]'
> > >Subject:  M3UA Iss7 - Routing Key Overlap
> > >
> > >Greetings,
> > >
> > >An issue was raised against the current text where we explicitly
mention
> > >that overlap of Routing Key information is not allowed.
> > >
> > >From Section 1.4.2.2:
> > >
> > >    "Routing Keys MUST be unique in the sense that a received SS7
> > >     signalling message cannot be matched to more than one Routing
> > >     Key."
> > >
> > >And in 4.3.4.1:
> > >
> > >    "If the SG determines that the Routing Key parameter overlaps
> > >     with an existing Routing Key entry, the SG returns a
> > >     Registration Response message to the ASP, with a Registration
> > >     Status of "Error - Overlapping (Non-Unique) Routing Key".  An
> > >     incoming signalling message received at an SG cannot match
> > >     against more than one Routing Key."
> > >
> > >I have heard the view that there may be some valid cases where a
Routing Key
> > >overlap is OK.  If so then perhaps we could replace the MUST with a
SHOULD
> > >in 1.4.2.2.  For 4.3.4.1 the last line could be deleted and we could
> > >generalize the error response from "Overlapping (Non-Unique) RK" to
> > >something like "Cannot Support Routing on RK" and change the text
around a
> > >bit to reflect that the problem is that the SG can't route if it allows
this
> > >RK.
> > >
> > >So to close on this - Is there support for this idea?  If so, are the
above
> > >changes OK?
> > >
> > >Cheers,
> > >
> > >   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] 

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 22 May 2001 16:31:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: SCTP: T3-rtx Issue
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [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 
                      QAA09438
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-240.dallas.net [209.44.42.240]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

All,

I know that everyone seems to be having a lot of fun with checksums and
things.  As a break from that, perhaps someone can clarify the following
problems I am having with a T3-rtx timer problem with RFC 2960 (the first
one)...

My problem senario is as diagrammed below for a simple SCTP association:

Data is being transferred fine in the direction from Endpoint A to Endpoint
Z.

        Endpoint A                               Endpoint Z
        ==========                               ==========

        DATA [0]  --------------------------->
        DATA [1]  --------------------------->
                  <--------------------------- SACK [1/4096]
        DATA [2]  --------------------------->
        DATA [3]  --------------------------->
                  <--------------------------- SACK [3/4096]

Now, it may happend that Endpoint Z runs out of receive buffer space and
advertizes a zero receive window in a SACK.
Endpoint Z starts immediately discarding SCTP DATA messages because it has
no buffer space for them.  There is nothing to SACK (because it is
discarding DATA) so it stops sending SACKs to Endpoint A.

        Endpoint A                               Endpoint Z
        ==========                               ==========

                                            (receive window falls
                                                to zero due to
                                                 congestion)

                                   /---------- SACK [3/   0]
                                  /
        DATA [4]  ---------------/----------->   (discards)
        T3-rtx start            /
        DATA [5]  -------------/------------->   (discards)
        DATA [6]  ------------/-------------->   (discards)
             .    <----------/
             .
             .
        T3-rtx timeout

Endpoint A, because of the window rules starts probing according to 6.1 A.

        DATA [4]  --------------------------->   (discards)
        T3-rtx start
             .
             .
             .
        T3-rtx timeout
        DATA [4]  --------------------------->   (discards)
        T3-rtx start
             .
             .
             .
        T3-rtx timeout
        DATA [4]  --------------------------->   (discards)
        T3-rtx start
             .
             .
             .
        T3-rtx timeout
        DATA [4]  --------------------------->   (discards)
        T3-rtx start

Unfortunately, the T3-rtx timer rules say that we must peg the
Path.Max.Retrans and Assoc.Max.Retrans as well as perform congestion
avoidance each time that T3-rtx expires.
So, eventually, the sender aborts the association.  Depending on the values
of RTO.max and the experienced RTT this could be quite quickly.
             .
             .
             .
             .
        T3-rtx timeout
       Path.Max.Retrans
          exceeded
       Assoc.Max.Retrans
          exceeded

        ABORT     --------------------------->

My question is, should the T3-rtx expiry rules be modified to NOT peg the
retrans in this case (i.e. when probing according to 6.1(A)) and to NOT
peform the congestion avoidance calculations?  Shouldn't there be some
provision in the specification to preclude the sender from aborting the
association in this case?

(AFAIK TCP's behaviour is to probe with a duplicate segment (of size 0) to
force an ACK regardles of the advertized window.)

-- 
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]
Sender: [email-masked]
Date: Tue, 22 May 2001 17:32:35 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA draft 7 questions
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken Morneault wrote on 22 May 2001:
  [...] 
> So, we have the following options that have been discussed in the
> past.
> 
> 1)  current text (LPO)  - could be effective if one could guarantee that
MGC and SG would
> enter SCTP congestion simultaneous, but since that cannot be
guaranteed....
  [...]

If I read section 1.5.5 (last paragraph) correctly, it has M2UA reporting
Local Processor Outage to its _upper layer_, MTP3. This does not sound like
a good idea. LPO is supposed to mean that that there is a problem at a level
higher than level 2. In Q.703, the LPO primitive goes from Level 3 to Level
2.

Did you maybe mean Remote Proc Outage in that last paragraph?

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Tue, 22 May 2001 21:05:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: Multiple streams
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      VAA13041
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-240.dallas.net [209.44.42.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

re: draft-ietf-sigtran-m2pa-02.txt

Why not have multiple streams per M2PA SCTP association?

Say, place one link (SLC) on each of 16 or 32 streams numbered 1 through 16
(or 32).  Use a single stream 0 status channel.
(All links are either in service, busy, not busy, processor outage, or not
processor outage at the same time anyway).

Multiple links in a linkset are only really used in the SS7 network for
capacity sizing of a linkset: something which does not apply to M2PA in the
same way as fixed bandwidth circuit connections.

-- 
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]
X-Lotus-FromDomain: HSS
From: [email-masked]
To: "sigtran" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], 
    [email-masked]
Date: Wed, 23 May 2001 09:08:11 +0530
Subject: RE: Other bakeoffs was: M2UA bakeoff.
X-SMTP-HELO: hindon.hss.co.in
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [202.54.26.202]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hughes Software Systems would be interested.

Ken Morneault <[email-masked]> on 05/22/2001 09:00:14 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:    (bcc: Harsh
Bhondwe/HSS)

Subject:  RE: Other bakeoffs was: M2UA bakeoff.

Who would be interested in testing IUA (RFC 3075) at the Megaco bake-off in
September (see below)?

Regards,

Ken

At 10:33 AM 5/22/01 -0400, Rosen, Brian wrote:
>Basically, just telling me you want to do it is enough to get
>the whole event handled.  What we need to do that takes some effort
>is to define the test scenarios and whatever documentation/scripts
>... we need, plus think through any test equipment we want to
>arrange (T1/E1 emulators).  We can sometimes get some assistance
>from test equipment vendors on that.
>
>I'm sure I can get UNH and MSF to agree to expand the event; it
>fits 100% with what they want to do.  I'll also be working on ISC
>support.  Getting sponsor support makes the cost for participation
>go down.  So far, with the Megaco events, the cost has been zero
>to participants, but we have also had a corporate sponsor that picked
>up some of the costs.
>
>Brian
>
> > -----Original Message-----
> > From: Ken Morneault [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 8:51 AM
> > To: sigtran
> > Subject: RE: Other bakeoffs was: M2UA bakeoff.
> >
> >
> >
> >
> > Brian,
> >
> > I think you are interested in testing IUA with Megaco.  I agree that
> > it would be very beneficial to test them together.
> >
> > What does the Sigtran group need to do to get IUA included at
> > this bakeoff event?
> >
> > Regards,
> >
> > Ken
> >
> >
> > At 08:31 AM 5/22/01 -0400, Rosen, Brian wrote:
> > >I was thinking of trying to so a SUA test at the next Megaco
> > >Interop Event, which would be September at University of
> > >New Hampshire.  While we wanted to try Megaco/SCTP-SUA combinations
> > >to support ISDN PRI gateways we could certainly expand to supporting
> > >just the SCTP-SUA standalone.
> > >
> > >This gets you the facility, the infrastructure, and the logistics
> > >support with minimal effort.  At present MSF will sponsor this
> > >event, ISC (Softswitch Consortium) has supported Megaco Interop
> > >Events in the past, but I don't know what they will do going forward.
> > >
> > >Brian
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Tuesday, May 22, 2001 5:30 AM
> > > > To: sigtran
> > > > Subject: Other bakeoffs was: M2UA bakeoff.
> > > >
> > > >
> > > > Hi,
> > > >
> > > > > Are there any plans to have an M2UA bakeoff
> > > > > (or any of the other adaptation layers such as M2PA) ?
> > > > > To me, it would seem logical to co-locate such an
> > > > > event with the next M3UA bakeoff. What are peoples
> > > > > feelings on this? Is there enough interest in any case?
> > > >
> > > > And is there interested in an SUA bakeoff?
> > > >
> > > > 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]
> >
>
>
>---
>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: Wed, 23 May 2001 05:24:39 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2UA draft 7 questions
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      FAA19645
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-240.dallas.net [209.44.42.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

On Tue, 22 May 2001, Tom George wrote:
> 
> If I read section 1.5.5 (last paragraph) correctly, it has M2UA
> reporting Local Processor Outage to its _upper layer_, MTP3. This does
> not sound like a good idea. LPO is supposed to mean that that there is a
> problem at a level higher than level 2. In Q.703, the LPO primitive goes
> from Level 3 to Level 2.
> 
> Did you maybe mean Remote Proc Outage in that last paragraph?
> 

In Q.703, LPO is diagrammed as coming from an implementation specific
function and going to L2.  Although Q.704 talks about local blocking (LPO),
it does not diagram this in the SDLs as such except on Figure 37/Q.704
(sheet 2 bis of 10).  Q.2210 does indicate LPO as going from MGMT to MTP L3
(TLAC) and also from MGMT to MTP L2.

MTP L3 needs to know if it is locally blocked on a link (LPO) for it to
peform its procedures correctly according to the text (which takes
precedence over the diagrams).

M2UA, sitting just beneath the MTP2-MTP3 interface, is aware of LPO
conditions which the MTP3 management may not be aware.
This primitive to L3 is really a notification to MGMT to send LPO (local
blocking) to L3 per the specs.

So, why does it not sound like a good idea?

-- 
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: Wed, 23 May 2001 08:12:07 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: "Brian F. G. Bidulock" <[email-masked]>
Subject: Re: M2PA: Multiple streams
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]

"Brian F. G. Bidulock" wrote:
> 
> Tom,
> 
> re: draft-ietf-sigtran-m2pa-02.txt
> 
> Why not have multiple streams per M2PA SCTP association?

From page 29 of the draft:

Note: The changeover procedure makes it impossible for M2PA to have multiple
User Data streams in a direction for one link. Buffer updating would have to
be done for each User Data stream separately to avoid duplication of
messages. But MTP3 provides for only one XCO message for sending the
last-received SSN.

> 
> Say, place one link (SLC) on each of 16 or 32 streams numbered
> 1 through 16 (or 32).  Use a single stream 0 status channel.
> (All links are either in service, busy, not busy, processor
> outage, or not processor outage at the same time anyway).
> 
> Multiple links in a linkset are only really used in the SS7
> network for capacity sizing of a linkset: something which does
> not apply to M2PA in the same way as fixed bandwidth circuit
> connections.

Service providers will likely want to deploy M2PA in a phased manner. This
means having both legacy MTP2 links and M2PA links in the same linkset, so
one can serve as a backup for the other.

---
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: FW: M3UA Iss7 - Routing Key Overlap
Date: Wed, 23 May 2001 15:29:36 -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: FW: M3UA Iss7 - Routing Key Overlap</TITLE> </HEAD>
<BODY>

<P><FONT SIZE=2>Hey Joe,</FONT>
</P>

<P><FONT SIZE=2>I can see now that basically I am proposing a (small) change
to the protocol when the requirements are not really known&nbsp;&nbsp;
2:^(</FONT></P>

<P><FONT SIZE=2>My assumption was that, referencing your example, ASP1 would
not be informed of the &quot;key splitting&quot; at the SG and would
continue to use the same Routing Context that it registered for (i.e., ASP1
would just get less traffic than it would have previously).&nbsp;&nbsp; This
is quite different from the assumptions that you appear to have below - and
I'm not really sure yet whether it would even work.&nbsp;&nbsp; The change I
proposed supports a key splitting function mostly by &quot;not
disallowing&quot; a non-unique key.&nbsp; But I do doubt based on your and
Ben's response that this is the final protocol answer to support a proper
&quot;key splitting&quot; function.&nbsp; If we need also other changes to
make this work then that is certainly fair game.</FONT></P>

<P><FONT SIZE=2>My brain starts to hurt when I think of having a (complex)
protocol addition to handle this (hopefully rare) configuration event.&nbsp;
I think we need to think of how this &quot;key splitting&quot; function
would be used by an Operator as in the end they will be the ones initiating
this method of changing the configuration.&nbsp; Then we could look at any
protocol impacts to support the requirements.&nbsp;&nbsp; </FONT></P>

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

<P><FONT SIZE=2>Greg Sidebottom</FONT>
</P>
<BR>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Joe Keller [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Tuesday, May 15, 2001 3:48
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: FW:
M3UA Iss7 - Routing Key Overlap</FONT> </P>

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

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Interesting problem.&nbsp; The problem I
have with this are what is</FONT> <BR><FONT SIZE=2>sent to the ASP1 when
ASP2 asks for the &quot;split&quot;.&nbsp; I would expect the</FONT>
<BR><FONT SIZE=2>SG needs to inform ASP1 that the routing key it registered
for using</FONT> <BR><FONT SIZE=2>some Local-RK-Identifier is now two (at
least two, I can think of</FONT> <BR><FONT SIZE=2>more complex scenarios)
separate routing contexts.&nbsp; After all, how</FONT> <BR><FONT
SIZE=2>would ASP1 indicate it wanted to deregister for the original
key?</FONT> </P>

<P><FONT SIZE=2>Would you want to add a new RKM message just for this
case?&nbsp; Does</FONT> <BR><FONT SIZE=2>the ASP care how the routing keys
are broken up?&nbsp; I am sure the</FONT> <BR><FONT SIZE=2>problem can be
solved and the SG will guarantee unique routing.</FONT> <BR><FONT SIZE=2>It
seems like it needs more text than just changing the MUST to a</FONT>
<BR><FONT SIZE=2>SHOULD.</FONT>
</P>

<P><FONT SIZE=2>Joe</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> </P>

<P><FONT SIZE=2>&gt;Hi Joe,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;The application I seem to remember is where an SG could
accept an</FONT> <BR><FONT SIZE=2>&gt;overlapping RK and rearrange the
configuration data to ensure unique</FONT> <BR><FONT
SIZE=2>&gt;routing.&nbsp; For example, if ASP1 registered for DPC=X, CIC
codes 1 - 100.</FONT> <BR><FONT SIZE=2>&gt;Then later ASP2 came in and
registered for DPC=x, CIC codes 1 - 50.&nbsp; The SG</FONT> <BR><FONT
SIZE=2>&gt;could react by creating internally RK structures that allow both
ASP1and</FONT> <BR><FONT SIZE=2>&gt;ASP2 to receive traffic for CICs 1-50
and ASP1 to get 51-100.&nbsp; How the</FONT> <BR><FONT SIZE=2>&gt;actual
traffic is distributed is determined by the traffic modes in the</FONT>
<BR><FONT SIZE=2>&gt;ASP-Actives.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;All this assumes that there is no change to the
protocol needed (i.e., the</FONT> <BR><FONT SIZE=2>&gt;SG handles this
internally).&nbsp; If so then how an SG does this is probably</FONT>
<BR><FONT SIZE=2>&gt;implementation dependent.&nbsp; The key is that if an
SG can do this and still</FONT> <BR><FONT SIZE=2>&gt;ensure unique routing,
then we should allow it.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Hope this helps,</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Greg</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt;From:&nbsp;&nbsp;&nbsp; Joe Keller [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FON
T> <BR><FONT SIZE=2>&gt;Sent:&nbsp;&nbsp;&nbsp; Thursday, May 10, 2001 12:56
PM</FONT> <BR><FONT SIZE=2>&gt;To: sigtran</FONT> <BR><FONT
SIZE=2>&gt;Subject: Re: FW: M3UA Iss7 - Routing Key Overlap</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &lt;&lt; File: Internet HTML &gt;&gt; &lt;&lt; File:
footer &gt;&gt;</FONT> <BR><FONT SIZE=2>&gt;Greg,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Can you clarify the valid cases for
allowing overlapped routing key?</FONT> <BR><FONT SIZE=2>&gt;We may need to
add text to what you have already proposed.</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Thanks,</FONT>
<BR><FONT SIZE=2>&gt;Joe</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&quot;Sidebottom, Greg [BCNR:7M01:EXCH]&quot;
&lt;[email-masked]&gt; on</FONT> <BR><FONT
SIZE=2>&gt;05/10/2001</FONT>
<BR><FONT SIZE=2>&gt;09:36:09 AM</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Please respond to
[email-masked]</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;To:&nbsp;&nbsp; &quot;sigtran&quot;
&lt;[email-masked]&gt;</FONT> <BR><FONT
SIZE=2>&gt;cc:&nbsp;&nbsp;&nbsp; (bcc: Joe Keller/Raleigh/TEKELEC)</FONT>
<BR><FONT SIZE=2>&gt;Subject:&nbsp; FW: M3UA Iss7 - Routing Key
Overlap</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Resending - I sent (and resent) some e-some mails out
yesterday and didn't</FONT> <BR><FONT SIZE=2>&gt;see anything on the list,
except for my test e-mail!.&nbsp; Perhaps all my mails</FONT> <BR><FONT
SIZE=2>&gt;are being sent to &quot;my sigtran archive&quot;
instead&nbsp;&nbsp; 2;^)</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT
SIZE=2>&gt;From:&nbsp;&nbsp;&nbsp;&nbsp; Sidebottom, Greg
[BCNR:7M01:EXCH]</FONT> <BR><FONT SIZE=2>&gt;Sent:&nbsp;&nbsp;&nbsp;&nbsp;
Wednesday, May 09, 2001 11:32 AM</FONT> <BR><FONT SIZE=2>&gt;To:&nbsp;
[email-masked]'</FONT> <BR><FONT
SIZE=2>&gt;Subject:&nbsp; M3UA Iss7 - Routing Key Overlap</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Greetings,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;An issue was raised against the current text where we
explicitly mention</FONT> <BR><FONT SIZE=2>&gt;that overlap of Routing Key
information is not allowed.</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;From Section 1.4.2.2:</FONT> <BR><FONT
SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &quot;Routing Keys MUST be unique in
the sense that a received SS7</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; signalling message cannot be matched to
more than one Routing</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
Key.&quot;</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;And in 4.3.4.1:</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &quot;If the SG determines that the
Routing Key parameter overlaps</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with an existing Routing Key entry, the
SG returns a</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
Registration Response message to the ASP, with a Registration</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Status of &quot;Error -
Overlapping (Non-Unique) Routing Key&quot;.&nbsp; An</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; incoming signalling message received at
an SG cannot match</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
against more than one Routing Key.&quot;</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I have heard the view that there may be some valid
cases where a Routing Key</FONT> <BR><FONT SIZE=2>&gt;overlap is OK.&nbsp;
If so then perhaps we could replace the MUST with a SHOULD</FONT> <BR><FONT
SIZE=2>&gt;in 1.4.2.2.&nbsp; For 4.3.4.1 the last line could be deleted and
we could</FONT> <BR><FONT SIZE=2>&gt;generalize the error response from
&quot;Overlapping (Non-Unique) RK&quot; to</FONT> <BR><FONT
SIZE=2>&gt;something like &quot;Cannot Support Routing on RK&quot; and
change the text around a</FONT> <BR><FONT SIZE=2>&gt;bit to reflect that the
problem is that the SG can't route if it allows this</FONT> <BR><FONT
SIZE=2>&gt;RK.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;So to close on this - Is there support for this
idea?&nbsp; If so, are the above</FONT> <BR><FONT SIZE=2>&gt;changes
OK?</FONT> <BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Cheers,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Greg</FONT> </P>
<BR>
<BR>
<BR>
<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: Wed, 23 May 2001 15:46:21 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: Greg Sidebottom <[email-masked]>
Subject: Re: FW: M3UA Iss7 - Routing Key Overlap
Reply-To: [email-masked]
Mail-Followup-To: sigtran <[email-masked]>, Greg 
                  Sidebottom <[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 
                      PAA28339
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.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Actually, I was hoping to be able to get a `broadcast' relationship between
ASPs (instead of just override or load-share), where the SG sends a copy of
each message to each ASP registered against the same routing-key in this new
`broadcast' AS.

Reliable broadcast is valid redudancy model which has characteristics more
suited to signalling applications than the leader-follower models supported
by the UAs.

One of the ways of accomodating this (without changing the spec much) is to
define a "load-share" AS with a group of ASPs which have overlapping routing
keys.  If overlapping routing keys are not permitted, I won't be able to
accomplish this.

--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: Wed, 23 May 2001 20:26:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA: Multiple streams
Reply-To: [email-masked]
Mail-Followup-To: Jacob Heitz <[email-masked]>, 
                  [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 
                      UAA32170
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.211]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Wed, 23 May 2001, Jacob Heitz wrote:
> 
> Service providers will likely want to deploy M2PA in a phased
> manner. This means having both legacy MTP2 links and M2PA
> links in the same linkset, so one can serve as a backup for
> the other.

Nah, they're not going to want those junky M2PA links mixed in with their
nice reliable SS7 links.  More likely, they will use a full combined linkset
using M2PA and have a full combined linkset of pure SS7 links as backup.

-- 
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: Wed, 23 May 2001 18:52:05 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
CC: [email-masked]
Subject: Re: M2PA: Multiple streams
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]

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> On Wed, 23 May 2001, Jacob Heitz wrote:
> >
> > Service providers will likely want to deploy M2PA in a phased
> > manner. This means having both legacy MTP2 links and M2PA
> > links in the same linkset, so one can serve as a backup for
> > the other.
> 
> Nah, they're not going to want those junky M2PA links mixed
> in with their nice reliable SS7 links.  More likely, they will
> use a full combined linkset using M2PA and have a full combined
> linkset of pure SS7 links as backup.

and still do changeover from one linkset to the other.

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Wed, 23 May 2001 21:01:43 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA: Multiple streams
Reply-To: [email-masked]
Mail-Followup-To: Jacob Heitz <[email-masked]>, 
                  [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 
                      VAA32627
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.211]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

On Wed, 23 May 2001, Jacob Heitz wrote:
> > > the other.
> > 
> > Nah, they're not going to want those junky M2PA links mixed
> > in with their nice reliable SS7 links.  More likely, they will
> > use a full combined linkset using M2PA and have a full combined
> > linkset of pure SS7 links as backup.
> 
> and still do changeover from one linkset to the other.

Yup.  Nobody is going to go messing around adding M2PA links to an already
working SS7 combined linkset.  If they are added at all, they will be added
as separate combined linksets with the existing SS7 linksets as backup.

Let me put that another way.  The SS7 linksets will be the "primary"
linksets and the M2PA linksets will be the "secondary".
Traffic will be moved onto the M2PA linksets by management inhibiting the
existing SS7 linksets (so that the SS7 links will automatically uninhibit in
the event of M2PA failure).

That is, if M2PA can make the grade to get into an SS7 network at all, which
I doubt is in the short-term.

-- 
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]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-sigtran-m3ua-mib-01.txt
Date: Thu, 24 May 2001 07:01:52 -0400
Sender: [email-masked]
X-SMTP-HELO: ietf.org
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [132.151.1.176]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Signaling Transport Working Group of the
IETF.

	Title		: SS7 MTP3-User Adaptation Layer (M3UA)Management 
                          Information Base using SMIv2
	Author(s)	: A. Roque
	Filename	: draft-sigtran-m3ua-mib-01.txt
	Pages		: 
	Date		: 23-May-01
	
The MTP3-User Adaptation Layer is a protocol for the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol.  Also, provision is
made for protocol elements that enable a seamless operation of the MTP3-User
peers in the SS7 and IP domains. This protocol would be used between a
Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident
Database.  It is assumed that the SG receives SS7 signalling over a standard
SS7 interface using the SS7 Message Transfer Part (MTP) to provide
transport.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sigtran-m3ua-mib-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-sigtran-m3ua-mib-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sigtran-m3ua-mib-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-sigtran-m3ua-mib-01.txt

<ftp://ftp.ietf.org/internet-drafts/draft-sigtran-m3ua-mib-01.txt> ---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Thu, 24 May 2001 13:53:47 +0200
From: Antonio Roque Alvarez <[email-masked]>
Subject: Re: I-D ACTION:draft-sigtran-m3ua-mib-01.txt
Sender: [email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Organization: Ericsson
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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Dear all,

Now that we have gone through the first interop, it's time to have a deeper
look to the MIB.

Version 01 has been restructured, trying to be more understandable.

I will appreciate your comments.

Cheers,
Antonio

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: SCON from ASP (Re: Final report from the Interop Test)
X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3
Date: Thu, 24 May 2001 21:38:12 +0900
From: Kazuo Watanabe <[email-masked]>
X-SMTP-HELO: TYO202.gate.nec.co.jp
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: TYO202.gate.nec.co.jp [202.247.6.41]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

from issue list at bakeoff

>  026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
>         congestion.
(snip)
>      The only case, where the SCON sent by the ASP seems
>      applicable, is when the AS is geographically seperated
>      from the ASP and the ASP detects overload towards the 
>      AS. In any case, I would propose to relate the
>      SCON to the AS (RC) rather than DPC.

"RC rather than DPC" makes sense to me.
i guess we can have new ASPTM Message, ASP Congestion, rather than SCON with
RC.
Does this make sense?

-- 
Kazuo Watanabe

---
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: M2PA: Multiple streams
Date: Thu, 24 May 2001 12:12:18 -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: M2PA: Multiple streams</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>I have already seen &quot;short term&quot; operator
requirements to allow mixing of M2PA and MTP2 links in the same linkset in
their SS7 network, although the implicit understanding seems to be that this
is temporary to &quot;soak-in&quot; the new M2PA links.&nbsp;&nbsp; There
are certainly some technical &quot;challenges&quot; to support this but I
don't think we can state that nobody will do this (although I personally
prefer your approach below).&nbsp; The same issue came up with operators
when they added SAAL/ATM-based links into their SS7 networks, with the same
result - allow them to be mixed up (temporarily).</FONT></P>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Greg Sidebottom</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp; [email-masked]</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+1 613 851-6725 (cell) </FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 23, 2001 10:02 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Cc:&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M2PA: Multiple
streams</FONT> </P>

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

<P><FONT SIZE=2>On Wed, 23 May 2001, Jacob Heitz wrote:</FONT> <BR><FONT
SIZE=2>&gt; &gt; &gt; the other.</FONT> <BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Nah, they're not going to want those junky M2PA
links mixed</FONT> <BR><FONT SIZE=2>&gt; &gt; in with their nice reliable
SS7 links.&nbsp; More likely, they will</FONT> <BR><FONT SIZE=2>&gt; &gt;
use a full combined linkset using M2PA and have a full combined</FONT>
<BR><FONT SIZE=2>&gt; &gt; linkset of pure SS7 links as backup.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; and still do changeover from one linkset to the
other.</FONT> </P>

<P><FONT SIZE=2>Yup.&nbsp; Nobody is going to go messing around adding M2PA
links</FONT> <BR><FONT SIZE=2>to an already working SS7 combined
linkset.&nbsp; If they are added</FONT> <BR><FONT SIZE=2>at all, they will
be added as separate combined linksets with</FONT> <BR><FONT SIZE=2>the
existing SS7 linksets as backup.</FONT> </P>

<P><FONT SIZE=2>Let me put that another way.&nbsp; The SS7 linksets will be
the</FONT> <BR><FONT SIZE=2>&quot;primary&quot; linksets and the M2PA
linksets will be the &quot;secondary&quot;.</FONT> <BR><FONT SIZE=2>Traffic
will be moved onto the M2PA linksets by management</FONT> <BR><FONT
SIZE=2>inhibiting the existing SS7 linksets (so that the SS7 links</FONT>
<BR><FONT SIZE=2>will automatically uninhibit in the event of M2PA
failure).</FONT> </P>

<P><FONT SIZE=2>That is, if M2PA can make the grade to get into an SS7
network</FONT> <BR><FONT SIZE=2>at all, which I doubt is in the
short-term.</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Brian F. G. Bidulock&nbsp;&nbsp;&nbsp; ¦ The reasonable man
adapts himself to the ¦</FONT> <BR><FONT
SIZE=2>[email-masked]&nbsp;&nbsp;&nbsp; ¦ world; the unreasonable one
persists in&nbsp; ¦</FONT> <BR><FONT SIZE=2><A
HREF="http://www.openss7.org/" TARGET="_blank">http://www.openss7.org/</A> ¦
trying&nbsp; to adapt the&nbsp; world&nbsp; to himself. ¦</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
Therefore&nbsp; all&nbsp; progress&nbsp; depends on the ¦</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
unreasonable man. -- George Bernard Shaw ¦</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: Thu, 24 May 2001 12:13:26 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Multiple streams
Reply-To: [email-masked]
Mail-Followup-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-211.dallas.net [209.44.42.211]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Greg,

Field trial and in-service are two different things.  Also, I didn't mean
that mixing should not be permitted, just that it has only temporary and
marginal use.

--Brian

On Thu, 24 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:

> 
>    Hi Brian, Jacob,
>    
>    I have already seen "short term" operator requirements to allow mixing
>    of M2PA and MTP2 links in the same linkset in their SS7 network,
>    although the implicit understanding seems to be that this is temporary
>    to "soak-in" the new M2PA links.   There are certainly some technical
>    "challenges" to support this but I don't think we can state that
>    nobody will do this (although I personally prefer your approach
>    below).  The same issue came up with operators when they added
>    SAAL/ATM-based links into their SS7 networks, with the same result -
>    allow them to be mixed up (temporarily).
>    
>    Cheers,
>    
>       Greg Sidebottom
>       [email-masked]
>       +1 613 851-6725 (cell)
>    

-- 
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: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "'Brian F. G. Bidulock'" <[email-masked]>
Subject: RE: FW: M3UA Iss7 - Routing Key Overlap
Date: Thu, 24 May 2001 13:30: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: FW: M3UA Iss7 - Routing Key Overlap</TITLE> </HEAD>
<BODY>

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

<P><FONT SIZE=2>Hmmm, I must say I like Brian's idea of a multicast traffic
option, although I'm not sure how this relates to overlapping Routing
Keys.&nbsp; I'd assume that ASPs that want to do this &quot;multicast
loadsharing&quot; would use the same Routing Key and register against the
same AS to get the same traffic set.&nbsp; I wouldn't call this an
&quot;overlapping&quot; RK although I must admit we don't have a real
definition on the table.&nbsp; </FONT></P>

<P><FONT SIZE=2>Any interest out there for multicast, assuming the proposal
doesn't change too much in the Iss7 draft of course.&nbsp; I think it might
be just adding an optional traffic mode and a few procedural details&nbsp;
(of course it is a real challenge to implement at the SG but I won't go
there).&nbsp; Actually, I think this could be useful in the Override case as
well.&nbsp; I haven't fully thought this out but a multicast could be used
to clean up any outstanding calls/transactions at the &quot;old&quot; ASP
upon override (e.g., the new ASP sends an ASP-Over-ride (Multicast) and
takes over but traffic now goes to both the old and new ASPs.&nbsp; This is
kind of like the previous discussions on an Over-ride (New traffic) mode
that we had some time ago, but now with less knowledge required at the
SG.&nbsp;&nbsp; When the old ASP has cleaned everything up it sends
ASP-Inactive to stop the traffic.&nbsp; Then the SG could send a Notify or
ASP-Active (Over-ride) Ack to the new ASP.&nbsp; Still requires some
coordination between the ASPs but less call/transaction state information
needs to be exchanged.</FONT></P>

<P><FONT SIZE=2>Getting back to basics - I think we have agreement on the
list that the M3UA should not disallow overlapping Routing Keys.&nbsp;&nbsp;
This will give us more flexibility going forward.</FONT></P>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Greg Sidebottom</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp; [email-masked]</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+1 613 851-6725</FONT> </P>
<BR>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Wednesday, May 23, 2001 4:46 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Greg Sidebottom</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: FW: M3UA Iss7
- Routing Key Overlap</FONT> </P>

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

<P><FONT SIZE=2>Actually, I was hoping to be able to get a `broadcast'
relationship</FONT> <BR><FONT SIZE=2>between ASPs (instead of just override
or load-share), where the</FONT> <BR><FONT SIZE=2>SG sends a copy of each
message to each ASP registered against the</FONT> <BR><FONT SIZE=2>same
routing-key in this new `broadcast' AS.</FONT> </P>

<P><FONT SIZE=2>Reliable broadcast is valid redudancy model which has
characteristics</FONT> <BR><FONT SIZE=2>more suited to signalling
applications than the leader-follower</FONT> <BR><FONT SIZE=2>models
supported by the UAs.</FONT> </P>

<P><FONT SIZE=2>One of the ways of accomodating this (without changing the
spec much)</FONT> <BR><FONT SIZE=2>is to define a &quot;load-share&quot; AS
with a group of ASPs which have</FONT> <BR><FONT SIZE=2>overlapping routing
keys.&nbsp; If overlapping routing keys are not</FONT> <BR><FONT
SIZE=2>permitted, I won't be able to accomplish this.</FONT> </P>

<P><FONT SIZE=2>--Brian</FONT>
</P>
<BR>

<P><FONT SIZE=2>snip</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>
To: "sigtran" <[email-masked]>
Date: Thu, 24 May 2001 10:44:46 -0700
From: Lyndon Ong <[email-masked]>
X-Sent-Mail: off
Reply-To: [email-masked]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: future planning
X-Sender-Ip: 63.96.78.21
Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80)
X-SMTP-HELO: shared1-mail.whowhere.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: shared1-batch.whowhere.com [209.185.123.82]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Folks,

Just doing some future planning...

We still have several items on our todo list:

-- get M3UA out to IESG - as soon as the updated 
   version comes out, hopefully very soon

-- Last Call M2UA, M2PA, SUA and v5UA

-- Last Call MIBs

-- Last Call Signalling AS

-- organize/document bakeoffs as needed

I would like group feedback on whether any other items should be added to
this list, as well as whether we need to hold a session in London.  I've had
one informal request for this already and am leaning towards requesting a
slot, hopefully our last.

Cheers,

L. Ong

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

---
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: SCON from ASP (Re: Final report from the Interop Test)
Date: Thu, 24 May 2001 14:35:10 -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: SCON from ASP (Re: Final report from the Interop Test)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>I must admit I never really liked the SCON from the ASP to
the SG procedure (I resisted it for a long time) and was kind of glad to see
this come up as an issue in the &quot;Bay-cough&quot;.&nbsp; I liked the
Final Report proposal that this procedure should be replaced by </FONT></P>

<P><FONT SIZE=2>&nbsp;&nbsp; &quot;closing of the receiver window in SCTP
(on upper layer request), which should </FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp;&nbsp; lead to a congestion indication on the other side
(the SG) from SCTP to the upper </FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;
layer. The SG, receiving traffic destined to the congested assoc, should
respond </FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; appropriately to the
originator.&quot;</FONT> </P>

<P><FONT SIZE=2>I honestly don't understand the following case described
after that (i.e., &quot; The only case, where the SCON sent by the ASP seems
applicable, is when the when the AS is geographically separated from the ASP
and the ASP detects overload towards the AS&quot;).&nbsp;&nbsp;&nbsp; I'm
assuming that this is really a case where, within an ASP, separate processes
are used to handle traffic for different Application Servers and these
processes or the paths to them can congest independently.&nbsp; If not then
can someone clarify this case for me?&nbsp; If so then I'd agree with Kazuo
Watanabe that an ASP Congestion message (containing the affected RC) is
clearer than adding an RC parameter to a reverse-direction SCON.</FONT></P>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Greg Sidebottom</FONT> <BR><FONT
SIZE=2>&nbsp;&nbsp; [email-masked]</FONT> <BR><FONT SIZE=2>&nbsp;&nbsp;
+1 613 851-6725 (cell)</FONT> </P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Kazuo Watanabe [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>]
</FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 24, 2001 8:38
AM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Cc:&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SCON from ASP (Re:
Final report from the Interop Test)</FONT> </P>

<P><FONT SIZE=2>from issue list at bakeoff</FONT> </P>

<P><FONT SIZE=2>&gt;&nbsp; 026 3.4.4 sending SCON message from ASP to SG
indicating M3UA or ASP</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
congestion.</FONT> <BR><FONT SIZE=2>(snip)</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The only case, where the
SCON sent by the ASP seems</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; applicable, is when the AS is
geographically seperated</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the ASP and the ASP detects
overload towards the </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AS. In any case, I would propose
to relate the</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SCON to the AS (RC) rather than DPC.</FONT> </P>

<P><FONT SIZE=2>&quot;RC rather than DPC&quot; makes sense to me.</FONT>
<BR><FONT SIZE=2>i guess we can have new ASPTM Message, ASP Congestion,
rather than</FONT> <BR><FONT SIZE=2>SCON with RC.</FONT>
<BR><FONT SIZE=2>Does this make sense?</FONT> </P>

<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Kazuo Watanabe</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>
From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: future planning
Date: Thu, 24 May 2001 14:53:50 -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: future planning</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; DUA as well!</FONT> </P>

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

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

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Lyndon Ong [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>
] </FONT> <BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 24, 2001 1:45
PM</FONT> <BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; future
planning</FONT> </P>

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

<P><FONT SIZE=2>Just doing some future planning...</FONT> </P>

<P><FONT SIZE=2>We still have several items on our todo list:</FONT> </P>

<P><FONT SIZE=2>-- get M3UA out to IESG - as soon as the updated </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; version comes out, hopefully very soon</FONT>
</P>

<P><FONT SIZE=2>-- Last Call M2UA, M2PA, SUA and v5UA</FONT> </P>

<P><FONT SIZE=2>-- Last Call MIBs</FONT> </P>

<P><FONT SIZE=2>-- Last Call Signalling AS</FONT> </P>

<P><FONT SIZE=2>-- organize/document bakeoffs as needed</FONT> </P>

<P><FONT SIZE=2>I would like group feedback on whether any other items
</FONT> <BR><FONT SIZE=2>should be added to this list, as well as whether we
need</FONT> <BR><FONT SIZE=2>to hold a session in London.&nbsp; I've had one
informal </FONT> <BR><FONT SIZE=2>request for this already and am leaning
towards requesting</FONT> <BR><FONT SIZE=2>a slot, hopefully our
last.</FONT> </P>

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

<P><FONT SIZE=2>L. Ong</FONT>
</P>
<BR>

<P><FONT SIZE=2>Join 18 million Eudora users by signing up for a free Eudora
Web-Mail account at <A HREF="http://www.eudoramail.com"
TARGET="_blank">http://www.eudoramail.com</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: Thu, 24 May 2001 13:56:16 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: Significant Changes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      NAA13294
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-211.dallas.net [209.44.42.211]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

I would like to propose some significant changes to the M2PA draft.
Basically, these changes are itemized below.  I can provide you with
proposed text if they seem reasonable.

1.  Changes to when the SCTP association is established.

    The current specification has the SCTP association being
    established when the L3->L2 START primitive is issued.
    This makes assumptions about the underlying network which
    are not necessarily valid.  Setting up an SCTP association
    may require the reaquisition of DHCP lease times or the
    establishment of switched connections, slow lookups for
    priming caches in hosts and middle boxes, dialing to
    establish PPP connections, establishing SVCs over ATM,
    any number of things.  These can take time and delay the
    establishment of the SCTP association.

    On the other side, it seems excessive to disconnect an SCTP
    association just because the signalling link is out of
    service (not carrying traffic).

    I would like to propose that the SCTP association be
    established when the SS7 Signalling Link is configured for
    operation by MTP signalling link management.

    This means a bunch of text changes and the addition of an
    `out of service' status indication.  This also means the
    addition of an `align' status indication and an alignment
    phase so that both sides of the association can sychronize
    on placing the link back into service.  It will also require
    addition of a `ALIGNED' and `NOT ALIGNED' state and the
    addition of a number of timers.

2.  Addition of registration procedures

    I would also like to propose some registration procedures so
    that the SEPs on both ends of the link can determine
    identifiers for the signalling link as well as in support of
    the dynamic allocation of signalling data links (which makes
    a lot of sense for M2PA links don't require switching).

3.  Addition of a proving.

    The purpose of a proving period is to keep the MTP Level 3
    from thrashing back and forth doing changeovers from
    signalling links which are unable to carry traffic.  Proving
    is a way of damping this transient behavior.

    The current specification does not determine that the link
    is able to carry traffic before signalling in service to L3.
    This means that the link may fail (or congest) when placed
    under load.  Proving is essential to proper operation with
    L3.

    I would like to propose that a proving period which uses
    either DATA chunks or HEARTBEAT chunks to prove the
    connection be added to the specification.  I would also
    like to propose that a NORMAL and EMERGENCY proving period
    be provided for.  I can provide a procedure which will fit
    the bill if you would like.

    This means a bunch of text additions and the addition of a
    `PROVING' state.  Also, because emergency conditions is a
    local thing, it will require the addition of a `normal
    proving' and `emergency proving' staus indication so that
    both sides of the link can determine which procedure to use.
    It also means the addition of several timers.

4.  Multiple links per Association.

    It is possibly dangerous to have multiple links, each in
    their own association, where the assocations follow the same
    network paths.  All of these links will likely fail together
    and can cause all kinds of thrashing around of changeovers
    in MTP L3 due to the serialization of link-failure
    primitives.  The answer to this problem could be one BIG
    M2PA link per linkset, however, the independence of SLS
    streams withing the SS7 traffic would not be taken advantage
    of due to the single data stream in M2PA.

    I would like to propose that traffic be sent over multiple
    streams within the SCTP association.

    This means using truncated TSN rather than SSN for changeover
    and negotiating the number of streams upon SCTP association.

5.  Recommendations on SCTP protocol parameters.

    I would like to see recommendations on SCTP protocol
    parameters added to the draft in fitting with the alignment
    procedures as well as the data transfer phase.  These
    recommendations would be for compatability with MTP Level 3
    and not to assume some underlying network.
    
I can provide text for all of these changes if you are interested.

Comments?

-- 
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: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: M2PA: Multiple streams
Date: Thu, 24 May 2001 15:09:43 -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: M2PA: Multiple streams</TITLE> </HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
SIZE=2>From: &nbsp; Brian F. G. Bidulock [<A
HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Thursday, May 24, 2001 1:13 PM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> <BR><FONT
SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: M2PA: Multiple
streams</FONT> </P>

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

<P><FONT SIZE=2>Field trial and in-service are two different things.&nbsp;
Also,</FONT> <BR><FONT SIZE=2>I didn't mean that mixing should not be
permitted, just</FONT> <BR><FONT SIZE=2>that it has only temporary and
marginal use.</FONT> </P>

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

<P><FONT SIZE=2>[Greg] I understand this and agree (of course!).&nbsp;&nbsp;
I just wanted to point out that some operators are pretty serious about
using M2PA in their very-reliable SS7 networks and it is not up to us how
they roll it in.&nbsp; I'm sure these links will be in-service in a network
very shortly (I can't say any more than that!).&nbsp; There is plenty of
water to go under the bridge yet as M2PA is not quite there yet as a
standard but we are committed to make it happen.</FONT></P>

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

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

<P><FONT SIZE=2>On Thu, 24 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH]
wrote:</FONT> </P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Hi Brian, Jacob,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; I have already seen &quot;short term&quot;
operator requirements to allow mixing</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; of M2PA and MTP2 links in the same linkset in
their SS7 network,</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; although
the implicit understanding seems to be that this is temporary</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; to &quot;soak-in&quot; the new M2PA
links.&nbsp;&nbsp; There are certainly some technical</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; &quot;challenges&quot; to support this but I
don't think we can state that</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;
nobody will do this (although I personally prefer your approach</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; below).&nbsp; The same issue came up
with operators when they added</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; SAAL/ATM-based links into their SS7 networks,
with the same result -</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; allow
them to be mixed up (temporarily).</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Cheers,</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg Sidebottom</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]</FONT> <BR><FONT
SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 613 851-6725
(cell)</FONT> <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; </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>
From: Barry Nagelberg <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: future planning
Date: Thu, 24 May 2001 15:52:44 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Lyndon,

I think that it is not wise to issue a last call for any UA before its first
bakeoff (M2UA, M2PA, SUA and v5UA). Too many issues arise at the bakeoff to
make such a last call relevant. 

As for M3UA, we "baked off" only version 5. The updated version will be
version 7. I think that it would be wise to have another bakeoff before
sending it to IESG. 

Barry Nagelberg
Staff Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 1:45 PM
> To: sigtran
> Subject: future planning
> 
> 
> Folks,
> 
> Just doing some future planning...
> 
> We still have several items on our todo list:
> 
> -- get M3UA out to IESG - as soon as the updated 
>    version comes out, hopefully very soon
> 
> -- Last Call M2UA, M2PA, SUA and v5UA
> 
> -- Last Call MIBs
> 
> -- Last Call Signalling AS
> 
> -- organize/document bakeoffs as needed
> 
> I would like group feedback on whether any other items 
> should be added to this list, as well as whether we need
> to hold a session in London.  I've had one informal 
> request for this already and am leaning towards requesting
> a slot, hopefully our last.
> 
> Cheers,
> 
> L. Ong
> 
> 
> Join 18 million Eudora users by signing up for a free Eudora 
> Web-Mail account at http://www.eudoramail.com
> 
> 
> ---
> 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, 24 May 2001 17:23:30 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: ..._ENDED status
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      RAA17815
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.44.41.236]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

A little problem with the BUSY_ENDED and PROCESSOR_ENDED status indications
in M2PA.  I just so happens that a link in SS7 cannot normally be BUSY and
PROCSSOR_OUTAGE at the same time.  Therefore only a single status is
necessary to cancel either or both.  I suggest that the BUSY_ENDED and
PROCESSOR_OUTAGE_ENDED status be removed an that a reiteration of IN_SERVICE
be used to cancel these status indications.

Under this scheme BUSY would cancel PROCESSOR_OUTAGE, and PROCESSOR_OUTAGE
would cancel BUSY as well.  That way the mutual exclusivity of these states
can be preserved.

Otherwise we have the situation where a link is perceived to be
simultaneously BUSY and PROCESSOR_OUTAGE.  Depending on the implementation
MTP3 may interpret this as either BUSY or PROCESSOR_OUTAGE and two
implementation may not agree.  The difference is significant.

--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: Thu, 24 May 2001 18:13:09 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: Busy handling
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      SAA18296
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-236.dallas.net [209.44.41.236]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Re: draft-ietf-sigtran-m2pa-02.txt Section 4.1.4

As you know, this section states that when SCTP is in "receive congestion"
that the Busy status be sent to the peer. And that the peer start timer T6.
This does not correspond well to the handling of busy status in SS7 MTP
Level 2.  SS7 MTP Level 2 along with the Busy status will withold
acknowledgements when it can no longer accept frames.  SCTP wil do the same,
if the receive window drops to 0, it will stop acknowledging DATA chunks (I
believe).  (There is the problem that this may abort the association after a
time and cwnd to close, but that's a separate issue.)

The differences between M2PA and SS7 Level 2 appear on the side receiving
the Busy status.  A Q.703 link receiving busy will stop the T6 timer if it
has nothing to send.  No provision is made in M2PA that if all the
outstanding DATA chunks happen to be sent that T6 be stopped regardless of
the fact that the other end is in receive congestion.  There is no reason to
fail a link whose receiver is in a busy state when there happens to be
nothing more to send.

In addition, in Q.703, every time that the receiver of the Busy receives an
acknowlegment from the sender of the Busy, it stops timer T6.  That is, as
long as you are acknowledging things, the sender will re-enforce T7
acknowledgement timing.  This also cancels the entire busy status (until the
next SIB is sent).

M2PA has no parallel and the T6 timer is either too large to be of any use
or will fail the link in response to transient conditions.  The parallel to
this in SCTP lies in SCTP's response to a delayed acknowledgment.

In SS7, an (except when SIB is received) the first acknowledgement which is
later than T7 will fail the link.
Plain and simple.  When SIB is received, SS7 will give the other end the
credit of the doubt for time T6 (on each acknowledgement) before failing the
link.

In SCTP if an acknowledgement not received within t3-rtx (set to SRTT within
RTO.min and RTO.max) SCTP will give the sender twice as long to acknowledge
the second transmission (...and she told two friends, and she told two
friends...)  The only way to enforce an upper bound on acknowledgements in
SCTP is through tight control of RTO.max and Path.Max.Retrans and
Assoc.Max.Retrans.

So, say we set RTO.max and Path.Max.Retrans and Assoc.Max.Retrans down tight
enough that we get T7-like behaviour.  (Say, for a multi-homed host we set
Path.Max.Retrans to 2 and Assoc.Max.Retrans to 2 and RTO.max to 500ms.)
Then things are too brittle: we have the T7 capability but not the T6.
There is no way in SCTP to tell the peer to ease up on its t3-rtx because
your going to be a little longer acknowledging this one.)

The next problem is that, regarless of setting busy and an external T6 or
tweaking SCTP protocol parameters, SCTP will always treat a late
acknowledgement as congestion and slam down the congestion window.  This
might be good, because there really is congestion (of a sort) at the far
end; however, there is no way for the peer to say "ok, no problem, that was
me, i was gone for a moment, but i'm back now, you can send full rate again"
in
        the same manner as does Q.703.

Also, T6 accomodates a shift in delay at the other end of the link, not
necessarily a shift in throughput.  This confuses SCTP: it treats a shift in
delay of acknowledgements (or a shift in RTT, which includes processing
turn-around times) as congestion.  This means that on time-triggered
systems, if the receiver's task window gets moved forward, the sender will
perceive this as congestion.

SS7 detects congestion on the transmit side with buffer fill.
It does not treat busy as receiver congestion, it treats it as intentional
delay of acknowledgement.

So, all in all, I suppose what I'm getting at is that there is no need for
the BUSY procedure in M2PA.  SCTP will perform this as well as it can given
tweaked settings of RTO.max and Path.Max.Retrans and Assoc.Max.Retrans.
When rwnd falls (receive congestion) the sender will withold sending
somewhat and then the receiver will stop acking.  Eventually either the
association will fail or the transmit side will become congested and hit
congestive failure.

I propose that the BUSY and T6 and their procedures be removed from the M2PA
spec.

--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: Thu, 24 May 2001 18:35:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: Processor Outage Handling
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      SAA18375
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-236.dallas.net [209.44.41.236]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Re: draft-ietf-sigtran-m2pa-02.txt  Section 4.1.3 Processor Outage

Tom,

There are some serious problems with the processor outage procedures in
M2PA.  The problem is as follows:

> When M2PA detects a local processor outage, it sends a Link Status
> message to its peer with status Processor Outage.  M2PA shall discard
> any User Data received. ...

It will do WHAT????  No, no.  Bad idea.  Don't discard received user data
messages.  Keep them in M2PA's receive buffer in case the processor outage
recovers 2 ms from now.

What the peer with local processor outage should do (as Q.703) is stop
*acknowledging* messages; but, aside from artificially setting a_rwnd to 0,
there doesn't seem to be any way of telling SCTP to do this.

You see, once the receiver acknowledges the message at SCTP, it is struck
from the senders retransmission buffer and is no longer available for
retrieval at the sending side.  If you throw it on the floor, it will be
gone forever, _even_if_the_local_processor
_recovers_2_milliseconds_from_now.

Looking at what it should do, it should send the status as indicated (so the
peer can start a timer), but what is should be able to do is to tell the
SCTP peer to stop sending.  The peer M2UA, upon receiving the
PROCESSOR_OUTAGE could stop sending, but that doesn't stop SCTP from
sending.  There may be a good number of messages already in the SCTP send
buffers waiting to be sent.  Few implementations of SCTP is capable of
retreiving these packets already committed to send_msg().

The only suggestion I can give is for the M2UA experiencing LPO to ask it's
SCTP to set the rwnd to 0.  (Should be possible via queue locking or
setsockopt.) However, this causes difficulties with SCTP in that this
condition cannot persist for too long unless you just happen to have
HEARTBEAT intervals set just right.  It is still far better that discarding
messages or havinging them sent onwards and acknolwedged by SCTP so that a
later RB_CLEAR primitive from MTP3 destroys them.

Clear_buffers is a primitive which was added to Q.703/704 in 1988/90 specs
to accomodate the clearing of messages caught in the TB/RTB and RB buffers
after a prolonged processor outage.
Discarding these buffers prematurely was an implementation issue in SS7
which was resolved in the 1988/90 specs.  I don't see any need to recereate
it.

--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: Fri, 25 May 2001 07:32:16 +0200
From: Ian Rytina <[email-masked]>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: future planning
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Barry,

According to my understanding of RFC2026, it is perfectly ok (and in fact
common IETF practice) to go into Proposed Standard RFC before any interop
tests are done. I cannot see any reason for having another "bake-off" of
M3UA before going to the IESG.

/Ian.

Barry Nagelberg wrote:

> Lyndon,
>
> I think that it is not wise to issue a last call for any UA before its
first
> bakeoff (M2UA, M2PA, SUA and v5UA). Too many issues arise at the bakeoff
to
> make such a last call relevant.
>
> As for M3UA, we "baked off" only version 5. The updated version will be
> version 7. I think that it would be wise to have another bakeoff before
> sending it to IESG.
>
> Barry Nagelberg
> Staff Software Engineer
> RadiSys, Corp.
> Signaling Products Design Center
> [email-masked]
> +1-856-642-9229 x237
>
> > -----Original Message-----
> > From: Lyndon Ong [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 1:45 PM
> > To: sigtran
> > Subject: future planning
> >
> >
> > Folks,
> >
> > Just doing some future planning...
> >
> > We still have several items on our todo list:
> >
> > -- get M3UA out to IESG - as soon as the updated
> >    version comes out, hopefully very soon
> >
> > -- Last Call M2UA, M2PA, SUA and v5UA
> >
> > -- Last Call MIBs
> >
> > -- Last Call Signalling AS
> >
> > -- organize/document bakeoffs as needed
> >
> > I would like group feedback on whether any other items
> > should be added to this list, as well as whether we need
> > to hold a session in London.  I've had one informal
> > request for this already and am leaning towards requesting
> > a slot, hopefully our last.
> >
> > Cheers,
> >
> > L. Ong
> >
> >
> > Join 18 million Eudora users by signing up for a free Eudora
> > Web-Mail account at http://www.eudoramail.com
> >
> >
> > ---
> > 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: Fri, 25 May 2001 02:21:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
Subject: M3UA: Protocol Data 2
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      CAA26197
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]>

The spec says to check the pertinent standards for the format of Protocol
Data 2 information.  In the Protocol Data 2 parameter is the LI included per
Q.703 or per Q.703 Annex A?  What standard should I check to see what length
the LI field will be?  Every national and international standard has both a
short (6-bit) and extended (HSL) LI field.  This is usually determined by
the type of link and is not passed to MTP3 at all.  So how is it to be
formatted?

-- 
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]
Reply-To: [email-masked]
From: Mark Kobine <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: m2ua - interface identifier
Date: Fri, 25 May 2001 09:52:27 +0100
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-SMTP-HELO: blueyonder.co.uk
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: pcow028o.blueyonder.co.uk [195.188.53.124]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[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.2919.6307" name=GENERATOR> <STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Heinz,</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>We haven't had any problems&nbsp;modelling
Interface Identifiers - they fit in rather well in our system.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2>However&nbsp;I agree that perhaps&nbsp;they could be named
better.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Cheers,</FONT></DIV> <DIV><FONT face=Arial
size=2>Mark</FONT></DIV> <BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px;
PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A href="mailto:[email-masked]" 
  title=[email-masked]>Heinz Prantner</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:[email-masked]" 
  title=[email-masked]>sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> 17 May 2001 20:05</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> m2ua - interface
identifier</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>Dear M2ua's,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>we have some conflict in our data model with
the 
  term *interface identifier* and thus would like to ask 1) whether we are
the 
  only one? and (if so) 2) whether we could, should change the m2ua draft to
use 
  a different name. The problem is, it does not really identify an interface

  (the way the mib2 for example uses the term), but could mean a timeslot
within 
  a t1/e1 interface, or according to ITU Q.751 a Signaling Link Termination
or a 
  Signaling Link (the draft explicitly states that *interface* is used for
*SS7 
  Signaling Link* so why not using signaling link for signaling link?). The 
  problem with *identifier* is, it gets confused with the identifier's used
to 
  identify a&nbsp;interface within one system (e.g. a t1 interface id in a 
  signaling gateway) while the *interface identifier* enumerates accross
systems 
  and means something different. (Uff, even describing the confusion is 
  confusing). We would like to propose&nbsp;to use *Link Reference* 
  instead.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV>Until Ken comes back from vacation it would be interesting to get 
  response on question 1) above.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Thanks,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>Heinz Prantner</FONT></DIV>
  <DIV><FONT face=Arial size=2>System Architect Signaling
Technology</FONT></DIV>
  <DIV><FONT face=Arial size=2>RadiSys, Corp.<BR>Signaling Products Design 
  Center<BR><A 
 
href="mailto:[email-masked]">[email-masked]</A></FON
T></DIV>
  <DIV><FONT face=Arial size=2>+1-856-642-9229 
  x235</FONT></DIV></FONT></DIV></FONT></DIV></FONT></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: [email-masked]
To: "sigtran" <[email-masked]>
Subject: RE: Other bakeoffs was: M2UA bakeoff.
Date: Fri, 25 May 2001 15:06:34 +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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Brian,

> I was thinking of trying to so a SUA test at the next Megaco
> Interop Event, which would be September at University of
> New Hampshire.  While we wanted to try Megaco/SCTP-SUA combinations
> to support ISDN PRI gateways we could certainly expand to supporting
> just the SCTP-SUA standalone.

This would be great.  I'll second this!

John

---
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: Fri, 25 May 2001 09:06:13 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: m2ua - interface identifier
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]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Heinz,

I don't have a strong attachment to "Interface Identifier".  But, since it
has been in the draft for so long, it would be good to see some consensus
for a change.  Based on past requests, I know this is difficult because
sometimes few people respond to these emails.

So, please, if you have an opinion, respond to your preference for
"Interface Identifier", "Link Reference" or other term.

Ken

At 09:52 AM 5/25/01 +0100, Mark Kobine wrote:
>Heinz,
>  
>We haven't had any problems modelling Interface Identifiers - they fit in
rather well in our system.
>  
>However I agree that perhaps they could be named better.
>  
>Cheers,
>Mark
>>----- Original Message ----- 
>>From: <mailto:[email-masked]>Heinz Prantner 
>>To: <mailto:[email-masked]>sigtran 
>>Sent: 17 May 2001 20:05
>>Subject: m2ua - interface identifier
>>
>>Dear M2ua's,
>>  
>>we have some conflict in our data model with the term *interface
identifier* and thus would like to ask 1) whether we are the only one? and
(if so) 2) whether we could, should change the m2ua draft to use a different
name. The problem is, it does not really identify an interface (the way the
mib2 for example uses the term), but could mean a timeslot within a t1/e1
interface, or according to ITU Q.751 a Signaling Link Termination or a
Signaling Link (the draft explicitly states that *interface* is used for
*SS7 Signaling Link* so why not using signaling link for signaling link?).
The problem with *identifier* is, it gets confused with the identifier's
used to identify a interface within one system (e.g. a t1 interface id in a
signaling gateway) while the *interface identifier* enumerates accross
systems and means something different. (Uff, even describing the confusion
is confusing). We would like to propose to use *Link Reference* instead.
>>  
>>Until Ken comes back from vacation it would be interesting to get response
on question 1) above.
>>  
>>Thanks,
>>  
>>Heinz Prantner
>>System Architect Signaling Technology
>>RadiSys, Corp.
>>Signaling Products Design Center
>><mailto:[email-masked]>[email-masked]
>>+1-856-642-9229 x235
>>---
>>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: Fri, 25 May 2001 10:14:11 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: future planning
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I will release another M2PA around mid-June. I had hoped to release around
mid-May but I received another assignment to complete first. 

I most likely will not make the trip to London. Like many companies, we are
trying to cut back on travel expenses. But I think that M2PA business can be
resolved over the e-mail list.

Lyndon Ong wrote:
> 
> Folks,
> 
> Just doing some future planning...
> 
> We still have several items on our todo list:
> 
> -- get M3UA out to IESG - as soon as the updated
>    version comes out, hopefully very soon
> 
> -- Last Call M2UA, M2PA, SUA and v5UA
> 
> -- Last Call MIBs
> 
> -- Last Call Signalling AS
> 
> -- organize/document bakeoffs as needed
> 
> I would like group feedback on whether any other items
> should be added to this list, as well as whether we need
> to hold a session in London.  I've had one informal
> request for this already and am leaning towards requesting
> a slot, hopefully our last.
> 
> Cheers,
> 
> L. Ong

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Significant Changes
Date: Fri, 25 May 2001 13:14:33 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[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 background="" bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2>Brian, All,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT color=#0000ff
face=Arial size=2>see comments below...</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Heinz</FONT></DIV> <DIV><FONT
face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2><BR></FONT><FONT face=Arial size=2>----- Original Message -----
<BR>From: Brian F. G. Bidulock &lt;[email-masked]&gt;<BR>To: sigtran
&lt;[email-masked]&gt;<BR>Cc:
&lt;[email-masked]&gt;<BR>Sent: Thursday, May 24, 2001 1:56
PM<BR>Subject: M2PA: Significant
Changes<BR><BR><BR>&lt;snip&gt;</FONT></DIV> <DIV><FONT face=Arial
size=2><BR><BR>&nbsp;&nbsp;&nbsp; On the other side, it seems excessive to
disconnect an SCTP<BR>&nbsp;&nbsp;&nbsp; association just because the
signalling link is out of<BR>&nbsp;&nbsp;&nbsp; service (not carrying
traffic).<BR></DIV></FONT>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>[HP] Was'nt there a thread
to prevent SCTP from acknowledging&nbsp;</FONT></FONT></DIV> <DIV><FONT
face=Arial size=2><FONT color=#0000ff>messages? Could an Out of Service
message sent over an</FONT></FONT></DIV> <DIV><FONT color=#0000ff face=Arial
size=2>active association solve that?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><BR>&nbsp;&nbsp;&nbsp; I would like to propose
that the SCTP association be<BR>&nbsp;&nbsp;&nbsp; established when the SS7
Signalling Link is configured for<BR>&nbsp;&nbsp;&nbsp; operation by MTP
signalling link management.</FONT></DIV> <DIV><FONT face=Arial size=2>
<DIV>&nbsp;</DIV></DIV>
<DIV>&lt;snip&gt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>4.&nbsp; Multiple links per Association.<BR><BR>&nbsp;&nbsp;&nbsp; It
is possibly dangerous to have multiple links, each in<BR>&nbsp;&nbsp;&nbsp;
their own association, where the assocations follow the
same<BR>&nbsp;&nbsp;&nbsp; network paths.&nbsp; All of these links will
likely fail together<BR>&nbsp;&nbsp;&nbsp; and can cause all kinds of
thrashing around of changeovers<BR>&nbsp;&nbsp;&nbsp; in MTP L3 due to the
serialization of link-failure<BR>&nbsp;&nbsp;&nbsp; primitives.&nbsp; The
answer to this problem could be one BIG<BR>&nbsp;&nbsp;&nbsp; M2PA link per
linkset, however, the independence of SLS<BR>&nbsp;&nbsp;&nbsp; streams
withing the SS7 traffic would not be taken advantage<BR>&nbsp;&nbsp;&nbsp;
of due to the single data stream in M2PA.<BR><BR>&nbsp;&nbsp;&nbsp; I would
like to propose that traffic be sent over multiple<BR>&nbsp;&nbsp;&nbsp;
streams within the SCTP association.<BR><BR>&nbsp;&nbsp;&nbsp; This means
using truncated TSN rather than SSN for changeover<BR>&nbsp;&nbsp;&nbsp; and
negotiating the number of streams upon SCTP association.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial
size=2><FONT color=#0000ff>[HP] I like the idea of having multiple streams
rather than multiple associations.</FONT></FONT></DIV> <DIV><FONT face=Arial
size=2><FONT color=#0000ff>The multiple association mode came up because of
retrieval, right? I could not find</FONT></FONT></DIV> <DIV><FONT face=Arial
size=2><FONT color=#0000ff>in the archives and have forgotten the reason why
we have to have multiple associations</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>to support retrieval. Can
someone help me to understand? I do not understand</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>neither why the SSN
(together with Link Code of Chaneover message) is not</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>good enough for retrieval
and we need a truncated TSN instead. Can you explain?</FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2>Are you planning to retrieve
messages for the whole linkset at once?</FONT></DIV> <DIV><FONT face=Arial
size=2><BR><BR>5.&nbsp; Recommendations on SCTP protocol
parameters.<BR><BR>&nbsp;&nbsp;&nbsp; I would like to see recommendations on
SCTP protocol<BR>&nbsp;&nbsp;&nbsp; parameters added to the draft in fitting
with the alignment<BR>&nbsp;&nbsp;&nbsp; procedures as well as the data
transfer phase.&nbsp; These<BR>&nbsp;&nbsp;&nbsp; recommendations would be
for compatability with MTP Level 3<BR>&nbsp;&nbsp;&nbsp; and not to assume
some underlying network.<BR></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>[HP] That one I found in
the archives has been proposed&nbsp;and denied. see message from Jan
Rytina</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT color=#0000ff>from Nov 22 2000 ==&gt; <A
href="http://www17.nortelnetworks.com/scripts/wa.exe?A2=ind0011&amp;L=SIGTRA
N&amp;P=R39815">http://www17.nortelnetworks.com/scripts/wa.exe?A2=ind0011&am
p;L=SIGTRAN&amp;P=R39815</A></FONT></FONT></DIV> <DIV><FONT face=Arial
size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;
<BR>I can provide text for all of these changes if you
are<BR>interested.<BR><BR>Comments?<BR><BR><BR>-- <BR>Brian F. G.
Bidulock&nbsp;&nbsp;&nbsp; ¦ The reasonable man adapts himself to the
¦<BR>[email-masked]&nbsp;&nbsp;&nbsp; ¦ world; the unreasonable one
persists in&nbsp; ¦<BR>http://www.openss7.org/ ¦ trying&nbsp; to adapt
the&nbsp; world&nbsp; to himself. 
¦<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
Therefore&nbsp; all&nbsp; progress&nbsp; depends on the
¦<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ¦
unreasonable man. -- George Bernard Shaw ¦<BR><BR><BR>---<BR>You are
currently subscribed to sigtran as: [email-masked]<BR>To
unsubscribe send a blank email to 
[email-masked]</FONT></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>
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Multiple streams
Date: Fri, 25 May 2001 13:14:41 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: M2PA: Multiple streams</TITLE> <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>Greg, Brian, All</FONT></DIV> <DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>just curious: They (network operators) do mix
high speed links with normal (low speed) links in the same linkset (combined
linkset) ???</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Heinz</FONT></DIV> <BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px;
PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:
black"><B>From:</B> 
  <A href="mailto:[email-masked]" 
  title=[email-masked]>Sidebottom, Greg [BCNR:7M01:EXCH]</A>
</DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:[email-masked]" 
  title=[email-masked]>sigtran</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, May 24, 2001 2:09
PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: M2PA: Multiple
streams</DIV>
  <DIV><BR></DIV><BR><BR>
  <P><FONT size=2>&nbsp;-----Original Message-----</FONT> <BR><FONT
size=2>From: 
  &nbsp; Brian F. G. Bidulock [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent:&nbsp;&nbsp; Thursday, May 24, 2001 1:13 
  PM</FONT> <BR><FONT size=2>To:&nbsp;&nbsp;&nbsp;&nbsp; sigtran</FONT> 
  <BR><FONT size=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re:
M2PA: 
  Multiple streams</FONT> </P>
  <P><FONT size=2>Greg,</FONT> </P>
  <P><FONT size=2>Field trial and in-service are two different things.&nbsp;

  Also,</FONT> <BR><FONT size=2>I didn't mean that mixing should not be 
  permitted, just</FONT> <BR><FONT size=2>that it has only temporary and 
  marginal use.</FONT> </P>
  <P><FONT size=2>--Brian</FONT> </P>
  <P><FONT size=2>[Greg] I understand this and agree (of
course!).&nbsp;&nbsp; I 
  just wanted to point out that some operators are pretty serious about
using 
  M2PA in their very-reliable SS7 networks and it is not up to us how they
roll 
  it in.&nbsp; I'm sure these links will be in-service in a network very
shortly 
  (I can't say any more than that!).&nbsp; There is plenty of water to go
under 
  the bridge yet as M2PA is not quite there yet as a standard but we are 
  committed to make it happen.</FONT></P>
  <P><FONT size=2>Cheers,</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; Greg</FONT> </P><BR><BR><BR>
  <P><FONT size=2>On Thu, 24 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH] 
  wrote:</FONT> </P>
  <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; Hi
Brian, 
  Jacob,</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; I have already seen "short term" operator 
  requirements to allow mixing</FONT> <BR><FONT
size=2>&gt;&nbsp;&nbsp;&nbsp; of 
  M2PA and MTP2 links in the same linkset in their SS7 network,</FONT>
<BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; although the implicit understanding seems to
be 
  that this is temporary</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; to 
  "soak-in" the new M2PA links.&nbsp;&nbsp; There are certainly some 
  technical</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; "challenges" to 
  support this but I don't think we can state that</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; nobody will do this (although I personally 
  prefer your approach</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
  below).&nbsp; The same issue came up with operators when they added</FONT>

  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; SAAL/ATM-based links into their
SS7 
  networks, with the same result -</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; allow them to be mixed up
(temporarily).</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; Cheers,</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Greg Sidebottom</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  [email-masked]</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 613 851-6725
(cell)</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; </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] </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>
Sender: [email-masked]
Date: Fri, 25 May 2001 13:37:33 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Multiple streams
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Multiple links in a link set are also used for redundancy. 

SS7 only allows one link set between two nodes. If the link set is an SCTP
association and for some reason the association is lost, then you lose the
link set and thus lose communication between the two nodes. 

As Jacob pointed out, to do changeover there has to be one data stream in
the association. The only way around that is to change the format of the
XCO/XCA messages. I took it as a given that we could not do that.

tomG.

"Brian F. G. Bidulock" wrote:
> 
> Tom,
> 
> re: draft-ietf-sigtran-m2pa-02.txt
> 
> Why not have multiple streams per M2PA SCTP association?
> 
> Say, place one link (SLC) on each of 16 or 32 streams numbered
> 1 through 16 (or 32).  Use a single stream 0 status channel.
> (All links are either in service, busy, not busy, processor
> outage, or not processor outage at the same time anyway).
> 
> Multiple links in a linkset are only really used in the SS7
> network for capacity sizing of a linkset: something which does
> not apply to M2PA in the same way as fixed bandwidth circuit
> connections.

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 25 May 2001 13:40:44 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA: Multiple streams
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      NAA02736
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]>
List-Unsubscribe: <mailto:[email-masked]>

Heinz,

HSL had two major uses and the use of M2PA could likely parallel this:
        
        1)  As a kind of "bandwidth on demand" link between
            the carrier and an interconnect where the interconnect
            wished to pay usage rather than fixed capacity as was
            all that was available with low speed A-links.

        2)  To provide much higher capacity that was attainable
            with the maximum number of low speed links which could
            be provisioned in a single linkset.

Neither of these uses is ammeniable to mixing of high speed links with low
speed links.

Perhaps Kevin can comment as to whether he sees a use for mixing.

--Brian

On Fri, 25 May 2001, Heinz Prantner wrote:

> 
>    Greg, Brian, All
>    
>    
>    
>    just curious: They (network operators) do mix high speed links with
>    normal (low speed) links in the same linkset (combined linkset) ???
>    
>    
>    
>    Heinz
>    

-- 
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]
Sender: [email-masked]
Date: Fri, 25 May 2001 11:49:47 -0700
From: Jacob Heitz <[email-masked]>
Organization: Lucent Technologies, Internetworking Systems, Software 
              Engineering, Alameda
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 i86pc)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: [Fwd: Re: M2PA: Multiple streams]
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]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

MTP3 inerprets link congestion to mean linkset congestion, so if one link
becomes congested, the whole linkset is seen as congested, even though other
links are ok. So, it is important to balance the links within a linkset.

-------- Original Message --------
     Subject: Re: M2PA: Multiple streams
        Date: Fri, 25 May 2001 13:14:41 -0500
        From: Heinz Prantner <[email-masked]>
    Reply-To: [email-masked] Organization: RadiSys
Corp.
          To: sigtran <[email-masked]>

Greg, Brian, All just curious: They (network operators) do mix high speed
links with normal (low speed) links in the same linkset (combined linkset)
??? Heinz

     ----- Original Message -----
     From: Sidebottom, Greg [BCNR:7M01:EXCH]
     To: sigtran
     Sent: Thursday, May 24, 2001 2:09 PM
     Subject: RE: M2PA: Multiple streams

      -----Original Message-----
     From:   Brian F. G. Bidulock [mailto:[email-masked]]
     Sent:   Thursday, May 24, 2001 1:13 PM
     To:     sigtran
     Subject:        Re: M2PA: Multiple streams

     Greg,

     Field trial and in-service are two different things.  Also,
     I didn't mean that mixing should not be permitted, just
     that it has only temporary and marginal use.

     --Brian

     [Greg] I understand this and agree (of course!).   I just wanted to
point out that some operators are pretty serious about using M2PA in their
very-reliable SS7 networks and it is not up to us how they roll it in.  I'm
sure these links will be in-service in a network very shortly (I can't say
any more than that!).  There is plenty of water to go under the bridge yet
as M2PA is not quite there yet as a standard but we are committed to make it
happen.

     Cheers,

        Greg

     On Thu, 24 May 2001, Sidebottom, Greg [BCNR:7M01:EXCH] wrote:

     >
     >    Hi Brian, Jacob,
     >
     >    I have already seen "short term" operator requirements to allow
mixing
     >    of M2PA and MTP2 links in the same linkset in their SS7 network,
     >    although the implicit understanding seems to be that this is
temporary
     >    to "soak-in" the new M2PA links.   There are certainly some
technical
     >    "challenges" to support this but I don't think we can state that
     >    nobody will do this (although I personally prefer your approach
     >    below).  The same issue came up with operators when they added
     >    SAAL/ATM-based links into their SS7 networks, with the same result
-
     >    allow them to be mixed up (temporarily).
     >
     >    Cheers,
     >
     >       Greg Sidebottom
     >       [email-masked]
     >       +1 613 851-6725 (cell)
     >

     --
     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: Fri, 25 May 2001 14:02:55 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Multiple streams
Reply-To: [email-masked]
Mail-Followup-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 
                      OAA03155
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]>
List-Unsubscribe: <mailto:[email-masked]>

On Fri, 25 May 2001, Tom George wrote:

> Multiple links in a link set are also used for redundancy. 
> 
Typically space redudancy is provided by the underlying carrier system
(self-healing) and is no longer used for individual links.  The
channelization costs are to great.

> SS7 only allows one link set between two nodes. If the link set is an
> SCTP association and for some reason the association is lost, then you
> lose the link set and thus lose communication between the two nodes. 
> 
That's what combined link sets are for.

> As Jacob pointed out, to do changeover there has to be one data stream
> in the association. The only way around that is to change the format of
> the XCO/XCA messages. I took it as a given that we could not do that.
> 
There is no need to change the XCO/XCA if you use TSN instead of SSN.
Truncating TSN to the least significant 24 bits for the XCO/XCA will work
fine.

-- 
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: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M2PA: Multiple streams
Date: Fri, 25 May 2001 15:05:55 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Hi Heinz, Brian ...

As Brian notes, there is no real "steady state" driver for mixing high and
low speed links in a linkset.  I have seen it happen when an operator adds
new High speed links, but as soon as the operator is comfortable that the
new-fangled high-speed links are operating with sufficient reliability, the
low speed links are made to disappear.  

I think the possibility of mixing is mentioned in passing in the Telcordia
GR-2878 HSL document because it has an impact on the aggregation of link
measurements for a link set (i.e., the high and low-speed link measurements
should be kept separate).   But I don't think it is recommended.

Cheers,

   Greg

 -----Original Message-----
From: 	Brian F. G. Bidulock [mailto:[email-masked]] Sent:
Friday, May 25, 2001 2:41 PM
To:	sigtran
Cc:	[email-masked]
Subject:	Re: M2PA: Multiple streams

Heinz,

HSL had two major uses and the use of M2PA could likely parallel this:
        
        1)  As a kind of "bandwidth on demand" link between
            the carrier and an interconnect where the interconnect
            wished to pay usage rather than fixed capacity as was
            all that was available with low speed A-links.

        2)  To provide much higher capacity that was attainable
            with the maximum number of low speed links which could
            be provisioned in a single linkset.

Neither of these uses is ammeniable to mixing of high speed links with low
speed links.

Perhaps Kevin can comment as to whether he sees a use for mixing.

--Brian

On Fri, 25 May 2001, Heinz Prantner wrote:

> 
>    Greg, Brian, All
>    
>    
>    
>    just curious: They (network operators) do mix high speed links with
>    normal (low speed) links in the same linkset (combined linkset) ???
>    
>    
>    
>    Heinz
>    

-- 
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]
Date: Fri, 25 May 2001 14:15:00 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA: Significant Changes
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA03391
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]>
List-Unsubscribe: <mailto:[email-masked]>

Heinz,

On Fri, 25 May 2001, Heinz Prantner wrote:
>    
>    [HP] Was'nt there a thread to prevent SCTP from
>    acknowledging messages? Could an Out of Service message
>    sent over an active association solve that?

I see your point.  Again, it may be necessary to do something like drop the
arwnd to 0 before sending out of service.

The only other solution that I see, aside from changing SCTP, is to put the
FSN/BSN back in the message.  This would solve a lot of other problems as
well.

>    
>    [HP] I like the idea of having multiple streams rather than
>    multiple associations.  The multiple association mode came
>    up because of retrieval, right? I could not find in the
>    archives and have forgotten the reason why we have to have
>    multiple associations to support retrieval. Can someone
>    help me to understand? I do not understand neither why the
>    SSN (together with Link Code of Chaneover message) is not
>    good enough for retrieval and we need a truncated TSN
>    instead. Can you explain?
>    
>    Are you planning to retrieve messages for the whole linkset
>    at once?
>    
Yes.  Although the separate SLSs are placed into individual streams, the
association will still to be treated as one link.
Multiple links which succeed and fail together could place too heavy a
transient on the MTP3 implementation (32 out of service messages, 32 bsnt
retrievals and 32 buffer retrievals, 32 changeover messages, etc.).  An MTP3
implementation which views them as separate links will also attempt link
changeover between links even though we know that the other links in the
association would be dead anyway.

>    [HP] That one I found in the archives has been proposed and denied.
>    see message from Jan Rytina
>    
The objection was ridiculous.  M2PA will not work over the Big I today.
Nevertheless, what I was proposing was recommended values which allow M2PA
to work with MTP3, not presuming an underlying network.  If the values
necessary to work with MTP3 do not happen to be acheivable on today's
Internet, so what?  It will catch up later...

-- 
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]
Sender: [email-masked]
Date: Fri, 25 May 2001 14:17:18 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
CC: [email-masked]
Subject: Re: M2PA: Significant Changes
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]
To: "sigtran" <[email-masked]>

Comments below....

"Brian F. G. Bidulock" wrote:
> 
> Tom,
> 
> I would like to propose some significant changes to the M2PA
> draft.  Basically, these changes are itemized below.  I can
> provide you with proposed text if they seem reasonable.
> 
> 1.  Changes to when the SCTP association is established.
  [...] 
>     I would like to propose that the SCTP association be
>     established when the SS7 Signalling Link is configured for
>     operation by MTP signalling link management.
  [...]

This might be a good idea.  

The only possible problems I see:

a. Are there any security risks with leaving an association up when the
upper layer does not need it?

b. Is it a burden to the network to keep up associations that are not being
used?

I think the answer is 'no' to both, but I am not sure.

> 2.  Addition of registration procedures
  [...]

Could you give some more explanation about this? Offhand, I don't see the
purpose of it.

> 3.  Addition of a proving.
  [...]
>     I would like to propose that a proving period which uses
>     either DATA chunks or HEARTBEAT chunks to prove the
>     connection be added to the specification.  I would also
>     like to propose that a NORMAL and EMERGENCY proving period
>     be provided for.  I can provide a procedure which will fit
>     the bill if you would like.
  [...]

The next version of the M2PA draft will have a proving procedure in it.
(I've already written it.) It uses another type of Link Status message.
The procedure does not distinguish between normal and emergency, though. 

And if I do Change #1 it will probably have some effect on the proving text
I have written.

If you already have text written up for this, I would be interested in
seeing it. Otherwise, you might want to wait until the next version and see
how close it comes to what you had in mind.

> 4.  Multiple links per Association.
  [...]
>     I would like to propose that traffic be sent over multiple
>     streams within the SCTP association.
  [...]

You can take a look at my comment in the other thread about this. 

Although we can't control how everyone sets up their network, it would be
unwise to have all the associations between two IPSPs going over the same
physical path. 

> 5.  Recommendations on SCTP protocol parameters.
> 
>     I would like to see recommendations on SCTP protocol
>     parameters added to the draft in fitting with the alignment
>     procedures as well as the data transfer phase.  These
>     recommendations would be for compatability with MTP Level 3
>     and not to assume some underlying network.

This sounds like a good idea, since it is based on MTP3 and not the
underlying network.

> 
> I can provide text for all of these changes if you are
> interested.

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 25 May 2001 14:21:23 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA03521
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]
List-Unsubscribe: <mailto:[email-masked]>

Jacob,

This is neither here nor there.  SS7 links are engineered to not congest.
Only extreme network failure conditions can cause congestion.

On Fri, 25 May 2001, Jacob Heitz wrote:

> MTP3 inerprets link congestion to mean linkset congestion, so if one link
> becomes congested, the whole linkset is seen as congested, even though
> other links are ok. So, it is important to balance the links within a
linkset.

-- 
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: Fri, 25 May 2001 14:32:05 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
X-MIME-Autoconverted: from 8bit to quoted-printable by netmail.alcatel.com
id 
                      OAA15243
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

But the point is, they DO congest and it is unacceptable not to have
congestion procedures running 24-7, if that's your implication.

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Jacob,
> 
> This is neither here nor there.  SS7 links are engineered to
> not congest.  Only extreme network failure conditions can
> cause congestion.
> 
> On Fri, 25 May 2001, Jacob Heitz wrote:
> 
> > MTP3 inerprets link congestion to mean linkset congestion, so if one
link
> > becomes congested, the whole linkset is seen as congested, even though
> > other links are ok. So, it is important to balance the links within a
linkset.
> >
> 
> --
> 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]
Date: Fri, 25 May 2001 14:36:37 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: M2PA: Significant Changes
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], sigtran 
                  <[email-masked]>, 
                  [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 
                      OAA03790
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]>

Tom,

Comments below comments...

Tom George wrote:                            (Fri, 25 May 2001 14:17:18)
> Comments below....
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Tom,
> > 
> > I would like to propose some significant changes to the M2PA
> > draft.  Basically, these changes are itemized below.  I can
> > provide you with proposed text if they seem reasonable.
> > 
> > 1.  Changes to when the SCTP association is established.
>   [...] 
> >     I would like to propose that the SCTP association be
> >     established when the SS7 Signalling Link is configured for
> >     operation by MTP signalling link management.
>   [...]
> 
> This might be a good idea.  
> 
> The only possible problems I see:
> 
> a. Are there any security risks with leaving an association up when the
> upper layer does not need it?
> 
> b. Is it a burden to the network to keep up associations that are not
> being used?
> 
> I think the answer is 'no' to both, but I am not sure.
> 
Who said that the associations weren't going to be used?  I just think that
dropping them between alignment procedures is fruitless.
An when the SEP reboots, signalling link management should bring the
associations up, rather than waiting for a START command (which is a little
late in the reboot cycle).

For dynamic allocation of signalling data links, signalling link management
can use the L1 CONNECT command provided for in MTP to form the association
when it is needed (at allocation time).

So the answer to both is `no' and `no'.  The associations are not `left up'
when then are not needed.  When they are needed is just determined by
signalling link management rather than attempting to form them on demand
when emergency traffic may need to be routed.

> 
> > 2.  Addition of registration procedures
>   [...]
> 
> Could you give some more explanation about this? Offhand, I don't see
> the purpose of it.

The purpose is to establish Signalling Data Link Identifiers for M2PA links
for use by signalling link management in the automatic allocation of
signalling data links.

> 
> 
> > 3.  Addition of a proving.
>   [...]
> >     I would like to propose that a proving period which uses
> >     either DATA chunks or HEARTBEAT chunks to prove the
> >     connection be added to the specification.  I would also
> >     like to propose that a NORMAL and EMERGENCY proving period
> >     be provided for.  I can provide a procedure which will fit
> >     the bill if you would like.
>   [...]
> 
> The next version of the M2PA draft will have a proving procedure in it.
> (I've already written it.) It uses another type of Link Status message.
> The procedure does not distinguish between normal and emergency, though. 
> 
> And if I do Change #1 it will probably have some effect on the proving
> text I have written.
> 
> If you already have text written up for this, I would be interested in
> seeing it. Otherwise, you might want to wait until the next version and
> see how close it comes to what you had in mind.

I don't already have text, I already have code.

> 
> 
> > 4.  Multiple links per Association.
>   [...]
> >     I would like to propose that traffic be sent over multiple
> >     streams within the SCTP association.
>   [...]
> 
> You can take a look at my comment in the other thread about this. 
> 
> Although we can't control how everyone sets up their network, it would
> be unwise to have all the associations between two IPSPs going over the
> same physical path. 

This is what SCTP multihoming is for.  Why reinvent the wheel by forcing
multiple associations to be provisioned according to their network paths???
Handle the redundancy once in SCTP provisioning!

> 
> 
> > 5.  Recommendations on SCTP protocol parameters.
> > 
> >     I would like to see recommendations on SCTP protocol
> >     parameters added to the draft in fitting with the alignment
> >     procedures as well as the data transfer phase.  These
> >     recommendations would be for compatability with MTP Level 3
> >     and not to assume some underlying network.
> 
> This sounds like a good idea, since it is based on MTP3 and not the
> underlying network.

On second thought, now that Heinz pointed out the last discussion, it would
be ok if M2PA has an AS which includes this...

-- 
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: Fri, 25 May 2001 14:54:56 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      OAA03991
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]>

Jeff,

That was not my implication.  What I am saying is that it makes no never
mind that links in a linkset have different capacities, they must be
engineered not to congest.

When congestion occurs, it is congestion of the entire linkset "by design".
The problem is cannot be one of misbalancing, because link sets are
engineered to not congest when a link fails.  This is not a reason not to
mix the two.  Links of differing capacities can still be traffic engineered
to not congest under peak traffic loads and in the face of link failure.

On Fri, 25 May 2001, Jeff Copley wrote:

> But the point is, they DO congest and it is unacceptable not to have
> congestion procedures running 24-7, if that's your implication.
> 
> Jeff
> 
> "Brian F. G. Bidulock" wrote:
> > 
> > Jacob,
> > 
> > This is neither here nor there.  SS7 links are engineered to
> > not congest.  Only extreme network failure conditions can
> > cause congestion.
> > 
> > On Fri, 25 May 2001, Jacob Heitz wrote:
> > 
> > > MTP3 inerprets link congestion to mean linkset congestion, so if one
link
> > > becomes congested, the whole linkset is seen as congested, even though
> > > other links are ok. So, it is important to balance the links within a
linkset.
> > >
> > 
> > --
> > 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    ¦ 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: Fri, 25 May 2001 15:16:58 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: M2PA: Acknowledgement Problem
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      PAA04453
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]>

Tom,

This is a separate note to attempt to address the acknowledgment problem in
M2PA.  This problem occurs whenever M2PA attempts to give one of the
following indications:

        Out of Service
        Busy
        Processor Outage

In the case of SS7 (SIOS, SIB, SIPO), the signalling link stops
acknowledging received frames.  In the case of M2PA, SCTP continues
acknowledging DATA chunks after these indications are sent.  This has the
problem of clearing the MSUs from the sender's transmission and
retransmission buffers and making them unavailable for retrieval should the
link fail as a result of any of these indications (it always fails for "Out
of Service").

This increases message loss due to failure.  At the SS7 link level, SS7
links DO NOT ACKNOWLEDGE MSUs UNTIL THEY ARE SUCCESSFULLY DELIVERABLE TO MTP
LEVEL 3!

(Please excuse the caps.)

What is required for M2PA to bring message loss back down to acceptable
levels is for M2PA to have a way of controlling when MSUs are acknowledged
to the peer.  There are two ways of doing this:

        1)  Alter SCTP-ULP interaction to permit M2PA to tell
            SCTP when to acknowledge DATA chunks and when not
            to.

        2)  Put sequence numbers and acknolwedgement in the DATA
            chunks with the MSUs themselves (i.e. put FSN/BSN in
            the frame).
            
I prefer solution #2, because it will probably be a cold day before SCTP
gets changed.

This is also a problem for M2UA.

-- 
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]
Sender: [email-masked]
Date: Fri, 25 May 2001 15:41:59 -0500
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Significant Changes
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]

"Brian F. G. Bidulock" wrote:
  [...]
> 4.  Multiple links per Association.
> 
>     It is possibly dangerous to have multiple links, each in
>     their own association, where the assocations follow the same
>     network paths.  All of these links will likely fail together
>     and can cause all kinds of thrashing around of changeovers
>     in MTP L3 due to the serialization of link-failure
>     primitives.  The answer to this problem could be one BIG
>     M2PA link per linkset, however, the independence of SLS
>     streams withing the SS7 traffic would not be taken advantage
>     of due to the single data stream in M2PA.
> 
>     I would like to propose that traffic be sent over multiple
>     streams within the SCTP association.
> 
>     This means using truncated TSN rather than SSN for changeover
>     and negotiating the number of streams upon SCTP association.
  [...]

More questions about this:

1. If you just have one association between the endpoints, would not the
capacity of that link set be limited to the capacity of that one
association?

2. I see problems with using TSNs for the changeover. 

a. You have to filter out the Link Status messages when you do the data
retrieval, since you don't want to retransmit them on the alternate link.

b. Suppose that a message is lost. Subsequent messages on other streams will
be delivered to the upper layer (M2PA). Now something happens that causes a
changeover. If you start retrieving data from the first gap in the TSNs, you
will retransmit those messages on the other streams that had already been
delivered to the upper layer M2PA. 

-- 
* Tom George        972-519-3168         [email-masked]   * *
PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  * *
Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   * * I
actively disclaim speaking for Alcatel USA, Inc. I do not purport * * to
advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
Date: Fri, 25 May 2001 16:06:28 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: M2PA: Significant Changes
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      QAA05270
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]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

Comments below...

On Fri, 25 May 2001, Tom George wrote:

> "Brian F. G. Bidulock" wrote:
>   [...]
> > 4.  Multiple links per Association.
> > 
> >     It is possibly dangerous to have multiple links, each in
> >     their own association, where the assocations follow the same
> >     network paths.  All of these links will likely fail together
> >     and can cause all kinds of thrashing around of changeovers
> >     in MTP L3 due to the serialization of link-failure
> >     primitives.  The answer to this problem could be one BIG
> >     M2PA link per linkset, however, the independence of SLS
> >     streams withing the SS7 traffic would not be taken advantage
> >     of due to the single data stream in M2PA.
> > 
> >     I would like to propose that traffic be sent over multiple
> >     streams within the SCTP association.
> > 
> >     This means using truncated TSN rather than SSN for changeover
> >     and negotiating the number of streams upon SCTP association.
>   [...]
> 
> More questions about this:
> 
> 1. If you just have one association between the endpoints, would not the
> capacity of that link set be limited to the capacity of that one
> association?

Yes; but the capacity of an SCTP association is unlimited (well, only
limited by the underlying network, which must be engineered anyway) so, so
what?  Using the link as a chunk of provisioning capacity is only applicable
to fixed bandwidth facilities such as circuits.

> 
> 2. I see problems with using TSNs for the changeover. 
> 
> a. You have to filter out the Link Status messages when you do the data
> retrieval, since you don't want to retransmit them on the alternate
> link.

Well... no you don't.  The algorithm to have the side receiving the
truncated TSN in the XCO is simple: just treat it as the first TSN in the
buffer earlier or at that provided in the XCO.  The algorithm at the sending
side is just a simple, skip advancing the TSN version of BSNT for status
messages, just advance it for MSUs.  It just needs to be monotonically
increasing, no worry if it skips a few.

> 
> b. Suppose that a message is lost. Subsequent messages on other streams
> will be delivered to the upper layer (M2PA). Now something happens that
> causes a changeover. If you start retrieving data from the first gap in
> the TSNs, you will retransmit those messages on the other streams that
> had already been delivered to the upper layer M2PA. 
> 

The SCTP transmitter cannot strike the GAP ACKed messages from the
retransmission buffer because the SCTP receiver can reneg on the GAP.
These must be retrieved on association failure because the sending M2PA
cannot tell whether the receiving M2PA would have reneged on these in the
future.  Because they must be retrieved, the way to avoid duplication is to
have the receiving M2PA NOT deliver these message to MTP3 until the
cumulative ack point passes them.  SCTP will ensure that the messages do not
have to be retransmitted if not necessary and they will be struck from
SCTP's receive window, but they must be held by M2PA in the event of
failure.  After all, they are not fully acknowedged messages, due to the
renegging difficulty.

-- 
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: Fri, 25 May 2001 17:09:17 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Acknowledgement Problem
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], 
                  [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 
                      RAA06141
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]>
List-Unsubscribe: <mailto:[email-masked]>

Tom,

Actually, there is a sneaky way of getting SCTP to deal with this if one has
control of the SCTP implementation.  That is to GAP ACK TSNs which have not
yet been accepted by the ULP.
Something like this:

        SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48

to acknowledge receipt of TSN 48 so that it gets struck from bytes in flight
but is held by the transmitter in case we reneg or the association aborts.

The next ones might look like:
        
        SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48
        SACK:    Cummulative TSN = 47, GAP ACK = 48 to 50
        SACK:    Cummulative TSN = 47, GAP ACK = 48 to 52

then, when 48 through 51 have been accepted by ULP:

        SACK:    Cummulative TSN = 51, GAP ACK = 52 to 52
        SACK:    Cummulative TSN = 51, GAP ACK = 52 to 54

If this can be done, then all that M2PA would have to do before sending
status Busy or Processor outage is stop servicing SCTP's read queue for
streams 1 through N.  M2PA would simply use the TSN of the last received MSU
(truncated) in the changeover message.

This would not impede SCTP's RTT calculations or be as drastic as
artificially dropping rwnd to 0.  I don't know how an existing
implementation will take to having a GAP ACK thrown at it that doesn't have
any real gaps.

--Brian

Brian F. G. Bidulock wrote:                 (Fri, 25 May 2001 15:16:58)
> Tom,
> 
> This is a separate note to attempt to address the acknowledgment
> problem in M2PA.  This problem occurs whenever M2PA attempts to
> give one of the following indications:
> 
>         Out of Service
>         Busy
>         Processor Outage
> 
> In the case of SS7 (SIOS, SIB, SIPO), the signalling link stops
> acknowledging received frames.  In the case of M2PA, SCTP
> continues acknowledging DATA chunks after these indications are
> sent.  This has the problem of clearing the MSUs from the sender's
> transmission and retransmission buffers and making them
> unavailable for retrieval should the link fail as a result of
> any of these indications (it always fails for "Out of Service").
> 
> This increases message loss due to failure.  At the SS7 link
> level, SS7 links DO NOT ACKNOWLEDGE MSUs UNTIL THEY ARE
> SUCCESSFULLY DELIVERABLE TO MTP LEVEL 3!
> 
> (Please excuse the caps.)
> 
> What is required for M2PA to bring message loss back down to
> acceptable levels is for M2PA to have a way of controlling when
> MSUs are acknowledged to the peer.  There are two ways of doing
> this:
> 
>         1)  Alter SCTP-ULP interaction to permit M2PA to tell
>             SCTP when to acknowledge DATA chunks and when not
>             to.
> 
>         2)  Put sequence numbers and acknolwedgement in the DATA
>             chunks with the MSUs themselves (i.e. put FSN/BSN in
>             the frame).
>             
> I prefer solution #2, because it will probably be a cold day
> before SCTP gets changed.
> 
> This is also a problem for M2UA.
> 
> 
> -- 
> 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 ¦

-- 
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]
Sender: [email-masked]
Date: Fri, 25 May 2001 17:40:05 -0500
From: "Randall R. Stewart" <[email-masked]>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Acknowledgement Problem
X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us
id 
                      f4PMe6h13651
X-SMTP-HELO: stewart.chicago.il.us
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [64.37.247.196]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian

Actually it probably would work fine with most implementations...not that I
would recomend this...

But when you think about the way you implement this you normally go through
and process the CUM-TSN first.
Remove up to the CUM-ACK then you process the GAP's seperately... Now some
implementations may attempt to collapse any consecutive TSN's but this is
really not right... One of the implementations at the last bakeoff (if I
remember right) was real good at detecting things like this... however their
solution, (if a peer was doing something like this) that was not to their
liking was to abort the assoc.

So probably it would work or abort the association :0

R

"Brian F. G. Bidulock" wrote:
> 
> Tom,
> 
> Actually, there is a sneaky way of getting SCTP to deal with
> this if one has control of the SCTP implementation.  That is
> to GAP ACK TSNs which have not yet been accepted by the ULP.
> Something like this:
> 
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48
> 
> to acknowledge receipt of TSN 48 so that it gets struck from
> bytes in flight but is held by the transmitter in case we
> reneg or the association aborts.
> 
> The next ones might look like:
> 
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 48
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 50
>         SACK:    Cummulative TSN = 47, GAP ACK = 48 to 52
> 
> then, when 48 through 51 have been accepted by ULP:
> 
>         SACK:    Cummulative TSN = 51, GAP ACK = 52 to 52
>         SACK:    Cummulative TSN = 51, GAP ACK = 52 to 54
> 
> If this can be done, then all that M2PA would have to do
> before sending status Busy or Processor outage is stop
> servicing SCTP's read queue for streams 1 through N.  M2PA
> would simply use the TSN of the last received MSU (truncated)
> in the changeover message.
> 
> This would not impede SCTP's RTT calculations or be as
> drastic as artificially dropping rwnd to 0.  I don't know
> how an existing implementation will take to having a GAP ACK
> thrown at it that doesn't have any real gaps.
> 
> --Brian
> 
> Brian F. G. Bidulock wrote:                 (Fri, 25 May 2001 15:16:58)
> > Tom,
> >
> > This is a separate note to attempt to address the acknowledgment
> > problem in M2PA.  This problem occurs whenever M2PA attempts to
> > give one of the following indications:
> >
> >         Out of Service
> >         Busy
> >         Processor Outage
> >
> > In the case of SS7 (SIOS, SIB, SIPO), the signalling link stops
> > acknowledging received frames.  In the case of M2PA, SCTP
> > continues acknowledging DATA chunks after these indications are
> > sent.  This has the problem of clearing the MSUs from the sender's
> > transmission and retransmission buffers and making them
> > unavailable for retrieval should the link fail as a result of
> > any of these indications (it always fails for "Out of Service").
> >
> > This increases message loss due to failure.  At the SS7 link
> > level, SS7 links DO NOT ACKNOWLEDGE MSUs UNTIL THEY ARE
> > SUCCESSFULLY DELIVERABLE TO MTP LEVEL 3!
> >
> > (Please excuse the caps.)
> >
> > What is required for M2PA to bring message loss back down to
> > acceptable levels is for M2PA to have a way of controlling when
> > MSUs are acknowledged to the peer.  There are two ways of doing
> > this:
> >
> >         1)  Alter SCTP-ULP interaction to permit M2PA to tell
> >             SCTP when to acknowledge DATA chunks and when not
> >             to.
> >
> >         2)  Put sequence numbers and acknolwedgement in the DATA
> >             chunks with the MSUs themselves (i.e. put FSN/BSN in
> >             the frame).
> >
> > I prefer solution #2, because it will probably be a cold day
> > before SCTP gets changed.
> >
> > This is also a problem for M2UA.
> >
> >
> > --
> > 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 ¦
> 
> --
> 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]

-- 
Randall R. Stewart
[email-masked] or [email-masked] 815-342-5222 (cell)
815-477-2127 (work)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
From: Jon Berger <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: RE: M2PA: Significant Changes
Date: Mon, 28 May 2001 09:44:14 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-SMTP-HELO: miles.dataconnection.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: smtp2.dataconnection.com [192.91.191.8]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

comments below

Jon

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: 25 May 2001
22:06
To: sigtran
Cc: [email-masked]
Subject: Re: M2PA: Significant Changes

Tom,

Comments below...

On Fri, 25 May 2001, Tom George wrote:

> "Brian F. G. Bidulock" wrote:
>   [...]
> > 4.  Multiple links per Association.
> > 
> >     It is possibly dangerous to have multiple links, each in
> >     their own association, where the assocations follow the same
> >     network paths.  All of these links will likely fail together
> >     and can cause all kinds of thrashing around of changeovers
> >     in MTP L3 due to the serialization of link-failure
> >     primitives.  The answer to this problem could be one BIG
> >     M2PA link per linkset, however, the independence of SLS
> >     streams withing the SS7 traffic would not be taken advantage
> >     of due to the single data stream in M2PA.
> > 
> >     I would like to propose that traffic be sent over multiple
> >     streams within the SCTP association.
> > 
> >     This means using truncated TSN rather than SSN for changeover
> >     and negotiating the number of streams upon SCTP association.
>   [...]
> 
> More questions about this:
> 
> 1. If you just have one association between the endpoints, would not the
> capacity of that link set be limited to the capacity of that one
> association?

Yes; but the capacity of an SCTP association is unlimited (well, only
limited by the underlying network, which must be engineered anyway) so, so
what?  Using the link as a chunk of provisioning capacity is only applicable
to fixed bandwidth facilities such as circuits.

> 
> 2. I see problems with using TSNs for the changeover. 
> 
> a. You have to filter out the Link Status messages when you do the data
> retrieval, since you don't want to retransmit them on the alternate
> link.

Well... no you don't.  The algorithm to have the side receiving the
truncated TSN in the XCO is simple: just treat it as the first TSN in the
buffer earlier or at that provided in the XCO.  The algorithm at the sending
side is just a simple, skip advancing the TSN version of BSNT for status
messages, just advance it for MSUs.  It just needs to be monotonically
increasing, no worry if it skips a few.

[Jon] - I'm slightly confused here.  Each message (MSU or LSSU) must have a
TSN assigned to it.  If the sequence number that you are maintaining in M2PA
is not the TSN, then what is the point?  Also fragmentation will mean that
the TSN potentially advances more than once for each MSU.  This is not a
problem with SSN.

> 
> b. Suppose that a message is lost. Subsequent messages on other streams
> will be delivered to the upper layer (M2PA). Now something happens that
> causes a changeover. If you start retrieving data from the first gap in
> the TSNs, you will retransmit those messages on the other streams that
> had already been delivered to the upper layer M2PA. 
> 

The SCTP transmitter cannot strike the GAP ACKed messages from the
retransmission buffer because the SCTP receiver can reneg on the GAP.
These must be retrieved on association failure because the sending M2PA
cannot tell whether the receiving M2PA would have reneged on these in the
future.  Because they must be retrieved, the way to avoid duplication is to
have the receiving M2PA NOT deliver these message to MTP3 until the
cumulative ack point passes them.  SCTP will ensure that the messages do not
have to be retransmitted if not necessary and they will be struck from
SCTP's receive window, but they must be held by M2PA in the event of
failure.  After all, they are not fully acknowedged messages, due to the
renegging difficulty.

[Jon] - If you are saying that the M2PA maintains its own cumulative TSN ack
point and only delivers based on this, then I don't see the point of having
multiple streams.  You have reintroduced the head of line blocking that use
of multiple streams is designed to remove.  Perhaps you can be more specific
about your suggestion.

-- 
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: Bernard Kuc <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: m2ua - interface identifier
Date: Mon, 28 May 2001 11:10:14 +0200
X-Mailer: Internet Mail Service (5.5.2650.21)
X-SMTP-HELO: mail.azisa.co.za
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.azisa.co.za [196.14.124.43]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Ken, Heinz,

Just because we've done it as *Interface Identifier* it will save us effort
if it stays as it is. However if you really want to change it I won't object
too strongly.

Bernard

-----Original Message-----
From: Heinz Prantner [mailto:[email-masked]] Sent: Friday, May
25, 2001 9:45 PM
To: sigtran
Subject: Re: m2ua - interface identifier

Ken, All,

in that case I cannot resist asking: does anyone object to change *Interface
Identifier* to *Link Reference* ?

that was bad. was it? :-)

Heinz

----- Original Message -----
From: Ken Morneault <[email-masked]> To: sigtran
<[email-masked]> Sent: Friday, May 25, 2001 8:06 AM
Subject: Re: m2ua - interface identifier

>
>
> Heinz,
>
> I don't have a strong attachment to "Interface Identifier".  But, since
> it has been in the draft for so long, it would be good to see some
> consensus for a change.  Based on past requests, I know this is
> difficult because sometimes few people respond to these emails.
>
> So, please, if you have an opinion, respond to your preference
> for "Interface Identifier", "Link Reference" or other term.
>
> Ken
>
> At 09:52 AM 5/25/01 +0100, Mark Kobine wrote:
> >Heinz,
> >
> >We haven't had any problems modelling Interface Identifiers - they fit in
rather well in our system.
> >
> >However I agree that perhaps they could be named better.
> >
> >Cheers,
> >Mark
> >>----- Original Message -----
> >>From: <mailto:[email-masked]>Heinz Prantner
> >>To: <mailto:[email-masked]>sigtran
> >>Sent: 17 May 2001 20:05
> >>Subject: m2ua - interface identifier
> >>
> >>Dear M2ua's,
> >>
> >>we have some conflict in our data model with the term *interface
identifier* and thus would like to ask 1) whether we are the only one? and
(if so) 2) whether we could, should change the m2ua draft to use a different
name. The problem is, it does not really identify an interface (the way the
mib2 for example uses the term), but could mean a timeslot within a t1/e1
interface, or according to ITU Q.751 a Signaling Link Termination or a
Signaling Link (the draft explicitly states that *interface* is used for
*SS7 Signaling Link* so why not using signaling link for signaling link?).
The problem with *identifier* is, it gets confused with the identifier's
used to identify a interface within one system (e.g. a t1 interface id in a
signaling gateway) while the *interface identifier* enumerates accross
systems and means something different. (Uff, even describing the confusion
is confusing). We would like to propose to use *Link Reference* instead.
> >>
> >>Until Ken comes back from vacation it would be interesting to get
response on question 1) above.
> >>
> >>Thanks,
> >>
> >>Heinz Prantner
> >>System Architect Signaling Technology
> >>RadiSys, Corp.
> >>Signaling Products Design Center
> >><mailto:[email-masked]>[email-masked]
> >>+1-856-642-9229 x235
> >>---
> >>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]
Date: Mon, 28 May 2001 12:37:24 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: M2PA: Significant Changes
Reply-To: [email-masked]
Mail-Followup-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 
                      MAA09248
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-241.dallas.net [209.44.42.241]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Jon,

On Mon, 28 May 2001, Jon Berger wrote:

(snip)

> > Well... no you don't.  The algorithm to have the side receiving the
> > truncated TSN in the XCO is simple: just treat it as the first TSN
> > in the buffer earlier or at that provided in the XCO.  The algorithm
> > at the sending side is just a simple, skip advancing the TSN version
> > of BSNT for status messages, just advance it for MSUs.  It just needs
> > to be monotonically increasing, no worry if it skips a few.
> 
> [Jon] - I'm slightly confused here.  Each message (MSU or LSSU) must have
a
> TSN assigned to it.  If the sequence number that you are maintaining in
M2PA
> is not the TSN, then what is the point?  Also fragmentation will mean that
> the TSN potentially advances more than once for each MSU.  This is not a
> problem with SSN.
> 
In general that's what fragmentation would mean: however, it is unlikely
that an M2PA message will ever fragment.  Nevertheless, it is not an
impossible situation.  From the TSN in the XCO it is easy to identify the
last fully delivered SSN for each stream.

> > The SCTP transmitter cannot strike the GAP ACKed messages from the
> > retransmission buffer because the SCTP receiver can reneg on the GAP.
> > These must be retrieved on association failure because the sending M2PA
> > cannot tell whether the receiving M2PA would have reneged on these in
> > the future.  Because they must be retrieved, the way to avoid
duplication
> > is to have the receiving M2PA NOT deliver these message to MTP3 until
> > the cumulative ack point passes them.  SCTP will ensure that the
messages
> > do not have to be retransmitted if not necessary and they will be struck
> > from SCTP's receive window, but they must be held by M2PA in the event
> > of failure.  After all, they are not fully acknowedged messages, due
> > to the renegging difficulty.
> 
> [Jon] - If you are saying that the M2PA maintains its own cumulative TSN
ack
> point and only delivers based on this, then I don't see the point of
having
> multiple streams.  You have reintroduced the head of line blocking that
use
> of multiple streams is designed to remove.  Perhaps you can be more
specific
> about your suggestion.
No.  We have introduced timing of the message delivery across the receiving
SCTP-ULP interface.  There is no head of line blocking across the SCTP
association.  This is not an SCTP issue at all.  It is the SS7 changeover
procedure which does not permit reordering of SLS `streams' within an SLC
from sender to receiver.  I will say again: for proper operation of SS7
changeover, LPO and Busy, the receiver cannot fully acknowledge an MSU which
has not been delivered to MTP Level 3 and still hope to meet message loss
and reordering requirements.

-- 
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]
Sender: [email-masked]
Date: Tue, 29 May 2001 11:01:56 -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: SCON from ASP (Re: Final report from the Interop Test)
X-SMTP-HELO: imr1.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [208.237.135.240]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kazuo Watanabe wrote:

> from issue list at bakeoff
>
> >  026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
> >         congestion.
> (snip)
> >      The only case, where the SCON sent by the ASP seems
> >      applicable, is when the AS is geographically seperated
> >      from the ASP and the ASP detects overload towards the
> >      AS. In any case, I would propose to relate the
> >      SCON to the AS (RC) rather than DPC.
>
> "RC rather than DPC" makes sense to me.
> i guess we can have new ASPTM Message, ASP Congestion, rather than
> SCON with RC.
> Does this make sense?

It makes sense if you just want to report that the ASP is congested.
However, I don't think that is what the draft intended. I think the
intention of the draft is to use the congestion handling procedures of the
SS7 network to suspend the sending of messages with lower priority until
congestion has abated.

So, to me, the real issue is not how to indicate internal ASP congestion to
the SG, but
rather what actions are taken by the SG when the indication is received. The
draft indicates that in this case the SG should send a TFC to the concerned
point code indicated by the SCON message (in the case where there are local
users at the SG, the SG could be the concerned point code, but I will
address this later). Before I continue, let me state now that I am NOT an
SS7 expert.
From what I understand, upon reception of a TFC, the SS7 element can test
the congestion status of the affected destination using the route set
congestion test procedure, which involves sending a RCT message to the
congested destination.
If the destination is still congested, a TFC will be received. Otherwise, no
TFC will
be received and the congestion level is decremented by one.

The draft does not indicate the actions to be taken when the SG receives a
RCT for a

destination in the IP network. For example, should the RCT be propagated to
the remote MTP3-User at the ASP?

In the case where the concerned point code in the SCON message is the point
code of the
SG, there is no SS7 element to which a TFC can be sent. In this case, the SG
is responsible
for performing the route congestion test procedure. The problem is that
there is no message or procedure defined in the draft addressing this
functionality.

Having said all that, I still think that you can have a message that
indicates ASP congestion
to the SG, but the SG should turn that message into a TFC for each
destination serviced by
the ASP.

Regards,
Kurt

>
>
> --
> Kazuo Watanabe
>
> ---
> 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: Tue, 29 May 2001 11:12:12 -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: SCON from ASP (Re: Final report from the Interop Test)
X-SMTP-HELO: imr2.ericy.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: imr2.ericy.com [12.34.240.68]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

"Sidebottom, Greg [BCNR:7M01:EXCH]" wrote:

>
>
> Greetings,
>
> I must admit I never really liked the SCON from the ASP to the SG
> procedure (I resisted it for a long time) and was kind of glad to see
> this come up as an issue in the "Bay-cough".  I liked the Final Report
> proposal that this procedure should be replaced by
>
>    "closing of the receiver window in SCTP (on upper layer request),
> which should
>     lead to a congestion indication on the other side (the SG) from
> SCTP to the upper
>     layer. The SG, receiving traffic destined to the congested assoc,
> should respond
>     appropriately to the originator."

From what I understand, closing the receiver window in SCTP is not something
that the SCTP RFC supports as an action from an SCTP user. So, some
(probably most) SCTP implementations will not support it.
Also, what is the the appropriate response to the originator?

>
>
> I honestly don't understand the following case described after that
> (i.e., " The only case, where the SCON sent by the ASP seems
> applicable, is when the when the AS is geographically separated from
> the ASP and the ASP detects overload towards the AS").    I'm assuming
> that this is really a case where, within an ASP, separate processes
> are used to handle traffic for different Application Servers and these
> processes or the paths to them can congest independently.  If not then
> can someone clarify this case for me?  If so then I'd agree with Kazuo
> Watanabe that an ASP Congestion message (containing the affected RC)
> is clearer than adding an RC parameter to a reverse-direction SCON.
>
> Cheers,
>
>    Greg Sidebottom
>    [email-masked]
>    +1 613 851-6725 (cell)
>
>  -----Original Message-----
> From:   Kazuo Watanabe [mailto:[email-masked]]
> Sent:   Thursday, May 24, 2001 8:38 AM
> To:     sigtran
> Cc:     [email-masked]
> Subject:        SCON from ASP (Re: Final report from the Interop Test)
>
> from issue list at bakeoff
>
> >  026 3.4.4 sending SCON message from ASP to SG indicating M3UA or
> ASP
> >         congestion.
> (snip)
> >      The only case, where the SCON sent by the ASP seems
> >      applicable, is when the AS is geographically seperated
> >      from the ASP and the ASP detects overload towards the
> >      AS. In any case, I would propose to relate the
> >      SCON to the AS (RC) rather than DPC.
>
> "RC rather than DPC" makes sense to me.
> i guess we can have new ASPTM Message, ASP Congestion, rather than
> SCON with RC.
> Does this make sense?
>
> --
> Kazuo Watanabe
>
> ---
> 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: Tue, 29 May 2001 12:53:26 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Reply-To: [email-masked]
Mail-Followup-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 
                      MAA26585
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-241.dallas.net [209.44.42.241]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt, Greg,

Translating congestion between MTP and its Users into route set congestion
is not a good idea.  The SS7 network interprets route set congestion as
applying only to a particular route and in some national variants will
reroute (restrict) traffic to other route sets on the basis of route set
congestion.

In the case you are talking about, it is the ASP (the MTP-User) which is
congested in the view of the SG, not a route set in the SS7 network.

This form of congestion (where there is congestion in or after the delivery
of MSUs to an MTP-User) is the responsibility of congestion controls at
Level 4 (that is, ISUP and TCAP congestion control) rather than route set
congestion.  So, for example, if the ASP is processing ISUP messages and it
is experiencing congestion in the ASP or between the SG and the ASP, either
the ISUP in the ASP or the SG should signal Automatic Congestion Level
controls in ISUP REL messages to the originating ISUP peers causing the
congestion.

Under drastic congestion, the SG should report the user part temporarily
unavailable.

In SS7 once an MSU has been delivered to MTP Level 3 (not its User), it is
no longer involved in transmit or receive congestion calculations.  So,
there is no case where the SG should normally signal TFC to the SS7 network
as a result of M3UA congestion.

--Brian

On Tue, 29 May 2001, Kurt Kite wrote:

> Kazuo Watanabe wrote:
> 
> > from issue list at bakeoff
> >
> > >  026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
> > >         congestion.
> > (snip)
> > >      The only case, where the SCON sent by the ASP seems
> > >      applicable, is when the AS is geographically seperated
> > >      from the ASP and the ASP detects overload towards the
> > >      AS. In any case, I would propose to relate the
> > >      SCON to the AS (RC) rather than DPC.
> >
> > "RC rather than DPC" makes sense to me.
> > i guess we can have new ASPTM Message, ASP Congestion, rather than
> > SCON with RC.
> > Does this make sense?
> 
> It makes sense if you just want to report that the ASP is congested.
> However, I don't think that is what the draft intended. I think the
> intention of the draft is to use the congestion handling procedures of
> the SS7 network to suspend the sending of messages with lower priority
> until congestion has abated.
> 
> So, to me, the real issue is not how to indicate internal ASP
> congestion to the SG, but rather what actions are taken by the SG when
> the indication is received. The draft indicates that in this case the
> SG should send a TFC to the concerned point code indicated by the SCON
> message (in the case where there are local users at the SG, the SG
> could be the concerned point code, but I will address this later).
> Before I continue, let me state now that I am NOT an SS7 expert.  From
> what I understand, upon reception of a TFC, the SS7 element can test
> the congestion status of the affected destination using the route set
> congestion test procedure, which involves sending a RCT message to the
> congested destination.  If the destination is still congested, a TFC
> will be received. Otherwise, no TFC will be received and the
> congestion level is decremented by one.
> 
> The draft does not indicate the actions to be taken when the SG
> receives a RCT for a
> 
> destination in the IP network. For example, should the RCT be
> propagated to the remote MTP3-User at the ASP?
> 
> In the case where the concerned point code in the SCON message is the
> point code of the SG, there is no SS7 element to which a TFC can be
> sent. In this case, the SG is responsible for performing the route
> congestion test procedure. The problem is that there is no message or
> procedure defined in the draft addressing this functionality.
> 
> Having said all that, I still think that you can have a message that
> indicates ASP congestion to the SG, but the SG should turn that
> message into a TFC for each destination serviced by the ASP.
> 
> Regards,
> Kurt
> 
> 
> >
> >
> > --
> > Kazuo Watanabe
> >
> > ---
> > 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    ¦ 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, 29 May 2001 13:14:01 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Reply-To: [email-masked]
Mail-Followup-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 
                      NAA26951
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-241.dallas.net [209.44.42.241]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Heinz,

I disagree altogether as explained somewhat in the note you just missed.

This is a confusion between TFC (which applies to outgoing route set
congestion from an STP) and MTP-User congestion (which applies to congestion
within the MTP-User or between the MTP and the MTP-User).  Signalling route
set congestion is only signalled back to the originator of a message which
encounters a link-set which is in link-set (transmit) congestion towards the
route set.  Once the message has been acknolwedged by MTP Level 3 for
distribution, route set congestion no longer applies.
MTP-User congestion does.

The temporary inability of MTP Level 3 to communicate with its Users
represents MTP User Part Unavailability rather than route-set congestion.

For example, where one signalling point code is spread across multiple ASPs,
and one ASP becomes congested, it is not the signalling route to the AS
which has become congested, it is the MTP-User for the specified routing
context which corresponds to the ASP which has become congested or
temporarily unavailable.

If the SG is going to be capable of distinguishing between routing contexts,
it will be necessary for it to understand the congestion procedures which
are applicable to the routing context.  So, for example, it an ISUP trunk
group CIC range forms a routing context to an ASP, the SG must be aware of
the ACL procedures to perform in the event of congestion towards the routing
context (i.e.  responding to IAMs with REL(network congestion)
ACL(congestion level)).

--Brian

On Tue, 29 May 2001, Heinz Prantner wrote:

> Kurt, Greg, All,
> 
> from GR905 - 3.1.5.4:
> 
> *The Transfer Controlled (TFC) message is sent in response to a
> received message destined for a signaling point where traffic has
> exceeded a specified congestion threshold. It is used to throttle
> traffic to that destination by notifying the remote signaling point to
> no longer send messages destined to the signaling point experiencing
> congestion with a priority lower than the one specified in the TFC
> message.*
> 
> The proposed change for M3UA was to apply the congestion state (within
> the SG) to an AS. (Somehow that became ASP congestion.) So the ASP
> would send an AS-congested message (new, slightly modified from
> Kazuo's proposal) refering to the AS by RC. The SG marks the AS
> congested and responds with TFC to incoming messages towards this AS.
> The TFC is sent to the originator of the incoming message. The refered
> destination is the one the AS is SPMC member of.
> 
>  As stated in the *bay-cough* (I like the new name) -issues, my
>  prefered solution (and Greg seems to like it :-) would have been to
>  close the receiver window in SCTP. If it is the ASP who has queues
>  filling up, this is most likely to happen anyway (without the upper
>  layer having to tell the sctp with eventual new api function). The
>  SG-SCTP SHOULD inform the upper layer with an Congestion Notification
>  (another undocumented interface ?). In that case I would have marked
>  all ASs for that ASP congested. Any incoming message for one of these
>  ASs would have a TFC in return....
> 
> The AS-congestion message still makes sense when the AS is seperated
> (different process, host) from ASP, as Greg was asking, assuming....
> (and still could be used in case SCTP does not support to close window
> on demand...)
> 
> Incoming RSCT messages could be responded by the SG based on the
> current AS congestion state. The SG, independently, could send
> periodically *AS Congestion Test messages* to the ASP(s).
> 
> (This does not cover the differences of congestion mechanisms in
> different standards, and I dont see the M3UA specifying the
> appropriate  SG behavior, still, the AS congestion state maintained by
> the SG should be good for ITU and ANSI)
> 
> Kind regards,
> 
> Heinz
> 

-- 
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]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Date: Tue, 29 May 2001 13:53:11 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Kurt, Greg, All,

from GR905 - 3.1.5.4:

*The Transfer Controlled (TFC) message is sent in response to a received
message destined
for a signaling point where traffic has exceeded a specified congestion
threshold. It is used
to throttle traffic to that destination by notifying the remote signaling
point to no longer
send messages destined to the signaling point experiencing congestion with a
priority lower
than the one specified in the TFC message.*

The proposed change for M3UA was to apply the congestion state (within the
SG) to an AS. (Somehow that became ASP congestion.) So the ASP would send an
AS-congested message (new, slightly modified from Kazuo's proposal) refering
to the AS by RC. The SG marks the AS congested and responds with TFC to
incoming messages towards this AS. The TFC is sent to the originator of the
incoming message. The refered destination is the one the AS is SPMC member
of.

 As stated in the *bay-cough* (I like the new name) -issues, my prefered
solution (and Greg seems to like it :-) would have been to close the
receiver window in SCTP. If it is the ASP who has queues filling up, this is
most likely to happen anyway (without the upper layer having to tell the
sctp with eventual new api function). The SG-SCTP SHOULD inform the upper
layer with an Congestion Notification (another undocumented interface ?). In
that case I would have marked all ASs for that ASP congested. Any incoming
message for one of these ASs would have a TFC in return....

The AS-congestion message still makes sense when the AS is seperated
(different process, host) from ASP, as Greg was asking, assuming.... (and
still could be used in case SCTP does not support to close window on
demand...)

Incoming RSCT messages could be responded by the SG based on the current AS
congestion state. The SG, independently, could send periodically *AS
Congestion Test messages* to the ASP(s).

(This does not cover the differences of congestion mechanisms in different
standards, and I dont see the M3UA specifying the appropriate  SG behavior,
still, the AS congestion state maintained by the SG should be good for ITU
and ANSI)

Kind regards,

Heinz

----- Original Message -----
From: Kurt Kite <[email-masked]> To: sigtran
<[email-masked]> Sent: Tuesday, May 29, 2001 11:01 AM
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)

> Kazuo Watanabe wrote:
>
> > from issue list at bakeoff
> >
> > >  026 3.4.4 sending SCON message from ASP to SG indicating M3UA or ASP
> > >         congestion.
> > (snip)
> > >      The only case, where the SCON sent by the ASP seems
> > >      applicable, is when the AS is geographically seperated
> > >      from the ASP and the ASP detects overload towards the
> > >      AS. In any case, I would propose to relate the
> > >      SCON to the AS (RC) rather than DPC.
> >
> > "RC rather than DPC" makes sense to me.
> > i guess we can have new ASPTM Message, ASP Congestion, rather than
> > SCON with RC.
> > Does this make sense?
>
> It makes sense if you just want to report that the ASP is congested.
However,
> I don't think that is what the draft intended. I think the intention of
the draft
> is to use the congestion handling procedures of the SS7 network to suspend
> the sending of messages with lower priority until congestion has abated.
>
> So, to me, the real issue is not how to indicate internal ASP congestion
to the SG,
> but
> rather what actions are taken by the SG when the indication is received.
The
> draft indicates that in this case the SG should send a TFC to the
concerned
> point code indicated by the SCON message (in the case where there are
local
> users at the SG, the SG could be the concerned point code, but I will
address
> this later). Before I continue, let me state now that I am NOT an SS7
expert.
> From what I understand, upon reception of a TFC, the SS7 element can test
the
> congestion status of the affected destination using the route set
congestion
> test procedure, which involves sending a RCT message to the congested
destination.
> If the destination is still congested, a TFC will be received. Otherwise,
no TFC
> will
> be received and the congestion level is decremented by one.
>
> The draft does not indicate the actions to be taken when the SG receives a
RCT for a
>
> destination in the IP network. For example, should the RCT be propagated
to the
> remote MTP3-User at the ASP?
>
> In the case where the concerned point code in the SCON message is the
point code of
> the
> SG, there is no SS7 element to which a TFC can be sent. In this case, the
SG is
> responsible
> for performing the route congestion test procedure. The problem is that
there is
> no message or procedure defined in the draft addressing this
functionality.
>
> Having said all that, I still think that you can have a message that
indicates
> ASP congestion
> to the SG, but the SG should turn that message into a TFC for each
destination
> serviced by
> the ASP.
>
> Regards,
> Kurt
>
>
> >
> >
> > --
> > Kazuo Watanabe
> >
> > ---
> > 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]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Date: Tue, 29 May 2001 15:50:57 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Brian,

I disagree partly to your altogether disagreement.

What is wrong with the SG considering the SG-ASP connections as a *Route
Set* and thus applying MTP3-congestion mechanism? Would'nt the Originators
throttle traffic? Your proposal seems to incline RELease of calls at the
call destination (or almost-destination). Your proposal is restricted to
ISUP, while M3UA is for MTP3-Users. Is there anything in SS7 preventing an
endpoint to generate TFCs ? (I did ask Greg this question already which he
answered with no)

(Above is no question in case the SG represents an STP, and is member of a
different SPMC than the AS).

I miss your point and dont understand why TFCs are bad.

Besides: I still didnt see the note you were refering to, so maybe its
explained there.

Cheers, Heinz

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]> To: sigtran
<[email-masked]> Sent: Tuesday, May 29, 2001 1:14 PM
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)

Heinz,

I disagree altogether as explained somewhat in the note you just missed.

This is a confusion between TFC (which applies to outgoing route set
congestion from an STP) and MTP-User congestion (which applies to congestion
within the MTP-User or between the MTP and the MTP-User).  Signalling route
set congestion is only signalled back to the originator of a message which
encounters a link-set which is in link-set (transmit) congestion towards the
route set.  Once the message has been acknolwedged by MTP Level 3 for
distribution, route set congestion no longer applies.
MTP-User congestion does.

The temporary inability of MTP Level 3 to communicate with its Users
represents MTP User Part Unavailability rather than route-set congestion.

For example, where one signalling point code is spread across multiple ASPs,
and one ASP becomes congested, it is not the signalling route to the AS
which has become congested, it is the MTP-User for the specified routing
context which corresponds to the ASP which has become congested or
temporarily unavailable.

If the SG is going to be capable of distinguishing between routing contexts,
it will be necessary for it to understand the congestion procedures which
are applicable to the routing context.  So, for example, it an ISUP trunk
group CIC range forms a routing context to an ASP, the SG must be aware of
the ACL procedures to perform in the event of congestion towards the routing
context (i.e.  responding to IAMs with REL(network congestion)
ACL(congestion level)).

--Brian

On Tue, 29 May 2001, Heinz Prantner wrote:

> Kurt, Greg, All,
>
> from GR905 - 3.1.5.4:
>
> *The Transfer Controlled (TFC) message is sent in response to a
> received message destined for a signaling point where traffic has
> exceeded a specified congestion threshold. It is used to throttle
> traffic to that destination by notifying the remote signaling point to
> no longer send messages destined to the signaling point experiencing
> congestion with a priority lower than the one specified in the TFC
> message.*
>
> The proposed change for M3UA was to apply the congestion state (within
> the SG) to an AS. (Somehow that became ASP congestion.) So the ASP
> would send an AS-congested message (new, slightly modified from
> Kazuo's proposal) refering to the AS by RC. The SG marks the AS
> congested and responds with TFC to incoming messages towards this AS.
> The TFC is sent to the originator of the incoming message. The refered
> destination is the one the AS is SPMC member of.
>
>  As stated in the *bay-cough* (I like the new name) -issues, my
>  prefered solution (and Greg seems to like it :-) would have been to
>  close the receiver window in SCTP. If it is the ASP who has queues
>  filling up, this is most likely to happen anyway (without the upper
>  layer having to tell the sctp with eventual new api function). The
>  SG-SCTP SHOULD inform the upper layer with an Congestion Notification
>  (another undocumented interface ?). In that case I would have marked
>  all ASs for that ASP congested. Any incoming message for one of these
>  ASs would have a TFC in return....
>
> The AS-congestion message still makes sense when the AS is seperated
> (different process, host) from ASP, as Greg was asking, assuming....
> (and still could be used in case SCTP does not support to close window
> on demand...)
>
> Incoming RSCT messages could be responded by the SG based on the
> current AS congestion state. The SG, independently, could send
> periodically *AS Congestion Test messages* to the ASP(s).
>
> (This does not cover the differences of congestion mechanisms in
> different standards, and I dont see the M3UA specifying the
> appropriate  SG behavior, still, the AS congestion state maintained by
> the SG should be good for ITU and ANSI)
>
> Kind regards,
>
> Heinz
>

--
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]
Date: Tue, 29 May 2001 16:10:54 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Reply-To: [email-masked]
Mail-Followup-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 
                      QAA29725
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-96.dallas.net [209.44.41.96]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Heinz,

Several points of disagreement:

 1) Signalling End Points do not generate TFC.  Only
    STP generates TFC.  Some STPs with border gateway
    screening will discard TFCs received on A- or
    F-links.

 2) If TFC is sent in response to congestion of one
    routing context, all routing contexts to affected
    signalling point code will be throttled by the
    recipient of the TFC.

 3) When the SG receives a signalling route set test
    message for the affected destination, what does
    the SG use as the congestion level for the response?

    The congestion status of one routing context for
    the concerned point code?  The greatest of all of
    routing contexts for that point code?  The least
    of all ....

The reason that TFCs are bad in this case is that they tell the network that
other routes to the concerned signalling point may be uncongested and some
national variants peform transfer restricted procedures in response to alter
routing.  When the ASP is congested, it doesn't matter what route is taken
to it, it is still congested...  TFC in this case will cause the some SS7
networks to reroute traffic only to encounter the same situation.

Further, TFCs are bad in this case because the congestion condition is not
guaranteed sufficient hysteresis to ensure that the condition does not
thrash between congestion levels, causing increased rerouting and message
loss in the SS7 network, not to mention increaseds strain on signalling end
points and STPs.

--Brian

On Tue, 29 May 2001, Heinz Prantner wrote:

> Brian,
> 
> I disagree partly to your altogether disagreement.
> 
> What is wrong with the SG considering the SG-ASP connections as a *Route
> Set* and thus applying MTP3-congestion mechanism? Would'nt the Originators
> throttle traffic? Your proposal seems to incline RELease of calls at the
> call destination (or almost-destination). Your proposal is restricted to
> ISUP, while M3UA is for MTP3-Users. Is there anything in SS7 preventing an
> endpoint to generate TFCs ? (I did ask Greg this question already which he
> answered with no)
> 
> (Above is no question in case the SG represents an STP, and is member of a
> different SPMC than the AS).
> 
> I miss your point and dont understand why TFCs are bad.
> 
> Besides: I still didnt see the note you were refering to, so maybe its
> explained there.
> 
> Cheers, Heinz
> 

-- 
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, 29 May 2001 19:50:34 -0500
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: [email-masked]
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
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-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com
id 
                      TAA00483
X-SMTP-HELO: bfgbhome.inetint.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: tnt-dal-96.dallas.net [209.44.41.96]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Heinz,

Please see comments below.

On Tue, 29 May 2001, Heinz Prantner wrote:

> Brian,
> 
> thank's for the list, I don't doubt you have some points. I'm not
> convinced though, that implementing *MTP3-User congestion procedures*
> in the SG makes it better.  You add a lot of complexity to the SG for
> the purpose of  simulating live as usual.
...

Welcome to SS7.

...
> Your - valuable :->
> arguments point to the discrepancy between SS7 route related
> congestion procedures versus Sigtran distributed User Part
> architecture (where part of the User Parts get congested ((on
> different levels))). (Did the inventors of the User Parts forsee that
> it will get parted when giving it that name???).  Beside that you add
> enormous complexity (various Users with various call states
> [congestion handling for an IAM versus other call setup or call
> release messages] with various standards in various countries) ...

No complexity has been added.  These user-part level congestion controls are
required to properly implement ISUP and TCAP.  It is only a question of
which side of the line the congestion controls are on.

M3UA is the one which has decided to "partition" the MTP to MTP-User
interface more granular than that which is specified for an MTP-User: the
signalling point code and service indicator.  This more granular
partitioning moves up beyond the MTP to MTP-User interface to that of the
MTP User Part itself.
Because the SG has been forced to take this granularity into consideration,
it must do so completely.  That not only includes congestion but other
procedures as well.

For example, an AS has a routing context which is an ISUP routing context
which contains all of the CICs in a trunk group (TG x) between SSP A (PC a)
and SSP B (PC b).  What does the SG do when this particular routing context
when the AS is down?

If you follow your TFC analogy, you would go sending TFPs for the whole
point code.  This is ridiculous.

So, what does the SG do when an IAM arrives for the routing context of the
AS which is down?  Let's see, the options are:

        a) send TFP (preposterous, this will cause all of the
        new calls to trunk groups to SSP B to fail)

        b) send UPU (preposterous for the same reason)

        c) send REL (network failure) and invoke ISUP's circuit
        validation test procedures (makes sense).

So, what is it the SG to do?

Same for congestion.  What does the SG do when an IAM arrives for a
congested AS?

        a) send TFC (preposterous, this will cause all of the
        new calls to trunk groups to SSP B to fail)

        b) send UPC (preposterous as well)

        c) send REL with ACL indicating (network congestion) and
        invoke ISUP's congestion controls.

So, what is the SG to do?

This is not a matter of adding complexity, it is a matter of choosing upon
which side of an SCTP association to place the procedure.  Complexity is not
added, it is not removed.

Your approach will muddle the MTP interface by having the MTP-User somehow
indicate to MTP that it is experiencing congestion worthy of a TFC.  That
primitive is not part of the existing interface and will cause
interoperability problems with existing MTP3 implementations which provide
an interface per Q.704 specs.

...
> you
> also incline to throw the whole traffic reduction to the end of the
> call path (ie the almost-destination) while the SS7 commits to reduce
> traffic at the origin.
...

No.  Congestion like ISUP ACL work just like TFC.  It tells the originator
of calls to stop sending at 2 or 3 congesion levels just as TFC does, except
it's granularity is the ISUP trunk group rather than the point code.  This
is a granularity that the routing context cannot go beneath without causing
a lot of disruption to ISUP circuit group management procedures.

...
> You will start implementing congestion
> procedures and you will end up implementing billing (let me think
> about that a little more, have to talk to our sales guys:-). I vote
> for giving up the granularity, given by the distributed architecture
> for the User Part, in case congestion occurs on one part of them.

Your SG implementation will fail Q.782 conformance tests.

--Brian

(more comments after yours below)

> > Several points of disagreement:
> > 
> >  1) Signalling End Points do not generate TFC.  Only
> >     STP generates TFC.  Some STPs with border gateway
> >     screening will discard TFCs received on A- or
> >     F-links.
> 
> [HP] (should be: A- or E-links)
>   Yes, you are right. By definition, STPs send the TFC
>   (so far:-).

Sorry, A-, E- or F-.  But don't forget F: gateway screening is as applicable
to SEPs as it is to STPs.

> 
> >  2) If TFC is sent in response to congestion of one
> >     routing context, all routing contexts to affected
> >     signalling point code will be throttled by the
> >     recipient of the TFC.
> 
> [HP] That's not so easy to say since the routing key
>     is rather vague defined (one of the potential
>     parameters of routing key is a opc range,
>     if I remember right), but in general: yes,
>     that is not different to an traditional SS7
>     endpoint, where everything is in one place.
>     So you lose the granularity, given by distributed
>     ASs, for congestion handling.

If your routing key contains complete point codes traffic (ISUP, TCAP, etc)
for one or more point codes, it is still inappropriate if your SG is
connected to the SS7 network by A-, E- or F- links.  Your TFC's will never
be "heard" by the network.

> 
> >  3) When the SG receives a signalling route set test
> >     message for the affected destination, what does
> >     the SG use as the congestion level for the response?
> > 
> >     The congestion status of one routing context for
> >     the concerned point code?  The greatest of all of
> >     routing contexts for that point code?  The least
> >     of all ....
> 
> [HP] Uff, it seems we have overlapping congestion
>     levels. Choose one.
>     Again, granularity given by multiple ASs is lost
>     for congestion.

It is not lost if you use the procedure appropriate to the granularity of
the routing key for congestion control.

-- 
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]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Date: Tue, 29 May 2001 20:12:08 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: [209.204.106.218]
X-Orig: <[email-masked]>
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Brian,

thank's for the list, I don't doubt you have some points. I'm not convinced
though,
that implementing *MTP3-User congestion procedures* in the SG makes it
better.
You add a lot of complexity to the SG for the purpose of  simulating live as
usual.
Your - valuable :-> arguments point to the discrepancy between SS7 route
related
congestion procedures versus Sigtran distributed User Part architecture
(where
part of the User Parts get congested ((on different levels))). (Did the
inventors
of the User Parts forsee that it will get parted when giving it that
name???).  Beside
that you add enormous complexity (various Users with various call states
[congestion
handling for an IAM versus other call setup or call release messages] with
various standards in various countries) you also incline to throw the whole
traffic
reduction to the end of the call path (ie the almost-destination) while the
SS7
commits to reduce traffic at the origin. You will start implementing
congestion
procedures and you will end up implementing billing (let me think about that
a little more, have to talk to our sales guys:-). I vote for giving up the
granularity,
given by the distributed architecture for the User Part, in case congestion
occurs on one part of them.

 see also below...

Heinz

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]> To: sigtran
<[email-masked]> Sent: Tuesday, May 29, 2001 4:10 PM
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)

Heinz,

Several points of disagreement:

 1) Signalling End Points do not generate TFC.  Only
    STP generates TFC.  Some STPs with border gateway
    screening will discard TFCs received on A- or
    F-links.

[HP] (should be: A- or E-links)
  Yes, you are right. By definition, STPs send the TFC
  (so far:-).

 2) If TFC is sent in response to congestion of one
    routing context, all routing contexts to affected
    signalling point code will be throttled by the
    recipient of the TFC.

[HP] That's not so easy to say since the routing key
    is rather vague defined (one of the potential
    parameters of routing key is a opc range,
    if I remember right), but in general: yes,
    that is not different to an traditional SS7
    endpoint, where everything is in one place.
    So you lose the granularity, given by distributed
    ASs, for congestion handling.

 3) When the SG receives a signalling route set test
    message for the affected destination, what does
    the SG use as the congestion level for the response?

    The congestion status of one routing context for
    the concerned point code?  The greatest of all of
    routing contexts for that point code?  The least
    of all ....

[HP] Uff, it seems we have overlapping congestion
    levels. Choose one.
    Again, granularity given by multiple ASs is lost
    for congestion.

The reason that TFCs are bad in this case is that they tell the network that
other routes to the concerned signalling point may be uncongested and some
national variants peform transfer restricted procedures in response to alter
routing.  When the ASP is congested, it doesn't matter what route is taken
to it, it is still congested...  TFC in this case will cause the some SS7
networks to reroute traffic only to encounter the same situation.

Further, TFCs are bad in this case because the congestion condition is not
guaranteed sufficient hysteresis to ensure that the condition does not
thrash between congestion levels, causing increased rerouting and message
loss in the SS7 network, not to mention increaseds strain on signalling end
points and STPs.

--Brian

On Tue, 29 May 2001, Heinz Prantner wrote:

> Brian,
>
> I disagree partly to your altogether disagreement.
>
> What is wrong with the SG considering the SG-ASP connections as a *Route
> Set* and thus applying MTP3-congestion mechanism? Would'nt the Originators
> throttle traffic? Your proposal seems to incline RELease of calls at the
> call destination (or almost-destination). Your proposal is restricted to
> ISUP, while M3UA is for MTP3-Users. Is there anything in SS7 preventing an
> endpoint to generate TFCs ? (I did ask Greg this question already which he
> answered with no)
>
> (Above is no question in case the SG represents an STP, and is member of a
> different SPMC than the AS).
>
> I miss your point and dont understand why TFCs are bad.
>
> Besides: I still didnt see the note you were refering to, so maybe its
> explained there.
>
> Cheers, Heinz
>

--
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: Wed, 30 May 2001 08:02:29 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
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, Heinz,

Please see comments below.

At 07:50 PM 5/29/01 -0500, Brian F. G. Bidulock wrote:
>Heinz,
>
>Please see comments below.
>
>On Tue, 29 May 2001, Heinz Prantner wrote:
>
> > Brian,
> > 
> > thank's for the list, I don't doubt you have some points. I'm not
> > convinced though, that implementing *MTP3-User congestion procedures*
> > in the SG makes it better.  You add a lot of complexity to the SG for
> > the purpose of  simulating live as usual.
>...
>
>Welcome to SS7.
>
>...
> > Your - valuable :->
> > arguments point to the discrepancy between SS7 route related
> > congestion procedures versus Sigtran distributed User Part
> > architecture (where part of the User Parts get congested ((on
> > different levels))). (Did the inventors of the User Parts forsee that
> > it will get parted when giving it that name???).  Beside that you add
> > enormous complexity (various Users with various call states
> > [congestion handling for an IAM versus other call setup or call
> > release messages] with various standards in various countries)
>...
>
>No complexity has been added.  These user-part level congestion
>controls are required to properly implement ISUP and TCAP.  It
>is only a question of which side of the line the congestion
>controls are on.
>
>M3UA is the one which has decided to "partition" the MTP to
>MTP-User interface more granular than that which is specified
>for an MTP-User: the signalling point code and service
>indicator.  This more granular partitioning moves up beyond the
>MTP to MTP-User interface to that of the MTP User Part itself.
>Because the SG has been forced to take this granularity into
>consideration, it must do so completely.  That not only includes
>congestion but other procedures as well.

Would you consider TFC or route level congestion to be "workable" (though
maybe not ideal) if the Point Code was not split among more than one AS as
in your example below and the SG was acting as a STP.  In other words, the
ASP that is congested is the only ASP supporting the Point Code.

>For example, an AS has a routing context which is an ISUP
>routing context which contains all of the CICs in a trunk group
>(TG x) between SSP A (PC a) and SSP B (PC b).  What does the SG
>do when this particular routing context when the AS is down?

I assume for your example that SSP B (PC b) is the IP based Point Code and
that there are other Routing Contexts (i.e. a Trunk Group between SSP C (PC
c) and SSP B (PC b) that exist) for SSP B that are support by other ASPs.

>If you follow your TFC analogy, you would go sending TFPs for
>the whole point code.  This is ridiculous.
>
>So, what does the SG do when an IAM arrives for the routing
>context of the AS which is down?  Let's see, the options are:
>
>         a) send TFP (preposterous, this will cause all of the
>         new calls to trunk groups to SSP B to fail)
>
>         b) send UPU (preposterous for the same reason)
>
>         c) send REL (network failure) and invoke ISUP's circuit
>         validation test procedures (makes sense).
>
>So, what is it the SG to do?

I like this solution for the case of a Point Code supported by multiple
ASPs, particularly when the SG is not a STP.   However, I never thought the
Sigtran group would be able to specify the SG behavior in a RFC to this
detail.  

The alternative (at least for this case) is to have a default routing key
that would cause all the messages for this Trunk Group (this Routing
Context) to be sent to a different (default) ASP.  The default ASP would
send REL and invoke ISUP's circuit validation test procedures.
This places the burden on the ASPs to coordinate with each other.

>Same for congestion.  What does the SG do when an IAM arrives
>for a congested AS?
>
>         a) send TFC (preposterous, this will cause all of the
>         new calls to trunk groups to SSP B to fail)
>
>         b) send UPC (preposterous as well)
>
>         c) send REL with ACL indicating (network congestion) and
>         invoke ISUP's congestion controls.
>
>So, what is the SG to do?

The default routing key could also be used in this case, BUT it would depend
on ASPs communicating with each other (i.e. the congested ASP must notify
the default ASP that it is congested) OR that SG could "notify" the default
ASP of the congestion.

My concern is that the ASP is experiencing SCTP congestion but it is
expected to send at least two messages (SCON to SG and proprietary
congestion message to fellow ASP) in a timely manner in order to have this
procedure work properly.

>This is not a matter of adding complexity, it is a matter of
>choosing upon which side of an SCTP association to place the
>procedure.  Complexity is not added, it is not removed.

Agree - the case of a Point Code supported by multiple Routing Contexts is
complex no matter where you put these procedures.  If you place it on the
SG, the SG ends up managing circuit state while the ASP for a Trunk Group is
unavailable (i.e. responding to BLOs, etc.).  
The ASP then has to query the SG for circuit state when it becomes
available.  If you have a default ASP, then the configuration is more
complex (default ASPs) and you have to deal with ASP coordination and
communication.

I like the SG solution, but the ASP solution has the advantages placing all
the complexity within a single vendor and keeping the details out of
Sigtran.

>Your approach will muddle the MTP interface by having the
>MTP-User somehow indicate to MTP that it is experiencing
>congestion worthy of a TFC.  That primitive is not part of
>the existing interface and will cause interoperability
>problems with existing MTP3 implementations which provide
>an interface per Q.704 specs.
>
>...
> > you
> > also incline to throw the whole traffic reduction to the end of the
> > call path (ie the almost-destination) while the SS7 commits to reduce
> > traffic at the origin.
>...
>
>No.  Congestion like ISUP ACL work just like TFC.  It tells the
>originator of calls to stop sending at 2 or 3 congesion levels
>just as TFC does, except it's granularity is the ISUP trunk
>group rather than the point code.  This is a granularity that
>the routing context cannot go beneath without causing a lot of
>disruption to ISUP circuit group management procedures.
>
>...
> > You will start implementing congestion
> > procedures and you will end up implementing billing (let me think
> > about that a little more, have to talk to our sales guys:-). I vote
> > for giving up the granularity, given by the distributed architecture
> > for the User Part, in case congestion occurs on one part of them.
>
>Your SG implementation will fail Q.782 conformance tests.
>
>--Brian
>
>(more comments after yours below)
>
> > > Several points of disagreement:
> > > 
> > >  1) Signalling End Points do not generate TFC.  Only
> > >     STP generates TFC.  Some STPs with border gateway
> > >     screening will discard TFCs received on A- or
> > >     F-links.
> > 
> > [HP] (should be: A- or E-links)
> >   Yes, you are right. By definition, STPs send the TFC
> >   (so far:-).
>
>Sorry, A-, E- or F-.  But don't forget F: gateway screening is
>as applicable to SEPs as it is to STPs.
>
> > 
> > >  2) If TFC is sent in response to congestion of one
> > >     routing context, all routing contexts to affected
> > >     signalling point code will be throttled by the
> > >     recipient of the TFC.
> > 
> > [HP] That's not so easy to say since the routing key
> >     is rather vague defined (one of the potential
> >     parameters of routing key is a opc range,
> >     if I remember right), but in general: yes,
> >     that is not different to an traditional SS7
> >     endpoint, where everything is in one place.
> >     So you lose the granularity, given by distributed
> >     ASs, for congestion handling.
>
>If your routing key contains complete point codes traffic (ISUP,
>TCAP, etc) for one or more point codes, it is still
>inappropriate if your SG is connected to the SS7 network by A-,
>E- or F- links.  Your TFC's will never be "heard" by the
>network.
>
> > 
> > >  3) When the SG receives a signalling route set test
> > >     message for the affected destination, what does
> > >     the SG use as the congestion level for the response?
> > > 
> > >     The congestion status of one routing context for
> > >     the concerned point code?  The greatest of all of
> > >     routing contexts for that point code?  The least
> > >     of all ....
> > 
> > [HP] Uff, it seems we have overlapping congestion
> >     levels. Choose one.
> >     Again, granularity given by multiple ASs is lost
> >     for congestion.
>
>It is not lost if you use the procedure appropriate to the
>granularity of the routing key for congestion control.
>
>-- 
>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: "Mc Grew, Michael A (Mike)" <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: RE: SCON from ASP (Re: Final report from the Interop Test)
Date: Wed, 30 May 2001 08:22:07 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-MIME-Autoconverted: from 8bit to quoted-printable by 
                      ihemail2.firewall.lucent.com id f4UCMAU15723
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]

Brian,
A few observations:

The T1.111.4 (ANSI MTP Level 3) states that a signaling end point may send
TFC:

"13.7.1	The transfer-controlled procedure is performed at a signalling
transfer point, and optionally at a signalling point, when it must notify
one or more originating signalling points that they should no longer send to
the concerned destination messages with a given priority or lower."

How the end point does this is implementation-dependent. A literal
interpretation might say that the MTP3 (not the whole node, including user
parts) should be congested. But who knows what goes on inside the
implementation?

The MTP does not change routing due to congestion. Instead, it is intended
to inform the users to cut back the amount of traffic toward the congested
destination. However (maybe this is what you meant), STPs need to divert
traffic away from C-links (between mate STPs) may use C-link congestion as a
trigger to broadcast TFR, thereby causing traffic from adjacent nodes to be
sent directly to the mate STP instead of having to go via C-links.
So I would not call this a "change in routing" but just invoking a
procedure.
(I'll bet that's really clear now;-)!)

Also, there is an important distinction about congestion that is different
from the other network indications:
Not all the nodes that generate traffic toward the congested node will
receive TFC, because it is generated on a statistical basis, based on
current congestion state of the node which can change quickly. So the nodes
that generate the most traffic toward the congested node are more likely to
trigger a TFC response.

I'm not sure about your "thrashing" point.
Because TFC does not change routing, it does not have the thrashing impact
that a rerouting procedure would have. And the end point that receives TFC
should gradually restore traffic whle maintaining at an acceptable level --
again, seems more like "oscillating" than "thrashing".

Respectfully,
Mike McGrew
Lucent Technologies

----
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] Sent: Tuesday, May
29, 2001 5:11 PM
To: sigtran
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)

Heinz,

Several points of disagreement:

 1) Signalling End Points do not generate TFC.  Only
    STP generates TFC.  Some STPs with border gateway
    screening will discard TFCs received on A- or
    F-links.

 2) If TFC is sent in response to congestion of one
    routing context, all routing contexts to affected
    signalling point code will be throttled by the
    recipient of the TFC.

 3) When the SG receives a signalling route set test
    message for the affected destination, what does
    the SG use as the congestion level for the response?

    The congestion status of one routing context for
    the concerned point code?  The greatest of all of
    routing contexts for that point code?  The least
    of all ....

The reason that TFCs are bad in this case is that they tell the network that
other routes to the concerned signalling point may be uncongested and some
national variants peform transfer restricted procedures in response to alter
routing.  When the ASP is congested, it doesn't matter what route is taken
to it, it is still congested...  TFC in this case will cause the some SS7
networks to reroute traffic only to encounter the same situation.

Further, TFCs are bad in this case because the congestion condition is not
guaranteed sufficient hysteresis to ensure that the condition does not
thrash between congestion levels, causing increased rerouting and message
loss in the SS7 network, not to mention increaseds strain on signalling end
points and STPs.

--Brian

On Tue, 29 May 2001, Heinz Prantner wrote:

> Brian,
> 
> I disagree partly to your altogether disagreement.
> 
> What is wrong with the SG considering the SG-ASP connections as a *Route
> Set* and thus applying MTP3-congestion mechanism? Would'nt the Originators
> throttle traffic? Your proposal seems to incline RELease of calls at the
> call destination (or almost-destination). Your proposal is restricted to
> ISUP, while M3UA is for MTP3-Users. Is there anything in SS7 preventing an
> endpoint to generate TFCs ? (I did ask Greg this question already which he
> answered with no)
> 
> (Above is no question in case the SG represents an STP, and is member of a
> different SPMC than the AS).
> 
> I miss your point and dont understand why TFCs are bad.
> 
> Besides: I still didnt see the note you were refering to, so maybe its
> explained there.
> 
> Cheers, Heinz
> 

-- 
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: [email-masked]
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
To: "sigtran" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 30 May 2001 10:16:44 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a
|January 
             17, 2001) at 05/30/2001 10:16:45 AM
X-SMTP-HELO: dnsmx1rrc.telcordia.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: dnsmx1rrc.telcordia.com [128.96.20.41]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Section 9 of GR-2878-CORE (ATM HSLs) provides some brief considerations for
transition from MTP2 links to ATM HSLs and Section 2.1.3 of GR-2946-CORE
provides more detail transition plans.  The key point is that the ATM HSLs
and MTP2 links would have to be mixed in the same link set to allow an
operator to have a graceful transition.  During the transition period it is
recommended that the amout of traffic on the HSLs be the same as the MTP2
links.  In otherwords the MTP3 uses it's SLS mechanism to distribute the
traffic equally on all the links in the link set.  I think the same
transition concepts as described in GR-2946-CORE for ATM HSLs would also be
applicable for M2PA links.

Regards
Ray

"Brian F. G. Bidulock" <[email-masked]> on 05/25/2001 03:54:56 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]> cc:
[email-masked] (bcc: Ray P. Singh/Telcordia)
Subject:  Re: [Fwd: Re: M2PA: Multiple streams]

Jeff,

That was not my implication.  What I am saying is that it makes no never
mind that links in a linkset have different capacities, they must be
engineered not to congest.

When congestion occurs, it is congestion of the entire linkset "by design".
The problem is cannot be one of misbalancing, because link sets are
engineered to not congest when a link fails.  This is not a reason not to
mix the two.  Links of differing capacities can still be traffic engineered
to not congest under peak traffic loads and in the face of link failure.

On Fri, 25 May 2001, Jeff Copley wrote:

> But the point is, they DO congest and it is unacceptable not to have
> congestion procedures running 24-7, if that's your implication.
>
> Jeff
>
> "Brian F. G. Bidulock" wrote:
> >
> > Jacob,
> >
> > This is neither here nor there.  SS7 links are engineered to
> > not congest.  Only extreme network failure conditions can
> > cause congestion.
> >
> > On Fri, 25 May 2001, Jacob Heitz wrote:
> >
> > > MTP3 inerprets link congestion to mean linkset congestion, so if one
link
> > > becomes congested, the whole linkset is seen as congested, even though
> > > other links are ok. So, it is important to balance the links within a
linkset.
> > >
> >
> > --
> > 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    ¦ 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]
Date: Wed, 30 May 2001 09:32:55 -0500
From: Jeff Copley <[email-masked]>
Organization: Alcatel USA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: [Fwd: Re: M2PA: Multiple streams]
X-MIME-Autoconverted: from 8bit to quoted-printable by netmail.alcatel.com
id 
                      JAA01154
X-SMTP-HELO: netmail.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: netmail.alcatel.com [128.251.168.50]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian,

I think we are agreeing.  Link sets are supposed to be engineered so that
they don't congest.  As I'm sure you know (but provided here for the benfit
of others), link sets (except for c-link sets) are deployed in sets of two
where each is typically engineered under .4 erlangs (normal mode) so that
one can handle the traffic of the other link set in failure mode (.8
erlang).  But if traffic exceeds our engineered limits, then whalla, we have
congestion.

This set of two link sets (mentioned above) is a combined link set.  It
connects an originating node (let's call it node A) to two other nodes (B &
C) for loadsharing and reliability purposes to ensure access from node A to
the network (yes, there are other scenarios too). The point is, is that they
are not two link sets between just two nodes (e.g., not A to B) as this is
not allowed by SS7.

I agree with Greg (and I think you) that the reason to mix links in a link
set is for sort term burn-in reliability purposes.  I have also seen this
done.  When you engineer these mixed-speed link sets, you engineer them to
the lowest link speed, therefore, the IP links should never congest in this
configuration.  You can bump up your thresholds (i.e., engineered capacity)
once you gain confidence in the "new-fangled high-speed links" (thanks for
the quote Greg) and after you have deactivated the lower speed links.

Jeff

"Brian F. G. Bidulock" wrote:
> 
> Jeff,
> 
> That was not my implication.  What I am saying is that it makes
> no never mind that links in a linkset have different capacities,
> they must be engineered not to congest.
> 
> When congestion occurs, it is congestion of the entire linkset
> "by design".  The problem is cannot be one of misbalancing, because
> link sets are engineered to not congest when a link fails.  This
> is not a reason not to mix the two.  Links of differing capacities
> can still be traffic engineered to not congest under peak traffic
> loads and in the face of link failure.
> 
> On Fri, 25 May 2001, Jeff Copley wrote:
> 
> > But the point is, they DO congest and it is unacceptable not to have
> > congestion procedures running 24-7, if that's your implication.
> >
> > Jeff
> >
> > "Brian F. G. Bidulock" wrote:
> > >
> > > Jacob,
> > >
> > > This is neither here nor there.  SS7 links are engineered to
> > > not congest.  Only extreme network failure conditions can
> > > cause congestion.
> > >
> > > On Fri, 25 May 2001, Jacob Heitz wrote:
> > >
> > > > MTP3 inerprets link congestion to mean linkset congestion, so if one
link
> > > > becomes congested, the whole linkset is seen as congested, even
though
> > > > other links are ok. So, it is important to balance the links within
a linkset.
> > > >
> > >
> > > --
> > > 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    ¦ 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]
Reply-To: [email-masked]
From: Heinz Prantner <[email-masked]>
To: "sigtran" <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
Date: Wed, 30 May 2001 10:08:36 -0500
Organization: RadiSys Corp.
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-SMTP-HELO: slink12.ss7-link.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: mail.ss7-link.com [209.204.106.218]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>

Ken,

see below...

Heinz

----- Original Message -----
From: Ken Morneault <[email-masked]> To: sigtran
<[email-masked]> Sent: Wednesday, May 30, 2001 7:02 AM
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)

<snip>

However, I never
thought the Sigtran group would be able to specify the SG behavior in a RFC
to this detail.

[HP] seems like an Applicability Statement would be appropriate (just cut
and paste Brians comments into it...)

---
You are currently subscribed to sigtran as: [email-masked] To
unsubscribe send a blank email to
[email-masked]
X-Origination-Site: <ind.alcatel.com>
X-InterScan: Passed
Sender: [email-masked]
Date: Wed, 30 May 2001 15:48:00 +0000
From: Laurent BRARD <[email-masked]>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
To: "sigtran" <[email-masked]>
Subject: Re: M2UA: Draft 7 - Relationship between SG/AS/ASP/MGC
X-SMTP-HELO: ind.alcatel.com
X-SMTP-MAIL-FROM: [email-masked]
X-SMTP-RCPT-TO: [email-masked]
X-SMTP-PEER-INFO: postal.xylan.com [208.8.0.248]
X-Orig: <[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

I have questions about the M2UA document also, relating to these topics.

  1. Ken's reply indicates:
     "Again, a bit of the shared "generic" UA text causing a problem.  There
     can be more than one AS per SG (I would suggest that it would be
     an unlikely scenario), but there should not be more than one AS
     supported by an ASP (single association cannot support more than
     one AS).  "
     My understanding is that there can be one association between an MGC
and SG.
     Now given that there CAN  be more than one AS per SG, it implies that
     there can be more than one AS supported by a given association.
     A message is directed to a given AS/ASP based on the interface IDs.
     Now this might not be a likely scenario, but it does not contradict
     any clause in the standards.

  2. The ASP-ACTIVE, ASP-INACTIVE, ASP-ACT-ACK and ASP-INACT-ACK messages
     all have optional parameters as list of identifiers.  Under what
     scenario would these messages contain a list of identifiers ?

  2b. The above question is important in the light of text in para 3.3.2.5
      " If only a subset of Interface Identifiers are included, the ASP is
        noted as Active for all the Interface Identifiers provisioned for
that
        AS."

  Thanks

Neeraj Gupta & Laurent Brard

Ken Morneault wrote:

> Mark,
>
> Pls see comments below.
>
> Regards,
>
> Ken
>
> At 12:10 PM 5/11/01 +0100, you wrote:
> >Hi,
> >
> >I need some clarification of the relationships between the various
> >entities.
> >
> >1) How many ACTIVE ASP's can there be per AS?
>
> M2UA only allows for Override (one Active ASP).
>
> >Although section 1.3.4 (2nd para) clearly states that "One or more
> >ASP's in the list are normally active" there are several statements
> >in the spec that suggest otherwise. These are:
> >
> >- Section 1.3.4 last para. The use of a 1 + k redundancy model
> >suggests 1 active ASP and k inactive ASP's.
>
> One disadvantage of sharing text between UAs is that it
> is not always generic.  This is one such case.  I will
> correct this text.
>
> >- Section 1.5.2 second para, second sentence "... which ASP is
> >currently active." The use of the singular suggests only 1 ASP can
> >be active.
> >
> >- Section 4.3.3.4 last para. This suggests that only 1 ASP can be
> >active per AS.
>
> >2) How many AS's can there be per SG?
> >
> >There are a number of statement in the spec that suggest that there
> >may be more than 1 AS per SG. These are:
> >
> >- Section 4.3.3.2 first para. This paragraph talks about sending a
> >single ASP Down message to a single SG to remove the ASP from all
> >AS's of which it is a member. This suggests that there can be more than
> >one AS per SG and perhaps more alarmingly that they share a single
> >SCTP association!
> >
> >- Section 4.3.3.4 first para. This states that a ASP can be registered
> >to more than one AS but share a SCTP association. Thereby implying
> >multiple AS's on a single SG.
>
> Again, a bit of the shared "generic" UA text causing a problem.  There
> can be more than one AS per SG (I would suggest that it would be
> an unlikely scenario), but there should not be more than one AS
> supported by an ASP (single association cannot support more than
> one AS).
>
> >3) How many ASP's per MGC can there be?
> >
> >On the basis of the ambiguity outlined in 1) and 2) I'd like to know
> >how many ASP's per MGC there can be?
>
> More specifically, I think you want to know how many ASPs a MGC
> would support for a single SG?
>
> The draft does not impose a limitation.  However, it would be
> unlikely that a SG would be configured such that the MGC would
> need to support more than one ASP.
>
> >Whatever the answers to the above the spec would benefit from a couple
> >of unambiguous statements to clarify 2) and 3).
>
> no doubt!
>
> >Cheers,
> >Mark
> >
> >
> >
> >---
> >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]

Attachment Converted: "c:\program files\qualcomm\eudora
pro\attach\laurent.brard.vcf" ---
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, 30 May 2001 12:12:51 -0400
To: "sigtran" <[email-masked]>
From: Ken Morneault <[email-masked]>
Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
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]
List-Unsubscribe: <mailto:[email-masked]>
Reply-To: [email-masked]

Brian's comments just scratch the surface of what a SG would need to do, not
to mention the SG/ASP coordination.  Do we try to specify everything or make
a blanket statement and leave it up to implementers?

Ken

At 10:08 AM 5/30/01 -0500, Heinz Prantner wrote:
>Ken,
>
>see below...
>
>Heinz
>
>----- Original Message -----
>From: Ken Morneault <[email-masked]>
>To: sigtran <[email-masked]>
>Sent: Wednesday, May 30, 2001 7:02 AM
>Subject: Re: SCON from ASP (Re: Final report from the Interop Test)
>
><snip>
>
>
>However, I never
>thought the Sigtran group would be able to specify the SG
>behavior in a RFC to this detail.
>
>[HP] seems like an Applicability Statement would be appropriate (just cut
>and paste Brians comments into it...)
>
>
>
>---
>You are currently subscribed t