NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 02-Mar-00
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:
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. |
Feb 00 |
|
Submit IP-based transport protocol draft to IESG for publication as a Standards-track RFC |
Mar 00 |
|
Submit UDP-tunneling transport draft to IESG for publication as an Experimental RFC |
Mar 00 |
|
Submit adaptation protocol drafts to IESG for publication as Standards-track RFCs |
May 00 |
|
Submit protocol MIB draft to IESG for publication as a Standards-track RFC |
Jun 00 |
|
Submit protocol Applicability Statement draft to IESG for publication as Informational RFC |
Internet-Drafts:
· VoIP Signaling Performance Requirements and Expectations
· Simple Control Transmission Protocol
· SS7 MTP2-User Adaptation Layer
· ISDN Q.921-User Adaptation Layer
· SS7 MTP3-User Adaptation Layer (M3UA)
· Tunneling of SCTP over Single UDP Port
· Simple Control Transmission Protocol Management Information Base using SMIv2
· Simple Control Transmission Protocol(SCTP) applicability statement
Request For Comments:
RFC |
Status |
Title |
RFC2719 |
Architectural Framework for Signaling Transport | |
SIGTRAN WG Wednesday, March 29, 2000
Reported by Matt Holdrege.
The agenda was presented and accepted.
1. INTRODUCTION
The SIGTRAN WG met for 2 1/2 hours on March 29, 2000. There were approx. 135 people in attendance.
The chair asked for a readout from the room on whether there was consensus that work on SCTP was the right direction and should be progressed. Humms in favor of the current directions and planned progress of SCTP were unopposed by the attendees.
2. SCTP STATUS - Randy Stewart. <rstewar1@EMAIL.MOT.COM>
We are currently in IETF last call for SCTP. Randy listed three main technical changes that have been proposed.
It has been proposed to add a hostname or FQDN to the INIT chunk to make things easier for NAT. This is optional to send, but implementations MUST receive. There were no objections to the change.
It has been proposed to add the option to truncate data at a user requested time-out. There were concerns expressed that the upper layers will not reliably know whether the data arrived or not. Should we extend the SACK again to report this, adding more complexity? It was agreed not add this option at this time.
It was proposed to include the ability to add or delete IP addresses from an association. It was proposed that this should be addressed at a later date through a separate document, since it does not appear to be a simple modification. There were no objections to this proposal.
3. SCTP and IPSEC - Steve Bellovin smb@research.att.com
SCTP requires some changes to IPSEC: Minor issue: Policy rule changes should be defined in a new RFC. Major issue: Multihomed connections are not properly supported. IPsec AH and ESP can do it, but IKE cannot. It would take a change to IKE to fix this. IKE would have to permit multiple addresses as endpoint identifiers. It was asked if we could use names or ranges of addresses, but it seems that today's IKE implementations might have difficulties with this. For initial implementations, where the number of addresses is limited (e.g., primary and backup, for a total of 4 per session) separate SAs can be created for each pair of communicating addresses.
This will be discussed further in the IPsec WG.
4. SCTP TUNNELING - draft-ietf-sigtran-sctptunnel-00.txt Lyndon Ong long@nortelnetworks.com
This provides a way of tunneling SCTP where either the OS does not support raw_IP sockets or where use of a new IP protocol number is not desired. There has been a UDP port registered for tunneling of SCTP and it is expected that routers will be able to forward this traffic, although they may not be able to perform special handling on this protocol such s prioritization using current software. The IANA-assigned UDP port number is 9899.
People are encouraged to review the draft and comment. It will be advanced to WG Last Call after deliberations on SCTP are complete.
5. SCTP BAKE-OFF Michael Tuexen <Michael.Tuexen@icn.siemens.de>
An SCTP bake-off/interoperability test has been scheduled for the 5th-9th of June in Munich. Focus will be very basic testing of bringing up and down associations and passing data. Also multihoming and failover should be tested along with flow control, attacks and error handling.
It was suggested that we should test multiple streams. A full list of test scenarios will be prepared. A mail list (sigtran-test@standards.nortelnetworks.com) will be setup for the bakeoff and announced to the general SIGTRAN email list.
Facilities will include network connections, IP addresses and packet tracers.
6. ADAPTATION LAYER OVERVIEW
We now have IANA port numbers assigned for the IUA (9900), M2UA (2904) and M3UA (2905).
6.1 M3UA Greg Sidebottom <gregside@nortelnetworks.com> See slides.
Greg described remaining open issues in M3UA and the other adaptation layers. The list has been greatly reduced from the last interation, and remaining issues will be addressed in Draft 03 to be out by end April and they hope to initiate WG last call after that.
It was suggested that we should have a requirements document. Lyndon said that if anyone had the initiative to generate requirements, they should send their thoughts to the list.
6.2 IUA AND M2UA draft-ietf-sigtran-iua-02.txt & draft-ietf-sigtran-m2ua-03.txt Ken Morneault
<kmorneau@cisco.com> See slides...
Lyndon noted that these documents can go to last call independently. So if the IUA is nearly done, it may go to last call soon while work continues on the M2UA.
6.3 M2Peer Wayne Davis <Wayne.Davis@usa.alcatel.com>
It was proposed to split the backhaul and peer2peer sections of M2UA to make the documents more readable and concise.
Others in the audience questioned the value of splitting the document. Other editors agreed that there are serious issues that need to be solved, but that they could be solved in the same document. Others saw a clear split between transporting primitives and PDU's and it should be split for M2UA, but not M3UA.
We could not resolve the issue in the meeting and it was requested that the two camps present more detailed arguments to the list to help determine the best course.
6.4 SUA draft-loughney-sigtran-sua-00.txt John Loughney <john.loughney@nokia.com> See slides
It was asked if Global title was considered. John said that several solutions were possible for working with global title in SUA.
It was proposed that this document become a working group item. There were no objections.
6.5 TCP
A few sentences of text were proposed by Matt Holdrege and Greg Sidebottom for the UA's. These would recommend the use of SCTP for several reasons, but allow for the use of TCP when such reasons are not required. The new text will be included in the next rev of the drafts. There were no objections from the group.
7. SCTP MIB Javier Pastor <j.javier.pastor@ericsson.com> See slides...
A draft is now available with the SCTP MIB (draft-ietf-sigtran-sctp-mib-00.txt) There was a suggestion to compile statistics for individual streams, but concern was expressed due to the potential volume issues. Instead it was suggested to provide some statistics on selected streams only.
8. SCTP Applicability Statement - draft-ietf-sigtran-sctp-applicability-00.txt Michael Tuexen
<Michael.Tuexen@icn.siemens.de> See slides...
There will be both an SCTP AS and a SCTP for Signalling Transport AS. New drafts will be issued soon. Help with this work is welcome.
9. REGISTRATION PROPOSAL - DDP - draft-xie-stewart-sigtran-ddp-00.txt Randy Stewart
<rstewar1@EMAIL.MOT.COM>
DDP is a proposal from the authors for a protocol/system for supporting registration, name resolution and dynamic provisioning of signaling applications using Sigtran. There was a great deal of interest in the proposal, but also many questions regarding the scope. Some pointed out that existing solutions would remove the need for this protocol, or at least some parts of it. It was suggested that the scope/abstract be updated to better explain the requirements. It was also suggested that the authors socialize this draft with the IAB and APPS area directors and specifically Keith Moore who has done a lot of research in this area.
More discussion will be required on this topic.
10. CHARTER EXTENSION
It was proposed that we add the MIB and AS to the list of work items in the charter, but that we wait on further discussion of DDP before asking for a larger extension to the charter.
Agenda
SCTP Applicability Statement
SCTP bake-off meeting
DDP - An Architectural Overview
Requirements for Fault Tolerance in SIGTRAN
"draft-ietf-sigtran-iua-02.txt"
M3UA (MTP3-User Adaptation Layer)
M2UA Peer-Peer Adaptation Layer SIGTRAN
SCTP MIB
SCTP Status
SCCP User Adaptation Layer
IPsec Issues for SCTP