NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Lyndon Ong <lyong@ciena.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:sigtran@standards.nortelnetworks.com
To Subscribe: lyris@lyris.nortelnetworks.com
In Body: subscribe sigtran in the SUBJECT field
Archive: ftp://ftp.ietf.org/ietf-mail-archive/sigtran/
The primary purpose of this working group will be to address the transport of packet-based PSTN signaling over IP Networks, taking into account functional and performance requirements of the PSTN signaling. For interworking with PSTN, IP networks will need to transport signaling such as Q.931 or SS7 ISUP messages between IP nodes such as a Signaling Gateway and Media Gateway Controller or Media Gateway.
Examples of such transport include:
- transport of signaling between a Signaling Gateway and Media Gateway or Media Gateway Controller - transport of signaling ("backhaul") from a Media Gateway to a Media Gateway Controller - transport of TCAP between a Signaling Gateway and other IP nodes
Applications include:
- Internet dial-up remote access - IP telephony interworking with PSTN - Other services as identified
Specific goals are:
1. Architecture and Performance Requirements: The working group will produce an informational RFC identifying functionality and performance requirements to support signaling over IP. Signaling messages have very stringent loss and delay requirements in the existing telephone networks that need to be supported.
2- Transport: The working group will produce a standards track proposal or proposals defining transport of signaling protocols using TCP or UDP, based on the requirements identified above.
These proposals will identify the method of encapsulation of different signaling protocols. This will include differentiating between different protocols being carried, and what components are transported, translated or terminated at the SG. Security and resilience must be addressed.
Note: TCAP is a transaction protocol with different functions and requirements than call control signaling. This will need to be taken into account in its mapping to IP networks.
This work will be done in conjunction with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant signaling protocols or in the network requirements for the transport of the relevant signaling protocols.
The group will make use of existing IETF QoS and security technology and will not address creation of new QoS or security functions for IP networks. Nor will the working group work on defining new call control or device control protocols.
Done |
|
Submit Initial draft of Signaling Architecture and Performance Requirements document as an Internet-Draft |
Done |
|
Issue initial IDs on Transport Layer Protocols and Encapsulation of Signaling Protocols |
Done |
|
Submit requirements document to IESG for publication as an RFC |
Done |
|
Submit revised version of drafts incorporating discussions and early implementation experience. |
Done |
|
Submit IP-based transport protocol draft to IESG for publication as a Standards-track RFC |
Done |
|
Submit initial adaptation drafts to IESG for consideration as a Proposed Standard |
Nov 00 |
|
Submit protocol MIB draft to IESG for consideration as an Proposed Standard |
Done |
|
Submit protocol Applicability Statements draft to IESG for consideration as an Informationl RFC |
Feb 01 |
|
Submit secondary adaptation drafts to IESG for consideration as a Proposed Standard |
· SS7 MTP2-User Adaptation Layer
· SS7 MTP3-User Adaptation Layer (M3UA)
· Stream Control Transmission Protocol Management Information Base using SMIv2
· Stream Control Transmission Protocol Applicability Statement
· SS7 SCCP-User Adaptation Layer (SUA)
· Telephony Signalling Transport over SCTP applicability statement
· SS7 MTP2-User Peer-to-Peer Adaptation Layer
· SS7 MTP3-User Adaptation Layer (M3UA)Management Information Base using SMIv2
· SCTP Unreliable Data Mode Extension
RFC |
Status |
Title |
RFC2719 |
Architectural Framework for Signaling Transport | |
RFC2960 |
PS |
Stream Control Transmission Protocol |
RFC3057 |
PS |
ISDN Q.921-User Adaptation Layer |
Sigtran Working Group Meeting Notes
August 7, 2001
Presentation urls listed at the end
Reported by: Ken Morneault
The Sigtran WG met on August 7, 2001 with 99 people attending.
Agenda bashing - Lyndon Ong
* Noted that v5 and M3UA MIB representatives not available at this meeting, so these topics were not discussed.
Status of Working Group Milestones - Lyndon Ong
Slow progress since the last meeting in terms of progression of drafts. Plan to move Working Group into dormant status ASAP when charter items are completed.
SCTP Status - Lyndon Ong
SCTP extensions and discussions moved to TSV WG.
There is still an outstanding issue in regards to error check. Proposed CRC-32 alternative is controversial because it is not backwards compatible. Will need to move to have another bakeoff after decision made.
A question was raised on the status of the U-SCTP proposal. Scott (as TSV chair) said it is still open for discussion in the TSV WG.
M2UA status - Lyndon Ong
Completed WG Last Call. Next version being prepared for IESG Last Call.
M3UA status - Lyndon Ong
Completed WG Last Call. However, there are still a number of outstanding issue and comments. Next version will hopefully go to IESG.
Applicability Statements - Lyndon Ong
SCTP AS completed Last Call. Working to resolve comments from Area Directors. ADs would like focus of document to be refocused on comparison of SCTP characteristics against TCP/UDP and to make recommendations as to when SCTP should be used vs. TCP/UDP. Previous focus of the document was problems that implementers could run into when trying to use SCTP.
SUA Status - John Loughney
WG Last Call started on Monday. Comments have been received. They will be numbered and sent to the list. The ASP Management procedures are being re-synced among M3UA/M2UA/SUA.
Summary of current comments:
(see John's slides)
Next steps (SUA)
Resolve issues, update draft and reissue as SUA v08. Plan to have IESG Last Call before next IETF meeting.
Question: TUA draft dropped because of lack of interest. Concern that SUA needs to cover all needs of TCAP.
Answer: The goal of SUA was to cover all SCCP-users including TCAP. If anyone sees any holes, please note them to the list during the last call.
M2PA Status - Kurt Damm
Quick review of M2PA status. Note new version of draft: M2PA v3.
The new draft includes:
* proving (normal and emergency) procedures for alignment
* common header format accepted
* SCTP associations can be started before MTP3 Start primitive
* version control
Open issues:
* Does M2PA need its own sequence numbers? Current proposal is no.
M2PA Interoperability Test
Alcatel plans to host in Plano, Texas. Proposed dates are October 29-November 2. Details will be posted to a web site by the end of August.
Would like to go to Last Call. We will consider if it is ready for Last Call after M3UA and SUA complete Last Call.
Question: Why was proving added back into the draft?
Answer: Felt it was need to ensure the quality and performance of the association before passing MTP traffic. Still open for comment on the list.
DUA Status - Anil Kumar
DPNSS/DASS2 extensions to IUA. Brief overview of what DPNSS and DASS2 along with architecture of DPNSS/DASS2 backhaul. Brief overview of extensions required to IUA to support DPNSS/DASS2.
Two comments from the floor that draft should be moved forward into Last Call. Lyndon wants to wait until other UAs move through Last Call process, then DUA can be submitted.
SCTP MIB status - Maria
Changes:
- added sctpMaxAssoc based on TCP folks' comment
- context change for checksum error
- added port type based on TCP MIB work
Open Issues:
- use of counter32 vs. counter64
-- it was suggested that the editor get help from Bert Wijnen, one of the A-Ds for that area, concerning this issue.
Version 5 will incorporate TCP MIB alignment. We need to clarify if we should Last Call SCTP MIB before the TCP MIB is finalized.
Bakeoffs - Lyndon Ong
Lyndon noted that bakeoffs are not an official activity of the Working Group, but the WG is a good place to coordinate them.
Scorecard:
SCTP - 3 bakeoffs
M3UA - 1 bakeoff
IUA - tentative plan to joint Megaco bakeoff (the week of Sept. 9th at UNH)
M2UA - ?
SUA - Offer, Belgium in Oct/Nov
M2PA - Offer, Plano, Texas in Oct/Nov
Noted from floor that Softswitch plans to offer full end-to-end testing during the 1st week of November in CA.
Presentations:
ftp://standards.nortelnetworks.com/sigtran/presentations/london01-agenda.doc
ftp://standards.nortelnetworks.com/sigtran/presentations/london01-sua.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/london01-m2pa.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/london01-dua.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/london01-mib.ppt
None received.