Re: Sigtran extension for network management and association changeover.

Xiangsong,

No, that is not right.  You are coming at this rather late in
the game.  M2PA first attempted to use SCTP's transport layer
ack in its functionality but it became impossible.
Modifications to SCTP were not seen to be appropriate when an
application level ack would suffice.  Not even all SIGTRAN
layers require this capability, and modifications to SCTP would
force the capability on all applications.

I quite frankly agree with the consensus that was taken by tsvwg
in these M2PA discussions and am resistant to a draft that would
go against that consensus now.

The corid draft does not require any changes to protocol
elements.  See the section entitled "Interworking".  The
approaches used in this section do no require any changes to the
protocol or even for the peer to support the procedures.  This
approach (similar to the time-controlled changeover and
changeback procedures of SS7) is used by a number of commercial
implementations of M3UA.  Standardization has not been necessary
because the procedures are local, only rely on existing protocol
elements and procedures, do not rely on implementation of the
procedures at the peer, are largely implementation related, and
are performance based implementation options.

I resubmitted the corid and about 8 or so other extension drafts
for 5 to 7 years while the working group was active and none
were taken up as WG items.  For example:

 http://tools.ietf.org/html/draft-bidulock-sigtran-aspcong-01
 http://tools.ietf.org/html/draft-bidulock-sigtran-aspext-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-isua-04
 http://tools.ietf.org/html/draft-bidulock-sigtran-loadgrp-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-loadsel-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-m2pa-test-08
 http://tools.ietf.org/html/draft-bidulock-sigtran-m2ua-ss7test-03
 http://tools.ietf.org/html/draft-bidulock-sigtran-regext-04
 http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05

The necessary (but not all) protocol elements for corid-05 and
regext-04 made their way into the UAs.  loadgrp-05 and
loadsel-05 are not supported in any way, leaving SLS as the only
rational basis for loadsharing.  The connection id components of
regext-04 are not supportted, making connection-oriented SCCP in
SUA useless.

After 8 years of banging my head on that, I think it unlikely
that there will be a rally around these concepts now that the WG
is shut down.  There is no charter, and these types of drafts do
not seem sufficient to create one.  For example, far more
important items (the lack of an M3UA MIB, and MIBs for any other
SIGTRAN UAs) cannot keep open or resurrect the WG.  You can
likely get more traction in forums that use SIGTRAN such as
ITU-T and 3GPP.

My advise (whether you want it or not) is to find procedures
such as those in the corid Interworking section that fits your
implementation.  Do not use any proprietary protocol elements.
Do not require any optional procedure of the peer.  Corid shows
that it is possible (if not preferred) in the Interworking
section.  If the corid procedures seem too complex for you, make
your implementation simpler.  If after that you want to share
all your work with the IETF, put forth a draft that describes
your implementation as an INFORMATIONAL RFC.

I won't even consider reviewing a draft that attempts to provide
protocol elements or requires changes in procedures at the peer,
either at SCTP or UA levels; because my first criticism will be
that it requires protocol elements and requires changes in
procedures at the peer: neither of which are possible nor
necessary at this point.

--brian


Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 10:44:50)
> Dear Brian,
> 
> I have read the corid draft and have some thought.
> 
> >http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
> >several mechanisms that are completely local and accomplish this
> >without protocol changes: neither in SCTP nor the UA.  UAs, such as
> >M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
> >that already accommodate these procedures.
> >
> >--brian
> 
> In my understanding, the corid draft and my association-changeover draft 
> are for
> the same goal, the main difference is corid draft works in UA (or SPP) 
> layer while my association-changeover draft focuses on SCTP layer.
> 
> The detailed differences include:
> 1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as 
>    M2UA, M3UA, SUA, ISUA.....
>    Association-changeover draft only changes SCTP protocol.
> 2, Corid draft brings many transport functionalities into UA layer, such as 
> corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 
>    4.1.3) and buffering
>    (section 4.1.4). These features bring complex and repeated job into UA 
>    layer and would make UA hard to work.
>    Association-changeover draft incorporates SS7 changeover functionality 
>    in Sigtran,
>    the peers exchange sequence information, and the sender resends the 
>    unacknowledged messages.
> 3, Determining which messages have already been acknowledged?
>    Corid draft accomplishes it in UA layer (<5>  IMPLEMENTATION NOTE of 
>    corid draft), it is out of the scope of corid draft but that is really 
>    difficult.
>    Association-changeover draft accomplishes it in SCTP layer by TSN, it is 
>    very easy.
> 4. Corid draft requires all traffic packets to include id information 
> (section 4.1.3), which would waste bandwidth of the network.
>    Association-changeover draft takes normal traffic transport procedure.
> 5. Corid resends all undetermined messages (including the acknowledged 
> messages) to the peer, and the messages are determined by the peer node.
>    Association-changeover resends only the unacknowledged messages to the 
>    peer.
> 
> Are those right?
> 
> Thanks and regards
> Xiangsong

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