Subject: SUAv8, M3UAv9: IPSP Handling

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 13 Oct 2001 18:23:16 -0500

Section 4.3.4.1.2 IPSP Considerations describes a single-ended
ASPUP and ASPAC procedure.  Althought I prefer the single-ended
approach, I thought that a large number of people wanted a
symmetrical approach to IPSP to IPSP management.

Both M3UA and SUA drafts have IPSPs split between the ASP role
and the SGP role.  This raised considerable technical concerns
with regard to the placement and operation of state machines
associated with providing MTP3 or SCCP services to the MTP-Users
and SCCP-Users thus represented at both ends.  While in the
SGP/ASP case, it is clear that MTP3 and SCCP services (and
state machines) are resident to the SGP, it is still completely
unclear in the IPSP case.  If these state machines and services
are to be partitioned between IPSPs, interoperability clearly
demands that the partitioning be described.

This was a last call issue both for SUA and M3UA and has not
yet been addressed in the drafts.

Could we please at least address the last call issues before
attempting to move the drafts to the IESG?

--brian

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

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

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 15 Oct 2001 11:52:38 -0700 (PDT)

Brian,

This is a fair point, and Javier has been working
on some text on IPSP-to-IPSP.  I asked him to hold
off on M3UAv9 in the interests of getting
text out quickly.

For the next version, we have a choice to either
try and incorporate this into the main text or
move this work to an extension draft.  My 
preference would be to define an extension, 
since it seems like a significant amount of work
to incorporate, whereas most of the other comments
look fairly easy ("may" for "SHOULD", etc.)

Comments?

Cheers,

L. Ong 

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> You are currently subscribed to sigtran as:
> [email-masked]
> To unsubscribe send a blank email to
[email-masked]

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 15 Oct 2001 14:20:36 -0500

Lyndon,

If it is moved to an extension draft, can we remove references
to the, then, unsupported IPSP?  The extension draft can define
the terminology as well.

This was discussed with the original issue: either define IPSP
to IPSP operation or remove it from the draft.  John assured us
that we need not discuss it any further, because he was working
with Janvier and Greg and had text in hand.  That text has not
been forthcoming, so please remove IPSP from both drafts.

Basically just remove the definition for IPSP, all occurences of
SGP or IPSP reduce to SGP, all occurences of ASP or IPSP reduce
to ASP.  And several examples and IPSP considerations paragraphs
in section need to be removed.

In SUA, because IP addresses in GT are only used for IPSP and are
not used for either SGP or ASP, please also remove the IP addressing
from the SUA GT.  Also remove reference to SUA-Users as distinct
from SCCP-Users as where there is no IPSP operation there are no
SUA-Users.

These were also issues at Last Call with SUA in relation to IPSP
operation.  If IPSP operation is not included in the draft, then
all this IPSP cruft which has no use in SGP/ASP operation should
be removed to the extension draft.

Thank you.

--brian

Lyndon Ong wrote:                      (Mon, 15 Oct 2001 11:52:38)
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 16 Oct 2001 09:51:37 +0200

Brian,

In my opinion, leaving the IPSP case out of the draft paves the
way for unaddressed issues and interactions. On the other hand,
if you leave the IPSP case in the original text, you already
have all the items you want to think about, and for future M3UA
revisions the IPSP case will also be considered. It may seem 
clumsy now but in the long run I believe it will be easier to
manage. Especially if you want to address both M3UA and SUA in one
draft.

While I'm at it, I think either side of the IPSP should be allowed
to start the ASPs and activate the AS. Which ever side ready 
should send these messages, the behavior is symmetrical. 
Acceptance by the peer is given by the Acks.
More generally, the IPSP behavior seems to follow pretty much the
ASP behavior, but it also has the AS and AS-per-ASP state machines
like an SG.

At least the following issues should be addressed (described and
left implementation dependant or mandated by the draft):

-symetry wrt to ASPSM and ASPTM vs client/server role (who sends
ASPSM and ASPTM)
-symetry wrt to registration (if both ends want to use Routing Keys
do they both need to send REG messages)
-RC applies to both directions vs single direction
-description of the transfer function at an IPSP/SS7, IPSP/SG,
and IPSP/IPSP gateway
-where do state machines for MTP3 and User Parts fit in the
IPSP model
-where do the AS and AS-per-ASP state machines fit in the IPSP
model (both ends would be logical if symmetric roles are adopted)
-description of the IPSP/SG mgt gateway (e.g. mapping between ASPTM
or SSNM messages from SG and SSNM messages to IPSP)
-description of the IPSP/SS7 mgt gateway (e.g. mapping between SS7
messages and SSNM messages to IPSP, interactions like MTP Restart)
-description of the IPSP/IPSP mgt gateway (how is management handled 
when several SPMC are hosted in a single IPSP for example)
-does the RK stay the same for IPSP or should it include parameters
like IP address that allow to locate the IPSP more naturally than a
fake PC in a pure IP network?

Any comments?
Francois.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, October 15, 2001 9:21 PM
> To: sigtran
> Cc: [email-masked]
> Subject: Re: SUAv8, M3UAv9: IPSP Handling
> 
> 
> Lyndon,
> 
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 03:09:41 -0500

Francois,

I like your list of issues.  Yes, I would also like to see these
addressed in the drafts.  That is why I raised the original IPSP
issue in last call.  The things you list are very unclear in the
existing text (in which IPSP is used interchangeably with ASP in
some circumstances and strangely SGP in others).

I would like to see the IPSP addressed in the SUA and M3UA drafts
before they go to IESG because the issue was raised as a Last
Call item that should have been resolved at Last Call.

If, however, IPSP is not going to be addressed (at least the issues
on your list), and is going to be deferred to and extension draft
as per Lyndon's suggestion, IPSP should be removed from the drafts.

So, the question is: is IPSP considerations going to be properly
addressed in the M3UA and SUA drafts before moving forward to IESG?
Or, should they be removed and deferred to extension drafts?

IPSP simply cannot stand as it is.  It is far to vague, yet would
confuse the reader of an extension draft.

--brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Tue, 16 Oct 2001 09:51:37)

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 16 Oct 2001 11:00:32 +0200

Hi, 

I don't agree on moving the IPSP cases to another document. One of the main purpose for these protocols is to be valid to be used by the 3GPP architecture (3rd generation). The main scenarios in that architecture include IP to IP communication. If we simply publish the AS-SG cases they would not be able to use M3UA or SUA and we would be making a protocol for nothing.

IPSP cases are more or less explained in the current draft. I agree with Brian that they are not pretty clear and that the confussion arise with the comparison with the ASP or SGP depending on the case. (talking about M3UA)

But from my point of view, having a separate sections for IPSP cases is not a hard work, it is only explaining the SG-AS scenario with IPSP words and addapt what is needed with explicit words, not leaving it to imagination.

The rework, has not been included in the current draft due to the time shortage, but, for sure, it will be added in the next version. The main objective of M3UAv09 was to have an intermediate draft to clarify some of the concepts that already were discussed on the list but not all of them. IPSP belongs to the second group.  :-D. 

Cheers // Javier.

> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 04:24:55 -0500

Javier,

Good.  Please resolve M3UA Issue 11 and SUA Issue 17 before attempting
to move a draft forward to IESG, either by crystalizing the IPSP operation
a bunch more (Francois has a good list), or removing it.

When can we expect to see it addressed in a draft?

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 16 Oct 2001 11:00:32)
>
> Hi, 
> 
> I don't agree on moving the IPSP cases to another document. One of the main
> purpose for these protocols is to be valid to be used by the 3GPP
> architecture (3rd generation). The main scenarios in that architecture
> include IP to IP communication. If we simply publish the AS-SG cases they
> would not be able to use M3UA or SUA and we would be making a protocol for
> nothing.
> 
> IPSP cases are more or less explained in the current draft. I agree with
> Brian that they are not pretty clear and that the confussion arise with the
> comparison with the ASP or SGP depending on the case. (talking about M3UA)
> 
> But from my point of view, having a separate sections for IPSP cases is not
> a hard work, it is only explaining the SG-AS scenario with IPSP words and
> addapt what is needed with explicit words, not leaving it to imagination.
> 
> The rework, has not been included in the current draft due to the time
> shortage, but, for sure, it will be added in the next version. The main
> objective of M3UAv09 was to have an intermediate draft to clarify some of
> the concepts that already were discussed on the list but not all of them.
> IPSP belongs to the second group.  :-D. 
> 
> 
> Cheers // Javier.
> 
> 
> 

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 16 Oct 2001 11:22:31 +0200

Hi Brian, 

As soon as we feel that the technical issues are clear. Hopefully before Christmas time...  ;-)

Cheers // Javier.

> Sent: Tuesday, October 16, 2001 11:25 AM
> To: sigtran

---

---

From: [email-masked]
Date: Tue, 16 Oct 2001 20:49:54 +0300

Hi Brian & Lyndon,

> been forthcoming, so please remove IPSP from both drafts.

The signaling from IPSP to IPSP in SUA has always been a key
part of the specification. If you still feel this is not 
sufficient, then I shall strive to produce something shortly
to meet your needs.
 
> in section need to be removed.

Brian,  essentially, I've considered the IPSP-IPSP signaling case
as a sort of ASP to ASP signaling (which I feel is analagous) to
ASP to SGP signaling, when the user message is consumed at the SGP
and the signaling is termated at the SG (i.e. - not forwarded into
the SS7 network).  Please note, this is a key requirement from
the groups intending to use M3UA & SUA.  It is not sufficient to
remove this from either M3UA or SUA.
 
> If IPSP operation is not included in the draft, then

You are being inconsistant here.  There have been issues raised
about broadcast mode, which you have promoted.  You have requested
that certain text remain in M3UA & SUA, because of a pending
extension draft.  The working group has been quite open to
your requests & needs - I request the same courtesy from you.

best regards,
John

---

---

From: [email-masked]
Date: Tue, 16 Oct 2001 20:50:05 +0300

Hi Brian,

> demands that the partitioning be described.

I will revist this in more detail - but I will say that the exact
nature of the SCCP state machines within an SUA layer at an IPSP
is an implementation issue.  If you feel that the SCCP services which
an SUA implementation provides for its users is lacking, I shall
try to more clearly state this.

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:08:21 -0500

John,

John Loughney wrote:                                         (Tue, 16 Oct 2001 20:49:54)
> sufficient, then I shall strive to produce something shortly

SUA Last Call Issue 17.

> remove this from either M3UA or SUA.

Ok.  Let's try to address Francois' list on this thread.  It is a
pretty good list of descriptions which are missing for IPSP.

> about broadcast mode, which you have promoted.

I think we were talking about SHOULD or MUST in a localized area of
the text, not strewn throughout the text and examples impinging on
almost every requirement as does IPSP.

> You have requested that certain text remain in M3UA & SUA, because
> of a pending extension draft.  The working group has been quite
> open to your requests & needs - I request the same courtesy from you.

I'm just impatient.  You asked us to stop discussing IPSP operation
on the list over a month ago because you would have proposed text
over the weekend.

Please: let's include IPSP in the main draft, but let's describe
it fully.  As it stands it is next to impossible to implement
interoperable IPSP operation in both M3UA and SUA.

As it stands M3UA Issue 11 and SUA Issue 17 have not been addressed.
That issue discussed either removing IPSP or describing it.  Let's
describe it!

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:30:56 -0500

John,

In IPSP operation there are no SCCP state machines as there is
not SCCP as there is at an SGP.  The draft needs to describe
how SUA goes about providing SCCP services to the SCCP-User
using SUA messages and SCTP facilities.  Right now it is very
unclear which services are provided locally and which are
provided remotely and how.  Whether SUA messages correspond
to primitives in the IPSP case as they do in the ASP case or
whether they correspond to SCCP PDUs.  If they correspond to
SCCP PDUs, the SCCP state machines will be required.  Which
is it?

--brian

John Loughney wrote:                                         (Tue, 16 Oct 2001 20:50:05)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 17 Oct 2001 12:09:31 +0200

Brian,

If SUA is to provide the same services as SCCP to its users (or so we
claim), it is clear to me that any resources, state machines etc need to be
provided in SUA (e.g. CO state machines, segmentation queues, ...) to do
this. This is true for the IPSP case (SUA PDUs == SCCP PDUs) as well as for
the SG-ASP case.

The only thing that makes the SUA on the SG special, is it's interworking
with legacy SCCP (modelled via the NIF); and we try to hide as much as
possible of SCCP variants at this point.

And of course each SUA has to maintain the necessary routing information :
- on the ASP to select SG/SGP for an available route to an available SS7
destination
- on the SG to select AS/ASP based on RK parameters and availability
- on IPSP to select another IPSP based on RK parameters and availability
This is the same for M3UA.

As such, the ASP-SUA should see the SG-SUA as a relay point/interworking
point with no "real" SCCP-users. Peer-to-peer (end-to-end) communication is
between SS7 SEP and ASP. In all-IP case, one might also have SUA-relay
points without real users, with the single purpose of forwarding messages
received on one SCTP association to another based on the address parameters
(AMF function).

I guess the CO state machines are the real issue here : I submit they must
be present on the IPSP and ASP; handling them remotely (at the SG) is and
should not be specified as an option, since it breaks the end-to-end SCCP
protocol when routing via multiple SGs is done. The coupled approach forms
no exception : CO state machines are still present at IPSP/ASP, and also 
on the SG to perform the association of connection sections.

For the same reason of multiple SGs, to a lesser extent, we also
reconsidered the CL reassembly at the SG before sending CLDT to the ASP. In
this case, it is now also recommended to perform reassembly at the ASP and
let the SG do nothing but route.

The issue for both M3UA and SUA is : in all-IP case they provide to legacy
users a "legacy" view of the network. I.e. M3UA should also provide the
transfer functionality : it is already there, but well hidden. (Suppose
there are SCTP associations between A-B and B-C. If A wants to route to C it
can view B as a SG which has connectivity to the "SS7" node C.) And the SUA
should provide the relay (AMF-Global title translation) functionality.

=> Up till now it is unclear what the equivalents of TFC, TFR etc. will be
in the all-IP case. Can we reuse SSNM messages for this and let the
transfer/relay points act as SGs in this respect ?

Regards,

____________________________

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

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 17 oktober 2001 0:31
To: sigtran
Cc: [email-masked]
Subject: Re: SUAv8, M3UAv9: IPSP Handling

John,

--brian

John Loughney wrote:                                         (Tue, 16 Oct
2001 20:50:05)

-- 
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, 17 Oct 2001 07:03:01 -0500

Gery,

Verwimp Gery wrote:                                       (Wed, 17 Oct 2001 12:09:31)
> this. This is true for the IPSP case (SUA PDUs == SCCP PDUs) as well as for

All that is required for ASP is the P/U interface.  Not full blown
MTP or SCCP state machines and routing.  Some additional is required
for multiple SG operation, but not complete state machines.

> possible of SCCP variants at this point.

Another thing is that the SG has full blown state machines and routing.

> - on the ASP to select SG/SGP for an available route to an available SS7

Only needs to select SG in multiple SG case.  One of multiple SGP are not
selected by available SS7 destination at all: but, by traffic mode and
SGP/ASP management.

> - on the SG to select AS/ASP based on RK parameters and availability

SG can select AS/ASP by interface identifier: RC.  RK is only needed to
bind the interface when the MTP/SCCP-User (AS) becomes active.

> - on IPSP to select another IPSP based on RK parameters and availability

Now that's the question: if it is based on user interface identifier (RC)
upwards to the AS and availability downwards: what is used for route
management in the downwards direction?  And peer to peer?  This has not
even been touched on in the drafts.  The multiple SG cases are minor
compared to the full routing and availability function.

> point with no "real" SCCP-users.

The ASP-SUA should be oblivious to whether there are local users or
not.  In fact, the draft prides itself on saying that the AS at the
ASP-SUA thinks that it *is* a local user of the SG.

> Peer-to-peer (end-to-end) communication is between SS7 SEP and ASP. In
> all-IP case, one might also have SUA-relay points without real users, with
> the single purpose of forwarding messages received on one SCTP association
> to another based on the address parameters (AMF function).

No need.  IP routes nicely without AMF.  Point to point is sufficient.

> I guess the CO state machines are the real issue here :

Well, there is also the routing function.  Routing and route status
applies to both CO and CL.

> I submit they must be present on the IPSP and ASP; handling them remotely
> (at the SG) is and should not be specified as an option, since it breaks the
> end-to-end SCCP protocol when routing via multiple SGs is done.

I think you want SCCP over M3UA.

> The coupled approach forms no exception : CO state machines are still
> present at IPSP/ASP, and also on the SG to perform the association of
> connection sections.

It is quite possible to implement without CO state machines at the ASP.
Just not at the IPSP.

> let the SG do nothing but route.

Only for the multiple SG case is it necessary as an option.  An SG can
reassemble all it wants (with consideration for reliability impacts for
multiple SG).

> users a "legacy" view of the network.

I would hardly call ISO NSD "legacy".  MTP may be legacy but SCCP is not.
Nevertheless, if users of M3UA/SUA did not want a legacy view, we would
not be doing so much work to transport SS7.  People like connecting their
communications systems to the telephone network: there are so many people
to call there.

> I.e. M3UA should also provide the transfer functionality : it is already
> there, but well hidden.

Pointless.  In backhaul case it is not necessary.  In IP case it is also
not necessary.  The MTP transfer functionality is inherently circuit-oriented:
IP is not.  Full mesh SCTP associations are quite feasable where full mesh
F-links are not.

> (Suppose there are SCTP associations between A-B and B-C. If A wants to
> route to C it can view B as a SG which has connectivity to the "SS7" node
> C.) And the SUA should provide the relay (AMF-Global title translation)
> functionality.

No point.  Just form an SCTP association between A and C.  Who needs a
complicated middle node when there are no circuits?  Why overlay an IP
network with a circuit view?  I think you want PWE.

> in the all-IP case.

It is clear to me: ICMP, RIP, BGP...

> Can we reuse SSNM messages for this and let the transfer/relay points act as
> SGs in this respect ?

The idea is to transport SS7, not to make an SS7 network out of the IP
network.

I don't see that this has made IPSP definition any clearer.

--brian

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

---

---

From: Coene Lode <[email-masked]>
Date: Wed, 17 Oct 2001 16:03:53 +0200

Brian,

I am always amazed about everything you say, in whatever mode you are
running at that moment: nethead, Bellhead, SS7 head, no head 

I'll try to put in some of your comments about some issues in my code: they
are sooo funny

> No need.  IP routes nicely without AMF.  Point to point is sufficient.

MTP lvl 3 or SCCP routes fine without IP also. This isn't a argument. If IP
does not support what you need to route, then something needs to be done.
(And don't even think about using DNS for solving those problems -> that is
a typical nethead solution, which is clearly showing its age and
inapprioriateness. See Randy Bush and his talk in IETF plenary in San Diego
about"The DNS Today Are we Overloading the Saddlebags on an Old Horse?")

> I think you want SCCP over M3UA.

This would imply a M3UA IPSP case, thus rendering youre argument against
IPSP rather , ahum, "interesting". Or does SCCP directly resolve this to the
final destination?: If this is true then how does a GSM network
work(according to you): example: how do I log on to a network in a other
country, send/receive SMS when I am out of the country(well heck, even
within the country). Do you really believe that there is a central computer
doing all those things(as some netheads seem to imply). Funny that I have
never seen, heard or implemented this protocol anywhere in my code for
making GSM or any other phone work. 
I leave the excersise to you to find the great central node in a IP
network(which according to people of the Faith "does not exist").

> communications systems to the telephone network: there are so 

SCCP uses MTP, now I am really confused about the meaning of legacy. 
But I don't mind. I far more interested in whether the protocol is used and
grade it by the number of people who use it.
- ISO NSD: a optimistic view: > 0
- MTP: most phone and nearly all wireless users: >> 500 Million
- SCCP : nearly all wirelless users: >> 500 Million
- IP: no exact counts are known, but believed around 500 Million, give or
take 100 Million

Legacy is a term used to make somebody feel bad or guilty or both, about
something they have made.

> IP is not.  Full mesh SCTP associations are quite feasable 

indeed Brian, you made a really pointless argument. 
Backhaul will not be the mainstay of SS7.
MTP transfer functionality  circuit-oriented???!!!: Where is my MTP circuit,
Oh you meant MTP link, Ahhh, Doesn't that look like a IP link, then . Would
that mean that IP is also circuit oriented? 
I don't get it(don't worry, it is condition that I get often into, mostly
when one of youre pearls of wisedom is exposed to me). Circuits are unheard
in SS7, some of our applications do something with circuits but they
certainly don't tell us anything about it.
Full mesh SCTP associations: about what sort of networks are you talking,
the 5 node maximum network? Even the smallest GSM network is bigger than
this and isn't even connected to its fellow GSM networks and you advocate
full mesh! It is very likely that a mob of SS7 designers and IP designers
will chase you down to the end of the earth(or (better end of the galaxy)
for uttering such a nonsense.(and I glady volunteer to be part of the mob.
Serving 500 million people rules out running a full mesh(just ask any real
nethead or GSM head)

> network with a circuit view?  I think you want PWE.

A SS7 network doen't have circuits, it has links and a STP routes msg from
one link to another link: look to IP : a IP router routes packet(msg) from
one link to another link. They do the same thing, but the protocol syntax is
different. I was amazed at how similar setting up routes was with a IP
router compared to a STP.

Yes you right (for once), it is a overlay, but where are those circuits.

I think you misread my mind(and Gery's also), I don't want Psuedo Wire
emulation. That happens to be something associated with MPLS. And netheads
in general have a very dim view of MPLS.

So any router is just a complicated midle node who shouldn't be there in the
first place.
Go figure.
> It is clear to me: ICMP, RIP, BGP...

ICMP: similar to the service messages such as UDTS, XUDTS. Are used for
indicating a error with a single packet,usually send back to the originator
to do soemthing with it. 
example discovery of the path MTU length. 
It is not a node management protocol which exchange msg between adjacend
nodes. Doesn't supply status or status changes of a node. Doesn't fit the
bill.
RIP, BGP: a routing protocol: tries to find routes through the network for
certain prefixes, so that everybody can possibly talk with everybody else.
Doesn't do management either.
Is so good that it only allows 1(yes, one) path through the network to reach
you destination. If you need more paths, uses different addresses, with
different prefixes naturally, otherwise you paths will be the same all along
the way. Net result: routing table grow and no hard guarentee of different
paths.(see multihoming)
Contrast this with MTP links and linksets and it put things in perspective.
See the The "State of BGP Routing ", IETF Minneapolis, plenary, for how
things really are going in this space.(it is even a recurring point at each
IETF plenary)
A exit router may get 2 or more advertisments of the same prefix over
different links, but the exit router will take only one(yes, 1) into account
and use this single link as its exit out of the network(or whatever) Need I
really to go any further.

Clear??!!: maybe on a very foggy day.!

> The idea is to transport SS7, not to make an SS7 network out of the IP

Well if it we could tranport SS7 over IP AND make a SS7 network out of IP,
That would be the biggest improvement IP would have had in years and not a
single soul would be interested in those QOS schemes such as RSVP,MPLS....

> I don't see that this has made IPSP definition any clearer.
Finally, a statement we can both agree on.

yours sincerly,
Lode

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:35 +0300

Hi Brian,

> pretty good list of descriptions which are missing for IPSP.

I think that this will be a good way forward.

> interoperable IPSP operation in both M3UA and SUA.

That is my goal.  

John

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:44 +0300

Hi Francois,

> manage. Especially if you want to address both M3UA and SUA in one

Agreed.
 
> to start the ASPs and activate the AS. 

Agreed, but the restriction is that the side which wants to initiate
the traffic also initiates the SCTP connections. SCTP provides a 
mechanism to handle INIT collision.  I believe one mechanism is
enough - two mechanisms is too much.

> Which ever side ready 

Agreed.

> -symetry wrt to ASPSM and ASPTM vs client/server role (who sends

For the ASPSM & ASPTM, we have two models - either single ended 
procedure vs. symetrical (bi-directional) procedure.  I will
propose text for this (both cases) and see what folks want.

> do they both need to send REG messages)

Yes, registration needs to be handled by each side.  The reason is
that registration, in effect, tells the other side what it is 
(what point code it is, what CIC ranges, what SSN, etc.).  Think of
it this way, two IP SEPs with be identified by different SS7 addresses.
Registration, effectively informs the other side what traffic (i.e. 
SS7 addresses) it is processing traffic for.  In this way, registration
has to be sent in both directions.

> -RC applies to both directions vs single direction

RC usually denotes an internal value (index into a table).  If
RC applies in both directions, then the RC + 'connection' is needed.

A diagram:

	     ab
	A ------- B
	 \       /
	  \     /
	ac \   / bc
	    \ /
	     C

A, B and C are IPSPs, each representing distinct ASs.  ab, ac, bc are the
SCTP
associations between them, I I will consider them as labeling the
connections
between the IPSPs. If routing contexts apply in both directions, you will
need
both the RC + the connection in order to uniquely identify the endpoint to
send traffic to.

> -description of the transfer function at an IPSP/SS7, IPSP/SG,

IPSP doesn't interwork with SS7, I thought.

> -where do state machines for MTP3 and User Parts fit in the

This seems to be under discussion.

> model (both ends would be logical if symmetric roles are adopted)

Both ends, in my opinion.

> messages and SSNM messages to IPSP, interactions like MTP Restart)

These I thought are not needed.

> when several SPMC are hosted in a single IPSP for example)

For SUA, is this needed (no SPMC in SUA).

> fake PC in a pure IP network?

This I think is not needed.  What an IPSP will need to do is build
a table which shows the mapping between the SS7 address to the
IP address.  Since M3UA / SUA will be supporting the routing 
of messages based on SS7 addresses, including any IP type addresses
is something that is not currently needed.

Let me know what is acceptable to you & I'll add it to the 'IPSP
Considerations' in chapter 4.  Additionally, I will try to propose
some text for some of the above.

best regards,
John

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:45 +0300

Brian,

> SCCP PDUs, the SCCP state machines will be required.  Which

From my high level view, this is what I've planned on:

IPSP ----- IPSP / ASP ---- SG ----- STP ---- SEP

where the IPSP / ASP would be a single network node.  I'm
currently not focusing on such a network node being an
SUA relay - I think such a beast would require some additional
text as an extension draft.

From this view, it is clear that the SUA messages correspond
to SCCP PDUs.  This requires SCCP (or SCCP-like) state machines
at the IPSP.  I think that some folks are still assuming that
the ASP will have a SCCP state machine, especially if the
ASP - SGP communication can be wholey contained (i.e. - you'd
have TCAP on top of an SGP) and the SCCP/SUA users would 
be only communicating between the ASP and SGP.

Now, on to the practical side.  The backhaul case (ASP to SGP)
is clear, but this IPSP to IPSP (the peer-to-peer) case is something
which has been specified in other SDOs who are waiting on M3UA
and SUA.  

Would it be something which you would support if we add a paragraph
on this issue (i.e. - state machines are needed at the IPSP) and
give a quick over view (along the lines of what I have specified
above).  Then, in chapter 4, we enhance all of the IPSP Consideration
sections to fully meet your & Francois' concerns?  

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 18:34:14 -0500

John,

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:35)
> > interoperable IPSP operation in both M3UA and SUA.

It's your goal for it to be impossible???!

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 18:41:34 -0500

John,

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:44)

[snip]
> IP address.

> Since M3UA / SUA will be supporting the routing of messages based
> on SS7 addresses, including any IP type addresses is something that
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> is not currently needed.
  ^^^^^^^^^^^^^^^^^^^^^^^

Think again what you said here:

  If IP type adress are not currently needed,
  remove routing on IP address from SUA. ;)

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 19:01:52 -0500

John,

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:45)
> text as an extension draft.

Nor a STP for M3UA I hope.

> at the IPSP.

Bad.  There is no need to code SCCP PDUs as SUA messages, just
transport the SCCP PDU as specified in the standards documents.
If the state machines are SCCP state machines, just use an
SCCP state machine.  I think you want M3UA here.

Did you want to specify state machines?  An NSD interface
description for SCTP would be easier.

> I think that some folks are still assuming that the ASP will
> have a SCCP state machine, especially if the ASP - SGP
> communication can be wholey contained (i.e. - you'd have TCAP
> on top of an SGP) and the SCCP/SUA users would be only communicating
> between the ASP and SGP.

If I have an SCCP state machine at an ASP (or IPSP for that matter),
why would I need SUA?  Why not just use M3UA if there is a complete
SCCP state machine at the ASP?

For M3UA: If I have an MTP state machine at an ASP (or IPSP), why
would I need M3UA?  Why not just use M2UA/M2PA if there is a complete
MTP state machine at the ASP?

Please do not assume that there is an SCCP state machine at an
SUA ASP/IPSP, nor an MTP state machine at an M3UA ASP/IPSP.

Map the user interface onto the services offered by SCTP.  That is
"wrapper" the SCTP state machines and ASP management procedures.

> sections to fully meet your & Francois' concerns?  

Saying that some unspecified SCCP-like or MTP-like state machines are
required at the IPSP will simply not do.  If you need state machines
there, they will have to be described, either through reference to
existing standards which contain the state machine descriptions or
described from scratch.

We don't even manage ASPs without describing state machines.  A protocol
without a state machine description would be rather useless don't you
think?  It would certainly have a hard time being inteoperable.

Why not consider that there is no such state machine at the IPSP.
That the IPSP maps the primitives of the SCCP and MTP interfaces
onto the message and services of SUA and M3UA only.  However, some
local indication and services (normally provided by the SG in the
ASP/SG arrangement) will have to be provided locally at the IPSP.
These services need to be described.

For example: in MTP when an IPSP loses an association to an other IPSP,
it informs all local MTP-User with a route to that IPSP via an
MTP-PAUSE primitive.

Of course, many more statements like this would be necessary to
describe the mapping.

What do you think?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 18 Oct 2001 10:32:48 +0200

Brian,

On the "why need" M3UA/SUA question : because we're running on top of
SCTP/IP and not a regular MTP3/MTP2 stack. And what "state machines" are you
talking about ? Do you want to run M3UA/SUA without writing any code ??

It is already established that M3UA/SUA need AS/ASP and SG/SGP state
management (1 family of "state machines"), and also SS7 availability status
in case of multiple SGs (unless you want to audit all the time). M3UA/SUA
can take the step to maintain routes as well (routing over paths formed by
SCTP associations).

For SUA, there is the connection-oriented service, which requires "state" at
each end point and in intermediate points performing coupling. I thought
that was clear.

Much of this is of course about reinventing the wheel (where else did all
those SUA parameters come from ;) and filling the gaps of what is missing in
the SCTP/IP protocol stack (loadsharing over hosts, quasi-immediate backup
routing, ...).

The higher you put the adaptation layer, the less SS7 layers you have to
take over; but you're stuck to the functionality of the layer you're
replacing AND the common functions of any adaptation layer. Where the
optimum UA is, depends on what's already installed in your network and what
you're trying to do.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 18 oktober 2001 2:02
To: sigtran
Subject: Re: SUAv8, M3UAv9: IPSP Handling

John,

John Loughney wrote:                                         (Thu, 18 Oct
2001 00:08:45)

What do you think?

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 04:05:24 -0500

Gery,

Verwimp Gery wrote:                                       (Thu, 18 Oct 2001 10:32:48)
> SCTP/IP and not a regular MTP3/MTP2 stack.

You misinterpret what I said:  I said if SUA has a complete SCCP state
machine, why not just use M3UA?  Both sides can then have an SS7
conformant SCCP state machine rather than a hacked SUA one.  With
M3UA if an MTP state machine is required at both ends, why not use
M2UA and have an SS7 conformant MTP state machine rather than a hacked
M3UA one?

If you are sticking MTP and SCCP state machines at both ends,
why not just use M2PA?

> And what "state machines" are you talking about ?

MTP state machines for M3UA and SCCP state machines for SUA.

> Do you want to run M3UA/SUA without writing any code ??

I don't want to implement MTP and SCCP state machines in an environment
which does not even permit them to be conformance tested.  One might
as well use the actual MTP and SCCP state machines in their intended
way.  Amount of code has nothing to do with it.

> can take the step to maintain routes as well (routing over paths formed by

I have no problem with that.  John was talking about SCCP state machines.
If the SUA messages are equivalent to SCCP PDUs, an SCCP state machine
must sit behind them.

> each end point and in intermediate points performing coupling. I thought

Again, John was talking about SCCP state machines and SUA messages being
equivalent to SCCP PDUs.  That is effectively SCCP with a different line
coding.

> the SCTP/IP protocol stack (loadsharing over hosts, quasi-immediate backup

All of this stuff relates to internal architecture of the SS7 node.  This
is only because the UA attempts to split up the stack in the backhaul case.

For IPSP a lot of that crap is unnecessary.  For example, an SCTP
association could serve an SCCP connection without having to add
SCCP state machines, needing SUA equivalents of SCCP PDUs and without
needing ASP management, notification procedures, error messages, blah
blah.

<skip class="motherhood statement">
> optimum UA is, depends on what's already installed in your network and what
</skip>

--brian

> Fax: +32 14 25 3212

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 04:44:21 -0500

Coene,

Coene Lode wrote:                                           (Wed, 17 Oct 2001 16:03:53)
> running at that moment: nethead, Bellhead, SS7 head, no head 

I do not subscribe to that last one: is "no head" the camp that
you are from? ;)
> I'll try to put in some of your comments about some issues in my code: they

I'm sure your code is even funnier. ;)

> about"The DNS Today Are we Overloading the Saddlebags on an Old Horse?")

Who needs DNS?  MTP does not do name resolution.

> making GSM or any other phone work. 

SCCP over M3UA is precisely 3GPP's current recommendation.

Do your homework.

> network(which according to people of the Faith "does not exist").

No central IP node required.  M3UA point to point over IP and SCCP
end to end.  Place your SCCP relay wherever you'd like.

> - IP: no exact counts are known, but believed around 500 Million, give or

X.25, Frame Relay, ISDN, ATM, ...  Telcos sell these too.  As it stands,
data is overtaking voice in the telephone network (you need all that
X.25, Frame Relay, ISDN, and ATM to carry that IP) so actually the amount
of ISO NSD in the network exceeds SS7 by throughput and volume.  Much of
your IP is carried over an NSD compliant network.  Don't know much about
telecommunications, do you? ;)

> something they have made.

Around here it is used to refer to anyone that works for a phone company. ;)

> Backhaul will not be the mainstay of SS7.

The M3UA draft specifically states that IPSP is only supported point-to-point.

> that mean that IP is also circuit oriented? 

I suggest you read the overview sections of MTP and SCCP, even SS7 for
that matter.  You seem lacking on basic principles.

> certainly don't tell us anything about it.

Again, read the overview sections and pay special attention to Q.702.
SS7 is transported over circuits.  You know?  Bidirectional channels?
Wires?  Have you heard of wires before?

> Serving 500 million people rules out running a full mesh(just ask any real

Not full mesh between people: full mesh between SS7 signalling points.
We are talking about STPs here.

This is already performed in the SS7 networks where no STPs are
provided.  STPs are optional in the SS7 network.  Would you rather
I use the term "fully associated"?  Do you know what an F-Link is?

> A SS7 network doen't have circuits, it has links

Re-read Q.702.  An SS7 network is made up of circuits.

> and a STP routes msg from one link to another link: look to IP
> : a IP router routes packet(msg) from one link to another link. They do the
> same thing, but the protocol syntax is different. I was amazed at how
> similar setting up routes was with a IP router compared to a STP.

My point is that you have the IP router so you don't need the STP.
Take a look at the way SS7 networks are put together in Europe.  You
will not see STPs as you do in NA and elsewhere.  All nodes are
directly connected (by links and circuits) to all the other nodes
that it wishes to talk to.  Yes, this requires SCPs with over 300
links in some situations.

STPs are an OPTIONAL part of the SS7 network.  The only thing that
causes problems for F-link, fully associated networks is the facilities
cost of the CIRCUITS for the links.  With SCTP associations there is
no inherent cost and there is simply no need for STPs or the relay
function in the IP domain.  M3UA does not evern support it: it states
clearly that it only supports IPSP in a point-to-point fashion.

> Yes you right (for once), it is a overlay, but where are those circuits.

You don't seem to understand what you are attempting to overlay, nor
the characteristics that change with the overlay.

> in general have a very dim view of MPLS.

So skip the transfer and relay function.

> So any router is just a complicated midle node who shouldn't be there in the

No.  A IP router is there so use it.  Don't overlay an MTP router and an
SCCP router on top of the IP router.

> Go figure.

Go read.

> nodes. Doesn't supply status or status changes of a node. Doesn't fit the

It seems you know little about IP as well.  An IP router can indicate
to a host via ICMP that a remote host is unreachable.  That is, say, TFP.

> Doesn't do management either.

Cluster TFP, TFA and TFR as for trying to find routes through the SS7
network for certain prefixes.

> the way. Net result: routing table grow and no hard guarentee of different

It does indicate the availability and metrics of routes which are equivalent
to MTP routesets.

> really to go any further.

Please do.  1 route is sufficient.

> Clear??!!: maybe on a very foggy day.!

M3UA can be used in a point-to-point IPSP fashion without transfer function.
Clear?  This is true both for SS7 and is all that is provided by the M3UA
draft.  Clear?

> single soul would be interested in those QOS schemes such as RSVP,MPLS....

I think that you should do a little more reading on SS7.  It is not the
panacea for IP.  Nevertheless, new QOS approaches are outside SIGTRAN's
charter.

==brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 18 Oct 2001 13:39:11 +0200

Brian,

Back here in Europe, operators are restructuring their networks and we see a
lot of STP offers being made. The same evolution in GSM -> 3GPP networks.
North America is still the biggest market for STPs, but the rest of us is
closing in.

Some other points ...

- no inherent cost to SCTP associations : I think this is very debatable.
Instead of the legacy MTP network planning, you now have a certain amount of
IP network planning to do. But anyway : you have no problem with routing
over paths formed by SCTP associations. This would require something akin to
MTP3 network management procedures in M3UA for the all-IP case, wouldn't it
? Some people even argue that MTP-transfer *is* supported by M3UA, or at
least not prohibited (the transfer node then has SG functionality, but with
M3UA at both ends ...)

- setting up SCTP associations between any point A and B might not be
possible/desirable, e.g. when you go from one operator's network to another
one's. And these operators might even share equipment.

- dynamically setting up SCTP associations for each SCCP (err...SUA)
connection ? Are you serious ? We're not doing file transfer here you know
;) Of course we could do without all the ASP management crap if M3UA/SUA
simply reused the existing SS7 procedures, hence we're back to your state
machines :)))

- SCTP/IP still leaves the host redundancy up to the UA.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 18 oktober 2001 11:05
To: sigtran
Subject: Re: SUAv8, M3UAv9: IPSP Handling

Gery,

Verwimp Gery wrote:                                       (Thu, 18 Oct 2001
10:32:48)

</skip>

--brian

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 22 Oct 2001 18:47:00 +0200

John,
Please find below (check for [Francois]) my input for the IPSP issues.
I did not put comments where I agreed with your text.
Francois.

Hi Francois,

Agreed.

[Francois] I believe this should be left implementation dependent as
there is no interaction between bringing up association and M3UA ASP.

Agreed.

[Francois] A single-ended procedure would be simpler. The Routing
Context has a dual significance (is valid at both ends of the IPSP).
Having one side (master) send the ASP UP and ASPAC messages would also
simplify the behavior. The other side (slave) acknowledges these
messages. It would be very simple and clean to manage.

[Francois] This should be left implementation dependant. It is perfectly
valid to send a REG REQ with a given routing context on the master side,
and accept this routing context by inverting DPC/OPC on the slave side.
For example if I send a REG REQ with (DPC=x, SCCP) and RC=1, I would assume
my peer would send me messages for (OPC=x, SCCP) and RC=1.
Therefore a double flow of messages is not necessary. 

A diagram:

	     ab
	A ------- B
	 \       /
	  \     /
	ac \   / bc
	    \ /
	     C

[Francois] A routing context has a significance on an peer-to-peer basis
only (OPC, DPC couple), but over all SCTP asssociations that may exist 
between two IPSP.

[Francois] In the absence of SS7 network, MTP3 is not present, but the
User Parts are present at both ends.

best regards,
John

---