NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 11-Oct-99
Chair(s):
Lyndon Ong <long@nortelnetworks.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:sigtran@standards.nortelnetworks.com
To Subscribe: listserv@standards.nortelnetworks.com
In Body: subscribe sigtran
Archive: http://www.nortelnetworks.com/standards
Description of Working Group:
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.
Goals and Milestones:
Nov 98 |
|
Submit Initial draft of Signaling Architecture and Performance Requirements document as an Internet-Draft |
Jan 99 |
|
Issue initial IDs on Transport Layer Protocols and Encapsulation of Signaling Protocols |
Apr 99 |
|
Submit requirements document to IESG for publication as an RFC |
Apr 99 |
|
Submit revised version of drafts incorporating discussions and early implementation experience. |
Jul 99 |
|
Submit protocol RFCs to IESG for publication as Proposed Standards |
Internet-Drafts:
· The application/ISUP media type
· Performance Requirements for TCAP Signaling in Internet Telephony
· VoIP Signaling Performance Requirements and Expectations
· Framework for SIGTRAN Common Transport Protocol
· Simple Control Transmission Protocol
· SS7 MTP2-User Adaptation Layer
Request For Comments:
RFC |
Status |
Title |
RFC2719 |
Architectural Framework for Signaling Transport | |
Minutes of the 46th IETF SIGTRAN WG Session, Washington DC, 11/09/99
CHAIR: Lyndon Ong <long@nortelnetworks.com>
Reported by Matt Holdrege holdrege@lucent.com
The Sigtran WG met for one session on November 9, 1999. There were approximately 180 people in attendance.
Introduction and agenda bashing (5 min.)
The Agenda was accepted. See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/agenda.ppt
Recap Sigtran objectives and progress (5 min.)
The architecture and requirements document is now RFC 2719. The protocol documents were originally scheduled for submission to IESG in July 1999, but they are still in draft. The chair emphasized that it is important that the group finish the protocol documents as soon as possible.
Status reports
M3UA
draft-ietf-sigtran-m3ua-00.txt
Greg Sidebottom <gregside@nortelnetworks.com>
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/m3ua-wash99.ppt
This draft was previously known as ITUN. There were still a number of issues to be addressed for M3UA. A Design Team meeting was scheduled for Wednesday, Nov. 10th to discuss issues with M3UA and the other adaptation layers. Current and potential comments will be incorporated into a new draft sometime in December, with target to do WG Last Call before the end of the year.
It was suggested that the draft include an architectural model that describes the different scenarios for M3UA. It was agreed that the draft should not constrain potential implementations.
IUA
draft-ietf-sigtran-iua-01.txt
Ken Morneault kmorneau@cisco.com
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/IETF-iua-wash99.ppt
The ISDN portions of this draft have been reviewed and are mostly complete, but more review is welcome. But there are other issues that are common to all the adaptation modules.
M2UA
draft-ietf-sigtran-m2ua-01.txt
Ken Morneault kmorneau@cisco.com
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/IETF-m2ua-wash99.ppt
Ram.Dantu <ram.dantu@usa.alcatel.com>
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/m2ua-case2.ppt
Ram discussed separation of Case 1 and Case 2 applications of M2UA, and recommended M2UA as a possible solution for high speed links. He noted that SSCOPMCE has been defined in ITU-T SG11 for ATM links and possibly IP connectionless environment. Ram noted that SCTP could be used for these links with some minor modifications.
SCTP
draft-ietf-sigtran-sctp-03.txt
Randy Stewart < rstewar1@email.mot.com>
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/sctp.ppt
Since Oslo, fragmentation and bundling have been added. Security cookie mechanism was added. Congestion control and retransmission times have been re-worked. Message format restructured for extensibility and better performance. IANA considerations section added and security considerations sections.
So far they have received no outstanding technical issues. They should soon have a reference implementation available.
There was a suggestion that SCTP be run directly over IP, and Randy was amenable to applying to IANA for a protocol ID. However the current draft runs over UDP/IP, and it was agreed that this should proceed ahead as is. Also, comments were made that running over UDP is better for interoperability and allows the application layer to have more control.
Lyndon asked the group if anyone objected to announcing last call for version 3 of SCTP. There were no objections so Lyndon will formally announce this to the list.
Lyndon said that he hopes to do last call for the adaptation modules in December.
PacketCable presentation:
Ed Miller from CableLabs talked about ISTP, which is analagous to M3UA and can run over TCP or SCTP. It will be released publicly by the end of November and may be submitted as an informational Internet Draft(s). Lyndon asked about IPR for ISTP and Ed said that use of specifications was royalty-free for members of the consortium but outside the consortium was up to the individual vendors involved in defining the specifications.
Neil Olson (neil.olsen@ieee.org) gave an overview of ISTP (Internet Signaling Transport Protocol)
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/istp.ppt.
Lyndon noted that any potential PacketCable drafts would not be official SIGTRAN work items.
MIB:
Maria Carmen Belinchon Vergara maria.c.belinchon@ericsson.com has volunteered to develop MIBs for SCTP and M3UA. She expects to have an SCTP MIB draft ready in about a month and an M3UA MIB draft in another few months. The group expressed hearty thanks for her efforts.
Other adaptation layers:
SCCP UA and DPNSS UA could soon be coming and Lyndon would like it to be possible for people to develop adaptation layers independent of the working group. An IANA mechanism will have to be set up for this.
Other Groups
ITU SG 16
Ian Rytina (ian.rytina@ericsson.com) talked about activities in SG16. H.248 over SCTP is discussed in Annex H of the white paper. H.225 call signaling is defined for UDP, TCP or Annex E, but there was a proposal and support for SCTP there as another option. SG16 must wait for an RFC number for SCTP before they can refer to it.
ITU SG 11
Jay Hilton (hiltonj@nortelnetworks.com), the chair of WP 4 in SG11 was present. Jay is to put together a report of what is happening in SIGTRAN on behalf of the SOI for SG11. Ian noted that WP2 is working on BICC not only for ATM, but also for IP. Lyndon asked whether SCTP is b eing considered as transport for BICC, but Ian said it is too early make an implementation decision on this in SG11.
3GPP
(see ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/sigtran-3gpp-2.zip)
John Loughney (john.loughney@nokia.com) presented information about the status of 3GPP activities for wireless, where SCTP and M3UA are planned to be components of the 3GPP architecture.
Applicability Statements
draft-coene-sctp-applic-state-00.txt & draft-coene-ss7-over-ip-00.txt
Lode Coene < lode.coene@siemens.atea.be>
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/Applic-State.zip
A large show of hands supported the development of these drafts. It was mentioned that this work should evolve over time as real world usage of SCTP defines the main points of applicability. It was also mentioned that there is a difference between an Applicability Statement and a Best Current Practices document and that we should think about which one we need or if we need both. Further discussion was referred to the list to identify more clearly what items would go into an AS (BCP would probably follow after some implementation experience).
Other
Streams
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/streams.ppt.
Hanns-Juergen Schwarzbauer <hannsjuergen.schwarzbauer@icn.siemens.de> presented an analysis of the use of streams in SCTP for different applications, e.g., mapping streams to SLS code or to signaling link in SS7. It was suggested that this information would be useful input to the AS for SCTP.
updated performance analysis
draft-ietf-sigtran-performance-req-01.txt
See ftp://standards.nortelnetworks.com/sigtran/presentations/wash99/perf.ppt.
Kun-Min Yang dyang@research.telcordia.com presented an update to performance analysis work that had been started earlier in Sigtran discussions. This was not discussed in detail, but questions were referred to the Telcordia authors.
None received.