Subject: Re: M3UA: Packing of Routing Label into DATA Payload

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 22:55:12 -0500

Greg,

I agree with Kurt, I was just trying to strike a compromise.

If Routing Context is included in DATA messages as proposed
for other implementation reasons, the ASP M3UA will never
have to apply a Routing Key to the DATA payload.  As a result,
the only impediment to the ASP M3UA being completely variant
neutral is the packing of the DATA payload.  An ASP M3UA
would need to unpack the routing label from the DATA payload
to pass the unpacked parameters in the MTP-TRANSFER primitive
to the MTP-User.  To do this, it will need to know the
variation of the MTP Routing Label.  Protocol Data 1 and Data
2 does not give this distinction for anything but TTC.

Rather than having the ASP M3UA try to deal with every possible
combination of routing label, if the routing label is unpacked
by the SG into a variant neutral structure, then the ASP M3UA
will not have to examine the DATA payload and can pass it
untouched to the MTP-User in the Data parameter of the
MTP-TRANSFER primitive.  This would increase interoperability
by permitting an ASP M3UA implementation to support routing
label formats of which its implementers were not aware at the
time that it was developed.  The exact format of point codes
would be understood by AS (MTP-User) and SG (MTP-Provider)
and the ASP M3UA implementation which merely transports the
interface need not know about routing label formats.

The simplicity of this is demonstrated by the fact that TTC
is also implicitly accomodated by this approach.  Any variation
on RL format similar to TTC in the future would also be implicitly
accomodated.  Because there are spare bits in the RL which are
reserved for national use, and national variants can determine
their own RL format, a new national variant could otherwise cause
all of the ASP M3UA implementations to be rewritten to accomodate
a new bit positioning.

Unpacking and normalization of the contents of the Routing
Label into MTP-TRANSFER parameters increases interoperability
and decreases the burden on the ASP M3UA implementer.  The
SG implementation is unaffected because the SG must know the
format of the RL anyway to perform necessary MTP functions
and performing the normalization into parameters is trivial.

Coupled with the Routing Context in the DATA message, this
format permits the ASP M3UA to be both RK and RL neutral
preserving the concept of M3UA as a pure transport that doesn't
muck around with what it is transporting.

If the Network Appearance discussion results in RC being added
to SNMM messages, network appearance can go back to being
Network Id and passive monitoring devices will be able to
determine the structure of the rest of the message.  Network
Appearance, however, would no longer be required in DATA
messages, but could be optionally added when permitting
passive monitoring is required.

(These implementation issues are all related...)

I would therefore like to propose (again) that the Data Payload
3 format proposed be the only Data Payload format.

(We might still want to embed Network Id as the high byte in
the point codes and get rid of Network Appeance altogether!)

--brian

Kurt Kite wrote:                                  (Thu, 02 Aug 2001 12:00:23)
>
> Hi Greg,
> 
> I don't think that we should add another protocol data format. We should
> agree on which one is better and use that one.
> 
> The second format was added to support Japanese MTP. Brian's proposal
> is just different, i.e., it does not add any functionality to the protocol.
> If Brian's proposal is added to the protocol I think that implementations
> will support one or the other.
> 
> I think Brian's proposal has advantages over the current scheme, so I would
> opt for that one.
> 
> /Kurt
> 
> 
> 
> 
> Greg Sidebottom wrote:
> 
> > Hi Brian,
> >
> >   Looks like a viable compromise to me.
> >
> >   Everyone, I haven't seen any follow-ups disagreeing - do we have consensus
> > on this?
> >
> > Cheers
> >
> >    Greg Sidebottom
> >
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "sigtran" <[email-masked]>
> > Cc: "Greg Sidebottom" <[email-masked]>
> > Sent: Friday, July 27, 2001 1:25 AM
> > Subject: Re: M3UA: Packing of Routing Label into DATA Payload
> >
> > > Greg,
> > >
> > > Perhaps we can hit a compromise on this issue.  Perhaps we could add a
> > > Protocol Data 3 format (to the other 8 or so formats under Protocol Data
> > > 1) which would be an "unpacked" format.  Then an SGP/ASP combination
> > > could use the most efficient format given local implementation
> > > considerations.  Following is proposed text:
> > >
> > > --brian
> > >
> > > *** m3ua-08.rcmods Thu Jul 26 23:40:02 2001
> > > --- m3ua-08.plmods Fri Jul 27 00:17:56 2001
> > > ***************
> > > *** 1739,1744 ****
> > > --- 1739,1745 ----
> > >            0x020a        Local_Routing Key Identifier
> > >            0x020b        Destination Point Code
> > >            0x020c        Service Indicators
> > > +          0x020d        Protocol Data 3
> > >
> > >
> > >   Sidebottom et al                                             [Page 31]
> > > ***************
> > > *** 1790,1796 ****
> > >
> > >        Network Appearance       Optional
> > >        Routing Context          Optional
> > > !      Protocol Data 1 or 2     Mandatory
> > >
> > >
> > >
> > > --- 1791,1797 ----
> > >
> > >        Network Appearance       Optional
> > >        Routing Context          Optional
> > > !      Protocol Data 1, 2 or 3  Mandatory
> > >
> > >
> > >
> > > ***************
> > > *** 1879,1885 ****
> > >
> > >   Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> > >
> > > ! Protocol Data 1 or 2: variable length
> > >
> > >      The Protocol Data 1 parameter contains the original SS7 MTP3
> > >      message, including the Service Information Octet and Routing Label.
> > > --- 1880,1886 ----
> > >
> > >   Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> > >
> > > ! Protocol Data 1, 2 or 3: variable length
> > >
> > >      The Protocol Data 1 parameter contains the original SS7 MTP3
> > >      message, including the Service Information Octet and Routing Label.
> > > ***************
> > > *** 1971,1977 ****
> > > --- 1972,2032 ----
> > >
> > >       * marks LSB of each field;  @ = OPC SP MSB;  $ = OPC region MSB
> > >
> > > +    The Protocol Data 3 parameter contains all the information in
> > > +    Protocol Data 1 and 2 as described above, but the Routing Label
> > > +    contents are unpacked and the Payload Data field contains the
> > > +    MTP-User protocol data starting immediately after the Routing Label.
> > > +
> > > +    The Protocol Data 3 field format is as follows:
> > > +
> > > +      0                   1                   2                   3
> > > +      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > > +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > +     |                    Originating Point Code                     |
> > > +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > +     |                    Destination Point Code                     |
> > > +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > +     | Service Ind.  | Msg. Priority |   Signalling Link Selection   |
> > > +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > +     /                                                               /
> > > +     \                           Protocol                            \
> > > +     /                             Data                              /
> > > +     \                                                               \
> > > +     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > +
> > > +    Originating Point Code: 32 bits (unsigned integer)
> > > +    Destination Point Code: 32 bits (unsigned integer)
> > >
> > > +       The Originating and Destinration Point Code fields contains the
> > > +       OPC and DPC from the routing label of the original SS7 message in
> > > +       Network Byte Order, justified to the least significant bit.
> > > +       Unused bits are coded `0'.
> > > +
> > > +    Service Indicator: 8 bits (unsigned integer)
> > > +
> > > +       The Service Indicator field contains the SI field from the
> > > +       original SS7 message justified to the least significant bit.
> > > +       Unused bits are coded `0'.
> > > +
> > > +    Message Priority: 8 bits (unsigned integer)
> > > +
> > > +       The Message Priority field contains the MP bits (if any) from the
> > > +       original SS7 message, both for ANSI-style and TTC-style message
> > > +       priority bits.  The MP bits are aligned to the least significant
> > > +       bit.  Unused bits are coded `0'.
> > > +
> > > +    Signalling Link Selection: 16 bits (unsigned integer)
> > > +
> > > +       The Signalling Link Selection field contains the SLS bits from the
> > > +       original SS7 message justified to the least significant bit and in
> > > +       Network Byte Order.  Unused bits are coded `0'.
> > > +
> > > +    Protocol Data: (variable)
> > > +
> > > +       The Protocol Data field contains a byte string of MTP-User
> > > +       information from the original SS7 message starting with the first
> > > +       byte of the original SS7 message following the Routing Label.
> > > +
> > >
> > >   3.4 SS7 Signalling Network Management (SSNM) Messages
> > >
> > >
> > > Brian F. G. Bidulock wrote:                               (Mon, 23 Jul
> > 2001 10:15:23)
> > > > Benjamin,
> > > >
> > > > Please see comments below...
> > > >
> > > > Benjamin J. Wilson wrote:                (Mon, 23 Jul 2001 09:55:42)
> > > > > Brian, Greg,
> > > > >
> > > > > On Mon, 23 Jul 2001, Brian F. G. Bidulock wrote:
> > > > > > Greg,
> > > > > >
> > > > > > As this issue of packing routing labels into data payloads
> > > > > > hasn't been resolved yet (I am staring incredulously at the code
> > > > > > that I am writing), I would like to take another stab at NOT
> > > > > > putting the routing label information in the DATA payload.
> > > > > >
> > > > > > The reasons (with a number of new ones are):
> > > > > >
> > > > > > 1.  The ASP must know the SS7 bit-coding of the routing label
> > > > > >     for each variant of SS7 just so that it can send a DATA
> > > > > >     message.  When a new one is created, all ASP code for M3UA
> > > > > >     which supports the new variant will need to be updated.
> > > > >
> > > > > Not disagreeing, but if you add RC to the DATA message wouldn't that
> > > > > be enough to help the ASP interpret the encoding of the routing
> > > > > label?
> > > >
> > > > The ASP can interpret the encoding of the routing label implicitly
> > > > or from the Network Appearance without Routing Context.  Routing
> > > > Context is needed in DATA message for identifying and demultiplexing
> > > > traffic flows.
> > > >
> > > > What I was trying to get at here, was that with the RL in the payload,
> > > > the ASP needs to know all these national variants of RL formats.
> > > > Consider that if the routing label was in parameters, the draft would
> > > > not even have to mention ANSI vs ETSI formats, and the ASP would not
> > > > need to know either.  If the difference in variants can be removed
> > > > from the ASP M3UA, variants information can be left to the MTP-User
> > > > at the ASP (such as ISUP).  And the MTP-User is "outside" of the
> > > > M3UA ASP.  Probably up in application space where code can be a
> > > > little more flexible.
> > > >
> > > > >
> > > > > (Thinking out loud).  I guess that is only true when
> > > > > Maria-Cruz's comment that "A RK cannot span more than one NA" is taken
> > > > > into account".  I thought this fact was actually detailed in the
> > > > > definition of a Routing Key in the latest M3UA spec.  If my
> > understanding
> > > > > is correct ONE RC is associated with ONE RK which is associated
> > > > > to ONE DPC which appears in ONE NA.
> > > >
> > > > It is start to seem like a strage restriction.  1:1:1:1 mappings are
> > > > not terribly useful.  Can anyone think of a reason why this shouldn't
> > > > be an k:l:m:n (or whatever) mapping?
> > > >
> > > > >
> > > > > Once you allow a RK to span NAs (with potentially different MTP
> > flavors)
> > > > > and use a RC to describe this RK.  Then the ASP still has to
> > understand
> > > > > 2 different types of point codes.  The DPC/OPC parameters that are
> > > > > created to support the new DATA message would need to contain some
> > > > > type id (24 bit, 16 bit, etc.).
> > > >
> > > > This is the normal use of the Network Appearance.  When it is required
> > > > in the DATA message, Nework Appearance could still be included.
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> >
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to [email-masked]
> 
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

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

---

From: Ken Morneault <[email-masked]>
Date: Mon, 13 Aug 2001 08:59:22 -0400

I also agree with Kurt that we do not need any more optional
parameters to the protocol.  We should weigh the advantages
of Brian's proposal against limiting changes to the protocol
and make a decision. 

Ken

At 10:55 PM 8/9/01 -0500, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 18:28:35 -0500

Greg,

Can we also add RC as an OPTIONAL parameter to the DATA
messages which MAY be included.  The idea being that the
parameter MAY be included by SG implementations to
permit ASP implementations to be RK neutral.

With that addition of RC as optional to DATA, I'm done
on the issues of NA and RC.

--brian

Brian F. G. Bidulock wrote:              (Thu, 09 Aug 2001 22:55:12)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 18:24:43 -0500

Greg,

As there has been no objections to this proposal
or Kurt's proposal in close to a month, can we
collapse Protocol Data to only follow the Protocol
Data 3 form?

--brian

Ken Morneault wrote:               (Mon, 13 Aug 2001 08:59:22)

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

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 09:02:38 -0400

Greg,

I object to including Protocol Data 3 format as proposed by Brian even as 
an option. M3UA should not touch any of the routing fields, and the 
receiver of the data message doesn't need to look at any of the routing 
fields. Only the sender must peek at the routing fields, to decide to 
which ASP or SGP to send the DATA message.

The routing fields are an integral part of the MTP3 signaling as defined 
in Section 1.3.2.1 (Support for the transport of MTP3-User Messages), and 
should not be touched by the M3UA layer:

"... the User Part messages received from the SS7 network by the SG are 
not re-encoded into a different format for transport between the M3UA 
peers. The MTP3 Service Information Octet (SIO) and Routing Label (OPC, 
DPC, and SLS) are included, encoded as expected by the MTP3 and MTP3-User 
protocol layer."

Section 3.3.1 states: "The DATA message contains the SS7 MTP3-User protocol data, which is an MTP-TRANSFER primitive, including the complete MTP3 Routing Label." This emphasizes that the DATA message is simply a wrapper around the 
untouched MTP-TRANSFER primitive.

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

"Brian F. G. Bidulock" <[email-masked]>
08/14/01 07:24 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc:     Greg Sidebottom <[email-masked]>
        Subject:        Re: M3UA: Packing of Routing Label into DATA Payload

Greg,

--brian

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

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 08:36:31 -0500

Barry,

[email-masked] wrote:                (Wed, 15 Aug 2001 09:02:38)
> which ASP or SGP to send the DATA message.

Then you must agree with placing RC in the DATA message for multiple AS?
--without it, the M3UA at the ASP is forced to examine the RL to decide
for which AS the message belongs.  We wouldn't want M3UA examining the
Routinging Label (applying the RK) to determin this. ;)

Besides, M3UA does not examine the RL to make Protocol Data 3, Protocol
Data 3 is the natural form of the MTP-TRANSFER primitive as described
in Q.700 etc., Protocol Data 1 and 2 are not.

> DPC, and SLS) are included, encoded as expected by the MTP3 and MTP3-User 

The above statement is only an extension of the Protocol Data 1 and 2
concepts, which have the obvious flaw that the approach make M3UA protocol
variant sensitive (as is obvious from the need for a TTC protocol data
at all).

> 
> Section 3.3.1 states: "The DATA message contains the SS7 MTP3-User protocol
> data, which is an MTP-TRANSFER primitive, including the complete MTP3
> Routing Label." This emphasizes that the DATA message is simply a wrapper
> around the untouched MTP-TRANSFER primitive.

The quotes you give are merely the definitions for Protocol Data 1 and 2.

Barry, please present an argument which addresses the rather lengthly
discussion on this matter.

We have already agreed to a Protocol Data 3 as a compromise to drawn
out previous discussion.  I merely reopened the question as to whether
Protocol Data 3 should replace 1 and 2 per Kurt's suggestion, not whether
Protocol Data 3 should be included.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 15 Aug 2001 07:45:21 -0700

What is your problem with looking at the RL?  Any receiving node must look
at the RL to do the discrimination function (i.e., is it mine or not).  This
is expected!!!  If the node supports multiple PCs, then a distribution
function is also needed, BUT this is a local implementation issue.  The RL
is there, use it. Stop making up excuses that you need the same information
in other parameters so that your implementation has an easier time in
processing the messages.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 8:37 AM
> To: sigtran
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 13:44:12 -0400

Brian,

1. The ASP _is_ the AS, thus it doesn't have to route to multiple ASs.
2. There has been no consensus expressed to include your suggested new 
Data message format, and I still object to its inclusion at all, even as 
an option.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/15/01 09:36 AM

        cc: 

Barry,

[email-masked] wrote:                (Wed, 15 Aug 2001 
09:02:38)

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 13:27:07 -0500

Barry,

I disagree with Protocol Data 1 and 2.  They were never
given working group approval, nor was the "packed" decision
ever vetted through the working group.  It was a decision
made autonomously by the authors of M3UA before it became
a WG item.  It was a bad decision for many reasons cited.
Please reference the previous thread leading back on this
topic.  If Protocol Data 3 is not included, I cannot agree
with Protocol Data 1 or 2 being included either.

--brian

[email-masked] wrote:                (Wed, 15 Aug 2001 13:44:12)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 07:55:06 -0700

It's a sad day when your node does not know what type of network it is
connecting into.  Protocol/variant is an attribute of the
stack/routes/linksets/links and how I decide to map this to associations is
my problem.

The M3UA will be configured (along with the rest of the stack) to know what
protocol it is handling.  My M3UA will put together SS7 messages that are
required by the network I am connected to and will stuff the SS7 messages
into the DATA messages.  If its Japan, Data 2 will be used (but we may make
this a configurable option).  We will use PCs that the network operator
configures for our node and the other remote nodes.  Remote PCs will be
assigned to routes as they are today.  In my view and the network operator
view, IP is just the transport. 

> Sent: Wednesday, August 15, 2001 2:21 PM
> To: sigtran
> Hi John,
> I'm interested to know just what were you going to put
> in the RL in the IPSP case:  Which national variant would
> one use?  Would one include MP bits, or not?  Should it
> be Data 1 or 2?  What are you going to use for a point
> code in the IP domain?
> 
> --brian
> 
> John Schantz wrote:                              (Wed, 15 Aug 
> 2001 07:45:21)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 10:55:35 -0500

John,

What I meant was when the IPSPs are running completely and
only in the IP domain: with no attachment to an external
legacy SS7 network.  Just two or more IPSPs in the IP network.
No SS7 nodes.  What will one put in the RL?

--brian

John Schantz wrote:                             (Thu, 16 Aug 2001 07:55:06)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 09:12:23 -0700

I think I will still be using PCs since I will still have an
SCCP/TCAP/etc./appl. setting on top of M3UA.  I am considering IP as just a
new transport for SS7.

> Sent: Thursday, August 16, 2001 10:56 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Aug 2001 12:18:57 -0500

John,

Are you saying that in the all IP domain there is still a need
for SS7 numbering authorities and PC assignment administration
and restricted point code numbering spaces?  That I have to go
talk to ANSI T1 or Telcordia or someone before I can assign an
ANSI PC to my all-IP node even though I don't have to talk to an
SS7 network?  Or, are you suggesting that someone form a
numbering administration to assign these point codes to be used
completely in the IP domain?

I'm thinking that it would be far more natural and require zero
additional administration to use an IPv4/v6 address instead of
the point code in an all IP network.

But, there is just no way to pack an IPv4/v6 address into a
routing label, now is there.  If the RL is unpacked, the
defintion of OPC and DPC could be expanded to include IPv4/v6
address.  Because the existing MTP-Users provide the OPC and DPC
as separate arguments of the MTP-TRANSFER primitives (and most
are aligned in a 32-bit field), IPv4 address instead of point
code should have minor (if any) impact on the MTP-User
application.

--brian

John Schantz wrote:                                          (Thu, 16 Aug 2001 09:12:23)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 11:18:31 -0700

I don't think you are going to see PCs disappear for a very long time.  I
think both you and I will have retired before it will happen.  Maybe by that
time there will be a coordinated proposal for all "parts" of the stack to is
IPv6 addresses.  Proposing to do it in only part of the stack is a wasted
effort. 

> Sent: Thursday, August 16, 2001 12:19 PM
> To: sigtran

---

---

From: Jeff Copley <[email-masked]>
Date: Tue, 21 Aug 2001 16:44:16 -0500

Brian,

I agree with John.  Yes, the ultimate goal may be to use the most
economical infrastructure, but the current one isn't going away for some
time.  We are faced with trying to implement these new protocols in a
manner that gracefully works with our legacy networks.  Right now, IMHO,
using point codes makes for the easiest interworking (non-backhaul).  We
also know what protocol variant we are dealing when a message is
received.

As for the number authorities, I think you know how this really works.

Jeff

"Schantz, John" wrote:
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 17:55:50 -0500

Jeff,

Where does IPSP interworking to SCN appear in the SIGTRAN
architecture?  I see AS/SG backhaul configurations with
interworking and IP domain IPSP configurations without
interworking, but I don't see IPSP configurations with
interworking?  Could you point to the section or diagram
of the SIGTRAN architecture RFC which provides for IPSP
configuration *with* SCN interworking?

I think that IPSP *with* SCN interworking is just an inferior
way of performing backhaul, and an inferior method which is
not even provided for in the SIGTRAN architecture.

Please correct me.

--brian

Jeff Copley wrote:                             (Tue, 21 Aug 2001 16:44:16)

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

---

---

From: Jeff Copley <[email-masked]>
Date: Wed, 22 Aug 2001 08:37:11 -0500

Brian,

You don't think we'll want to interwork with legacy networks?  Are you
saying we will just cut over someday?

Jeff

---

---

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

Jeff,

Did I miss your reference to the place in the SIGTRAN
architecture where IPSP was shown interworking with SCN? ;)

SS7 signalling doesn't have a place inside the IP network,
the IP network is just being used to transport it.

The backhaul case permits an MGC to talk to legacy devices
in the SS7 network.

The non-backhaul case permits legacy devices to talk to one
another across the IP network using IP as transport.

In the M3UA non-backhaul case there is no need for IPSPs
with transfer functions: MTP3-User to MTP3-User transport
is provided by the IP network.

This IPSP as multiple SG/STP is some mutant combination
between the backhaul and non-backhaul cases.  What is its
purpose?  If you have MGC talking to SG, backhaul will do.
If you have legacy SP talking to legacy SP across an IP
network, IPSP will do.

Why does one need multiple IPSP/SG/STPs?

--brian

Jeff Copley wrote:                                           (Wed, 22 Aug 2001 08:37:11)

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

---