NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 20-Nov-98
Lyndon Ong <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe sigtran
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
- 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:
Submit Initial draft of Signaling Architecture and Performance Requirements document as an Internet-Draft
Issue initial IDs on Transport Layer Protocols and Encapsulation of Signaling Protocols
Submit requirements document to IESG for publication as an RFC
Submit revised version of drafts incorporating discussions and early implementation experience.
Submit protocol RFCs to IESG for publication as Proposed Standards
No Current Internet-Drafts
No Request For Comments
SIGTRAN Working Group
Meeting Notes - December 10, 1998
Chair: Lyndon Ong - firstname.lastname@example.org
Reported by Matt Holdrege - email@example.com
160 people signed the blue sheet
The SIGTRAN archive can be found at ftp://ftp.baynetworks.com/pub/outgoing/long/sigtran
1. Agenda and Charter
The agenda escaped bashing. The group then discussed the charter as approved by IESG.
Goals of the group are: Informational RFC on requirements, standards track proposal on transport, to support encapsulation, security and resilience no new IP functions or call/device control protocols
Target - July for submission to IESG.
A question was asked by Chip Sharp on whether signalling gateway to signalling gateway was part of the charter. This is shown in the current framework document and can be addressed within the group's
Scott Bradner (AD) made clear that the group was to focus on transport of signaling protocols, and not work on the design of signalling protocols.
The group reviewed requirements from RSGP (Matt Holdrege - no slides used), Etheric (Ian Rytina, firstname.lastname@example.org) and IPDC (Ike Elliott, ike.elliott@Level3.com). Some points of note:
- SIGTRAN will address Etheric requirements for transport of ISUP over IP.
- Ike identified a list of 8 requirements, including: SIGTRAN protocol must support multiple payload types, implying a payload type identifier in each message SIGTRN sessions must be proxyable to pass through firewalls SIGTRAN must be able to multiplex multiple sessions on one underlying session SIGTRAN must include an identifier for the physical interface SIGTRAN must include an identifier for the logical entity on which the signalling originates/terminates. Nomenclature for identifiers must be designated. This could be a DNS name or IP address. SIGTRAN must allow transport of ISUP, QSIG, TCAP, DPNSS, DSS1 as well as be extensible to other signalling protocols. Other protocols such as IS41 and GSM MAP were also identified. SIGTRAN must be transactional and application level acknowledged (subsequently Ike has modified this to require just reliable delivery. There were issues with the word "transactional"). SIGTRAN must be capable of meeting the performance requirements of these protocols in real networks.
Steve Cohoon also noted that security aspects would be important.
Ike suggested we should try to mathematically prove that the timing requirements could be met. Scott Bradner noted that this would be an interesting task on the public Internet, and that we should not assume that this would only be used in private nets.
3. New Requirements Work
Bob Abrams (presenting for Mike McGrew, email@example.com) showed a drawing of the reference entities in a layer chart. New adaptation layers were required between MTP-3 and UDP and TCP.
In response to questions, it was clarified that MTP3 would be modified to adapt to these layers, and that the scenarios being addressed here were the use of IP for transport of signaling between SS7 endpoints (as opposed to transport between an SS7 endpoint and an IP node). It was agreed (prompted by the AD) that this group will not address changes to MTP, that is ITU-T's domain. This group would not define changes to protocols being transported, only the transport itself.
Henry Sinnreich (firstname.lastname@example.org) spoke on service provider requirements for IP Telephony signalling and device control. These mostly applied to design of megaco, rather than sigtran work, and was deferred to that group.
Paul Lin (email@example.com) identified a number of Internet Telephony signalling performance requirements based on PSTN, especially call setup delay requirements that affect the latency requirements for transport of signaling over IP.
There were a number of questions, in particular Scott Bradner suggested that some of the call setup delay requirements associated with user expectations could be handled in ways other than requirements on the latency of signaling transport, such as provision of reassuring tones or indications. It was suggested that protocol-based requirements such as timers should be differentiated from user-based requirements such as post-dial delay. It was also suggested that there may be a range of services from high quality to low, and that the group should not assume automatically that PSTN requirements will be the target for all applications.
Scott Bradner noted that the RUTS BOF asked for a muxing protocol to handle the issues of packet handling in a congested scenario, and that this work may be relevant to SIGTRAN.
The work on requirements will be incorporated through enhancements of the iRFC on signaling transport requirements. The group is encouraged to work on extensions to the existing framework document.
4. TCAP over IP and Other
Gene Ma (firstname.lastname@example.org) presented a proposal for TCAP transport over UDP (T/UDP). This identified several requirements and proposed protocol enhancements to support TCAP and SCCP addressing and management.
David Sanchez Ariz (email@example.com) presented an architecture for SCCP transport over IP called Simple SCCP Tunnelling Protocol - SSTP, and identified similar need for protocol to support SCCP addressing and management.
Scott Bradner reiterated that the group is addressing the issue of replacing the wire between the two switches using IP instead of a TDM channel. There was some uncertainty about whether the issues of routing fall within the charter. (In the Chair's view, the issue is not so much routing in an IP sense as the mapping of protocol at the Gateway, which affects the information that needs to be encapsulated and transported for TCAP and SCCP). More clarification is needed on this issue.
Scott Petrack (Scott_Petrack@vocaltec.com) proposed using RTP to signal events. Features include: Real time, reliable, in order delivery Delivery to controller of all event info Association to media stream Global time synchronization Muxing across single port
This will be compared with other potential protocols through discussion on the mailing list.
Tom Taylor (firstname.lastname@example.org) and Gur Kimchi (email@example.com) provided input from current work in ITU-T SG16 and ETSI TIPHON. Gur is the editor for work in SG16 on an annex (E) to support transport of H.323 signalling over UDP rather than just TCP. This work provides a framework that may be useful for SIGTRAN as well. Gur identified documents on the PictureTel website for those interested in following up. SG16 plans to approve this framework in early 199