Subject: [Sigtran] inter-IP communciation

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 18 Apr 2002 21:32:29 -0400

Hi,

I will try to give a brief overview what was discussed and agreed (again
just from my point of view) in IPSP list. It will have only the general
ideas, because I wanted to send something quickly so that we can decide
where to put this information (of, course first let's see whether everybody
likes the listed ideas or not), the real draft itself -if necessary-, I will
try to submit soon but the following will probably be enough to understand
the proposed approach. (I will explain in more detail how the models are
working, put more examples and try to discuss about advantages/disadvantages
of each proposed method. Especially for  inter-IP communication with
multiple SGPs case, more explanation is necessary but because it corresponds
what was called before to double-ended approach, I think people won't have
big difficulty to get the idea)

In my opinion, the most important decision in the IPSP discussions was to
base inter-IP communication on existing ASP/SGP fuctionalities, where no
additonal IPSP functionality is defined.

    Tolga

Inter-IP Communication
========================
1.Overview
The purpose of this document is to recommend methods of inter-IP
communication for UA peers, based on the functionalities already defined in
the corresponding RFCs/drafts and SG-SG communication, as described in draft
[.....].
The strategy is, making use of alredy defined SGP/ASP functionalities and
SG-SG communication, rather than defining a new functionality type (that is
the reason, why I think, it is more appropriate to call it inter-IP, instead
of IPSP)

2.Inter-IP Communication Methods
2.1 Inter-IP Communication with SG-SG Protocol
     -----              -----
   //     \\          //     \\
  |  ASP    |        |  ASP    |
  |  Cloud 1|        |  Cloud 2|
   \\     //          \\     //
     --+--              --+--
       |                  |
       |                  |
    +--+--+            +--+--+
    | SG1 +------------+ SG2 |
    +--+--+            +--+--+
       |                  |
       |                  |
       |                  |
       |     +-----+      |
       +-----+ SG3 +------+
             +--+--+
                |
                |
              --+--
            //     \\
           |  ASP    |
           |  Cloud 3|
            \\     //
              -----
Figure 1. Inter-IP communication with SG-SG protocol

This method uses SGP/ASP functionalities as defined in corresponding RFCs
for UAs. Communication between SGs is based on SG-SG communication as
defined in draft[...]. For that reason, this method is only applicable for
UAs, for which SG-SG protocol is defined (so, currently just for M3UA).
It should be noted that in this method, configuration changes or dynamic
status changes (AS/ASP state changes, RK definitions etc....)in ASP clouds
are transparent to other ASP clouds, as long as they don't affect the status
of SPMC.

2.2 Inter-IP Communciation with one SGP
 +------+     +------+      +------+
 | ASP1 |     | ASP2 |      | ASP3 |
 +---+--+     +--+---+      +--+---+
     |           |             |
     |           |             |
     |           |             |
     |           |             |
     |           |             |
     |        +--+---+         |
     +--------+ SGP1 +---------+
              +------+
Figure 2. Inter-IP communication with one SGP

This method uses SGP/ASP functionalities as defined in the corresponding
RFCs for UAs. It does not need any additional functionality, so should be
considered only as a sample configuration of the already defined SGP/ASP
functionalities.

2.3 Inter-IP Communication with multiple SGPs

 +-----+           +-----+
 |ASP1 +-----------+SGP2 |
 +--+--+           +--+--+
    |                 |
    |                 |
    |                 |
 +--+--+           +--+--+
 |SGP1 +-----------+ ASP2|
 +-----+           +-----+
Figure 3. Inter-IP communication with multiple SGPs

This method uses SGP/ASP functionalities as defined in the corresponding
RFCs for UAs. It does not need any other functionality, so should be
considered only as a sample configuration of the already defined SGP/ASP
functionalities.
In this method, associations between peers is used in a unidirectional way,
unlike the regular SGP/ASP case. The interfaces between ASP1/SGP1 and
ASP2/SGP2 may be implemented with a proprietarty method. ASPs should be able
to know, which SGPs to use to send out messages for a specific AS. For
example a message from ASP1 to ASP2 will go through the following steps:
1-ASP1 sends the message to SGP1 (based on RK, ASP1 knows, to which SGP the
message should be sent)
2-SGP1 sends the message to SGP2 (based on RK, SGP1 knows, to which ASP the
message should be sent)

It should be noted, both ASPs and SGPs differentiate between peers not only
based on RKs, but also on the direction of the messages.

With this method, the situation, where the message path between two user
applications is open only in one direction, migth happen.

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Apr 2002 09:43:55 -0400

Javier,

Probably after this brief overview, what was discussed in IPSP list, it is
more clear why I said, there are no extra explanations necessary in IG for
IPSP mode. The decision there was, a new process type -IPSP- is not
necessary. In fact, also the first discussions about IPSP mode were going to
that direction, but time did not allow to finish those.
In my opinion, the only thing necessary in IG related with IPSP is, to say
that it is no more needed.

    Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Thursday, April 18, 2002 9:32 PM
> To: [email-masked]
> Subject: [Sigtran] inter-IP communciation
>
>
> Hi,
>
>