Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Mon, 25 Nov 2002 17:30:40 +0100

> > 2.  Concern about the state of IPSP.  With IPSP as single-exchange,
> > there is an issue related to dynamic registration.  General 
> consensus
> > is that dynamic registration needs to be double-exchange to avoid
> > potential for race condition.  Thus, there is a desire to move back
> > to double-exchange.
> [TOLGA] What is exactly the problem scenario? Is the proposal 
> to move just
> dynamic registration to double exchange or the whole IPSP model? 

Hi Tolga,

we know that there has been a lot of discussion about the subject SE IPSP
vs. DE IPSP.
It is not our intention to re-open the technical parts of these discussions.
However, as Ken indicated in his summary of the 2nd day of the plugtest,
there is an argument to be made to put DE IPSP back in the M3UA
implementor's guide:

1. Both DE and SE IPSP are included in RFC 3332
2. During the 3rd M3UA plug test, we have successfully interoperated in DE
IPSP mode, both with static RCs configured and with dynamic registration of
Routing Keys.
3. There was a clear consensus amongst those present at the plug test that
for an implementation that wants to use dynamic registration, only DE IPSP
will work.

So, for these reasons, we would like to see the M3UA implementor's guide
modified to reflect the following rules:
1. When using static configuration of RCs, both SE and DE IPSP are allowed
and the chosen mode must be configured on both sides.
2. When using dynamic registration of Routing Keys, only DE IPSP is allowed.

We propose the following texts:

3.12 IPSP stuff

3.12.1 Description of the problem

    ---------
    Old text: (Section 3.12.1)
    ---------

    At the 2nd M3UA Plugtest several concerns were raised about the non-
    interoperability of the two different IPSP exchanges defined in M3UA.

    ---------
    New text: (Section 3.12.1)
    ---------
    
    At the 2nd M3UA Plugtest several concerns were raised about the non-
    interoperability of the two different IPSP exchanges defined in M3UA.
    
    The mode of communication (SE or DE) MUST be agreed between both peers. 

 3.12.2 Text changes to the document

    ---------
    Old text: (Section 4.3.1)
    ---------

    Figure 4: ASP State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |      Other   +-------|              |
                |   ASP in AS  |       +--------------+
                |   Overrides  |           ^     |
                |              |    ASP    |     | ASP
                |              |    Active |     | Inactive
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      +--------------+
                |                          ^     |
      ASP Down/ |                     ASP  |     | ASP Down /
      SCTP CDI/ |                     Up   |     | SCTP CDI/
      SCTP RI   |                          |     v SCTP RI
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

    ---------
    New text: (Section 4.3.1)
    ---------

    The figure below shows the transitions for the ASP and IPSP cases.

            Figure 5: IPSP SE State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |        Other +-------|              |
                |   IPSP in AS |       +--------------+
                |    Overrides |           ^     |
                |              |    ASPAC/ |     | ASPIA/
                |              |[ASPAC-Ack]|     | [ASPIA-Ack]
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      |              |
                |                      +--------------+
                |                          ^     |
         ASPDN/ |                          |     | ASPDN /
    [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
      SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
      SCTP RI   |                          |     | SCTP RI
                |                          |     v
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

            Figure 6: IPSP DE State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |        Other +-------|              |
                |   IPSP in AS |       +--------------+
                |    Overrides |           ^     |
                |              |    ASPAC  |     | ASPIA
                |              |           |     |
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      |              |
                |                      +--------------+
                |                          ^     |
         ASPDN/ |                          |     | ASPDN /
    [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
      SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
      SCTP RI   |                          |     | SCTP RI
                |                          |     v
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

    The transitions in brackets are just valid for the IPSP communication
    while the rest are valid for both ASPs and IPSPs.

    ---------
    Old text: (Section 4.3.4.1.2)
    ---------

    Alternatively, an interchange of ASP Up messages from each end can be
    performed. This option follows the ASP state transition diagram. It
    would need four messages for completion.

    ---------
    New text: (Section 4.3.4.1.2) i.e. UNCHANGED versus RFC
    ---------

    Alternatively, an interchange of ASP Up messages from each end can be
    performed. This option follows the ASP state transition diagram. It
    would need four messages for completion.
    
    ---------
    Old text: (Section 4.3.4.3.1)
    ---------

    Alternatively, an interchange of ASP Active messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be activated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    New text: (Section 4.3.4.3.1) i.e. UNCHANGED versus RFC
    ---------
    Alternatively, an interchange of ASP Active messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be activated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    Old text: (Section 4.3.4.4.1)
    ---------

    Alternatively, an interchange of ASP Inactive messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be deactivated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    New text: (Section 4.3.4.4.1) i.e. UNCHANGED versus RFC
    ---------

    Alternatively, an interchange of ASP Inactive messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be deactivated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.
    
    ---------
    Old text: (Section 4.4.3)
    ---------

    The Registration/Deregistration procedures work in the IPSP cases in
    the same way as in AS-SG cases.  An IPSP may register an RK in the
    remote IPSP.  An IPSP is responsible for deregistering the RKs that
    it has registered.

    ---------
    New text: (Section 4.4.3)
    ---------

    The Registration/Deregistration procedures are not recommended in the
    IPSP cases working in SE mode as one or two RC may be involved 
    in the exchange depending of the sequence of events.

    The Registration/Deregistration procedures work in the IPSP cases in
    the same way as in AS-SG cases.  An IPSP may register an RK in the
    remote IPSP.  An IPSP is responsible for deregistering the RKs that
    it has registered.

    ---------
    Old text: (Section 5.5)
    ---------

    These scenarios show a basic example for IPSP communication for the
    three phases of the connection (establishment, data exchange,
    disconnection). It is assumed that the SCTP association is already
    set up. Both single exchange and double exchange behavior are
    included for illustrative purposes.

    5.5.1 Single exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |

    Routing Context are previously agreed to be the same in both
    directions.

    5.5.2 Double exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |<-------------ASP Up------------|
                  |-----------ASP Up Ack---------->|
                  |                                |
                  |-------------ASP Up------------>|  (optional)
                  |<----------ASP Up Ack-----------|  (optional)
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |------- ASP Active(RCa)-------->|  RC: Routing Context
                  |<-----ASP Active Ack (RCa)------|      (optional)
                  |                                |
                  |<=========  DATA (RCa) =========|
                  |==========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|
                  |                                |
                  |------ASP Inactive (RCa)------->|  RC: Routing Context
                  |<----ASP Inactive Ack (RCa)-----|
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |
                  |------------ASP Down----------->|  (optional)
                  |<--------ASP Down Ack-----------|  (optional)
                  |                                |

    In this approach, only one single exchange of ASP Up message can be
    considered as enough since the response by the other peer can be
    considered as a notice that it is in ASP_UP state.

    For the same reason, only one ASP Down message is needed since once
    that an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed to receive ASPSM
    messages.

    ---------
    New text: (Section 5.5)
    ---------

    These scenarios show a basic example for IPSP communication for the
    three phases of the connection (establishment, data exchange,
    disconnection). It is assumed that the SCTP association is already
    set up. Both single exchange and double exchange behavior are
    included for illustrative purposes.

    5.5.1 Single exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |

    No registration/deregistration procedure is supported. Routing 
    Context are previously agreed to be the same in both directions.

    5.5.2 Double exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |<-------------ASP Up------------|
                  |-----------ASP Up Ack---------->|
                  |                                |
                  |-------------ASP Up------------>|  (optional)
                  |<----------ASP Up Ack-----------|  (optional)
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |------- ASP Active(RCa)-------->|  RC: Routing Context
                  |<-----ASP Active Ack (RCa)------|      (optional)
                  |                                |
                  |<=========  DATA (RCa) =========|
                  |==========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|
                  |                                |
                  |------ASP Inactive (RCa)------->|  RC: Routing Context
                  |<----ASP Inactive Ack (RCa)-----|
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |
                  |------------ASP Down----------->|  (optional)
                  |<--------ASP Down Ack-----------|  (optional)
                  |                                |

    In this approach, only one single exchange of ASP Up message can be
    considered as enough since the response by the other peer can be
    considered as a notice that it is in ASP_UP state.

    For the same reason, only one ASP Down message is needed since once
    that an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed to receive ASPSM
    messages.

    Registration/deregistration procedure is supported.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Nov 2002 10:23:23 -0700

PELLAN,HERVE,

PELLAN,HERVE (HP-France,ex1) wrote:              (Mon, 25 Nov 2002 17:30:40)
> 2. When using dynamic registration of Routing Keys, only DE IPSP is allowed.

I disagree with this: why would one want to disallow already OPTIONAL
registration for SE?

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 25 Nov 2002 11:55:12 -0800 (PST)

After long discussions the consensus was that IPSP is
intended to be AS-to-AS. IMO, DE does not fit this
model, so my personal preference is to keep IPSP as it
is.
If the problem case with dynamic registration is
presented in the forum (because till now it wasn't),
we might try to find a solution for it within the
boundaries of current IPSP model.
DE is totally a different model and thinking that both
SE/DE can coexist is not logical IMO.

   Regards,
    Tolga

--- "PELLAN,HERVE (HP-France,ex1)"
<[email-masked]> wrote:
>                                        |            
>  |
>                 |      Other   +-------|            
>  |
>                 |              |    ASP    |     |
> ASP
>                 |              |    Active |     |
> Inactive
>  |
>                 |                     
>       SCTP RI   |                          |     v
> SCTP RI
>                 |                     
>  |
>                                        |            
>  |
>                                        |            
>  |
>                 |        Other +-------|            
>  |
>                 |              |    ASPAC/ |     |
> ASPIA/
>  |
>  |
>                 |                     
>          ASPDN/ |                          |     |
> ASPDN /
>       SCTP RI   |                          |     |
> SCTP RI
>                 |                     
>  |
>                                        |            
>  |
>                                        |            
>  |
>                 |        Other +-------|            
>  |
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran