SIGTRAN Working Group Meeting Notes - December 10, 1998 Chair: Lyndon Ong - long@nortelnetworks.com Reported by Matt Holdrege - matt@ascend.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 charter. 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. 2. Requirements The group reviewed requirements from RSGP (Matt Holdrege - no slides used), Etheric (Ian Rytina, ian.rytina@ericsson.com) 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, mmcgrew@lucent.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 (henry.sinnreich@mci.com) 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 (hlin@bellcore.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 (gene_ma@nortelnetworks.com) 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 (emedasa@madrid.ericsson.se) 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 (taylor@americasm01.nt.com) and Gur Kimchi (gur.kimchi@etsi.fr) 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 1999.