Subject: Proposed Liaison Response to ITU-T SG15 on G.799.1

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 26 Dec 2001 16:20:28 -0800

Folks,

Attached is the proposed response to ITU-T SG15's liaison to us
back in November.  The response is based on comments I have
received on their document.

Please let me know any further comments by Friday, otherwise
I will send this off.

Cheers and Happy Holidays,

L. Ong

----------------------------------------------------------------------------
-

Liaison Response

To: ITU-T SG15
From: IETF Sigtran Group
Contact: Lyndon Ong
Tel: +1 408 366 3358
E-mail: [email-masked]

We greatly appreciate your notification and request for comments
concerning proposed Recommendation G.799.1.  This has been
circulated to interested parties within the IETF Sigtran Working
Group and a number of comments were noted on Figure 2 of
the document:

-- it appears from the Figure that Sigtran would be used between
a TIGIN Gateway and MGC, which means that in the terminology
that we have been using (documented in IETF RFC2719) that the
TIGIN acts as a Signaling Gateway. The M2UA adaptation layer
that has been defined in the Sigtran WG may be of particular
interest for this case, as it is designed for "backhaul" of signaling
F-link traffic to the MGC.  It was suggested that the G.799.1 
document might also note that F-links can be groomed into an
SG via a MUX, or the TIGIN would need to support Add/Drop
capability to groom the F-Links.

-- on the other hand, the Figure shows a stand alone SG separate
from the TIGIN with SIP as the protocol between SG and MGC.
We are unsure as to whether this is a recommendation or an
example.  We believe that Sigtran, especially the M3UA adaptation
layer being defined by the WG, can also be used at this
interface, depending on whether the desired function is transport
of SS7/ISDN signaling or application level conversion of, e.g., 
ISUP to SIP.  We believe that the intended functionality at this
interface could be clarified.

Regarding the status of the Sigtran protocol work, it has been agreed
within the IETF Transport Area to change the error check mechanism
in SCTP from the original Adler-32 checksum to a CRC-32 method
using the CRC-32C polynomial.  This will be reflected in a new draft
aimed at Standards Track RFC status, expected to be available by
the end of December.  The original RFC 2960 will remain in force, but
will be supplemented by the new RFC, which treats only the error
check mechanism (currently specified in an Appendix of RFC 2960).
As such, there will not be an "RFC 2960bis", this will be allowed to
expire.

M2UA has completed Working Group Last Call and is now in 
IETF Last Call, ending January 1st.  Assuming that there is no objection,
it will then be approved as an IETF Proposed Standard and will be
allocated in RFC number following final editing by the RFC Editor.

We hope that this information will be valuable to you and welcome
any further interactions that you may wish to initiate.

Sincerely,

Lyndon Ong
Chair, IETF Sigtran Working Group

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