Subject: [Sigtran] IPSP dynamic registration

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Fri, 6 Dec 2002 17:12:49 +0100

Hi all,

To conclude the thread "[Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day
2" with respect to the support of the Dynamic Registration between IPSP:

1) Dynamic Registration in Single Exchange:
===========================================

Concerning the Dynamic Registration use in Single Ended mode of operation,
we would like to hear whether, at least two implementations successfully
interoperated, and more specifically, showed that when REG REQ are generated
at the same time by the two ends, each implementation was able to handle the
race condition and the consequences. The following message flow illustrate
the race condition issue.

If multiple implementations didn't show that dynamic registration works in
Single Exchange, then, from a standardization point of view, this feature
must be either fixed or dropped for IPSP Single Exchange, as proposed in the
Implementor's Guide text proposal attached (See point 2)).

Single Exchange dynamic registration issue:

IPSP A                              IPSP B

   |-------------ASPUP---------------->|
   |<------------ASPUP ACK-------------|
   |                                   |
   |------------REG REQ (RK_A)-------->|
   |<----------REG REQ (RK_B)----------|

Then what's happen ?
Possibly:
   |------------REG RSP(RC_B)--------->|
   |<-----------REG RSP(RC_A)----------|
                   .
                   .
                   .

Either RC_A and RC_B are correlated in some way, or if not, then possibly
each end will generate its own ASPAC with its own RC ?? It looks then like
Double exchange ...

We don't think that there is any easy way to fix the issue with Single
Exchange, as we feel the fix would actually be a Double Exchange mode of
operation which is not the scope of this e-mail. So proposal is to NOT
support Dynamic Registration with Single Exchange.

2) Implementor's Guide text addition proposal:
=============================================

We are therefore proposing to amend the current M3UA implementor's guide
with the attached text.

Basically, when using dynamic registration of Routing Keys, only Double
Exchange 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.

-----------------------------------------------------------------------
         /\\/\0 Herve PELLAN       /\    Telnet:  779-4511
  /\    /  \\                  /\ /  \   non-TN:  (33) 4-76-14-4511
 /  \/\/    \  Telecom Infrastructure \  Fax:     (33) 4-76-14-4323
/    \ \     \_Division      /  /      \ e-mail:
[email-masked]
                                         e-card:
https://ecardfile.com/id/Herve_Pellan
              HEWLETT PACKARD  
              5 Av R. Chanas 38053 Grenoble Cedex 9
              FRANCE
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Dec 2002 10:37:57 -0700

PELLAN,HERVE,

Comments below...

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Fri, 06 Dec 2002 17:12:49)
> 1) Dynamic Registration in Single Exchange:

Not yet.  Implementation is only required when the spec advances from
Proposed Standard.  We're not at Proposed Standard and implementation
is not even required to acheive Proposed Standard.

> support Dynamic Registration with Single Exchange.

This is not how SE dynamic registration works.  The side that is
capable of responding to a registration can already generate an
RC for the RK.  Therefore, only the side incapable of assigning
a RC for the RK need generate a REG REQ.  For the same RK, why
would IPSP A generate a REG REQ if it can generate RC in response
to a REG REQ on the same RK?

> 2) Implementor's Guide text addition proposal:

Proposal unnecessary.

--brian

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