SIGTRAN Working Group Meeting Notes Wednesday, July 14, 1999 OSLO, Norway This session was recorded and broadcast on the MBONE Chair: Lyndon Ong - long@nortelnetworks.com Report provided by: Matt Holdrege - holdrege@lucent.com 1. Agenda bashing The agenda was accepted with a brief addition from the PILC WG. Aaron Falk (afalk@panamsat.com) of the PILC WG requested coordination with SIGTRAN. They have a document on performance enchancing proxies (spoofing) The goal is to enhance TCP performance on a disadvantaged channel such as wireless. See draft-ietf-pilc-pep-00.txt or http://pilc.grc.nasa.gov/pilc 2. Architecture status The framework doc is on 3d draft. The chair asked if it is ready for last call. The meeting approved start of Working Group Last Call by hum. Protocol architecture document - draft-sigtran-common-transport-00.txt was presented by Ian Rytina. Ian presented a conceptual picture of signaling transport identifying sublayers that provide functions of sequencing, reliability, link control and UDP transport. A number of adaptation modules will be supported to specific SCN protocols based on their management requirements. Initial modules are ISUP/SCCP, DSS1(with Q.921 primitives) and MTP3 (with MTP2 primitives). Ian proposed that there should be one RFC for each adaptation module. The ITU SG11 document structure can serve as a template for these RFC's. 3. Performance status Paul Lin - Telcordia - presented work on VoIP call setup performance requirements and expectations from Draft-ietf-sigtran-performance-req-00.txt Paul's methodology was to derive POTS call setup delay requirements from existing standards for delay across individual components of a hypothetical reference connection (e.g., delay across an STP, across a switch, etc.) summed up. This results in an overall end-to-end figure, which should then be analyzed to determine delay requirements for specific IP components such as SIGTRAN. It was mentioned that the results of the requirements represent the maximum delay, but not necessarily the target delay that implementers should work toward. Rich Garrett from US West proposed that they are looking at a max 2 seconds to setup a call. US West has a signalling gateway to NAS arrangement working in their network and has found that 2.5 is the very high end and 4 causes call dropping (although it was not clear what causes calls to drop, whether it is an internal network timer or end system response). US West will try to report back with more real statistics. Randy Stewart said it's usually 3-4 seconds to bring up CDMA radio connections. So wireless networks may have longer delays. Brian Rosen expressed concern that this methodology will not lead to a reasonable number. Paul is looking for suggestions on other methodologies to pursue and how to extend this work to other areas such as wireless and TCAP related setups. 4. Transport work 4.1 MDTP status As MDTP has evolved, it will change its name. The current proposal is to rename it SCTP (Signaling Common Transport Protocol). Qiaobing Xie discussed the state flow and noted its similarity with TCP. Vern Paxson said there is a flooding attack in MDTP which is analogous to TCP SYN attacks. He said the solution is a stateless cookie used in a handshake to avoid such an attack. Lyndon asked for reference for this proposed solution. Randy Stewart said there is a well commented reference implementation of MDTP. Scott Bradner on the fast recovery subject suggested that SIGTRAN would not generally be used in an environment that stresses the capacity of the network, but rather on a well engineered network. The aim is flexibility and quick response, but not to maximize throughput. Multiple links are supported for reliability rather than load balancing. It was mentioned that fragmentation is required and bundling may be added as an optional feature. Another comment was that bundling could be accomplished without affecting the protocol, by including multiple SCTP messages within a UDP packet (since each SCTP message has a length field). 4.2 MDTP analysis Hans Schwarzbauer gave an analysis on MDTP and noted that in order to support the Busy Hour Call Attempt traffic rates envisioned, the window size for MDTP will need to increase based on RTT. The initial 20 packet window is sufficient for 16 ms RTT, but much larger windows are needed for cases such as satellite links. It was noted that there are some differences between versions of ISUP that might affect the calculations to a small extent. Hans has placed an Excel spreadsheet at ftp://standards.nortelnetworks.com/sigtran for those interested in this issue. Randy Stewart noted that upcoming changes to MDTP will also affect his spreadsheet. 5. Adaptation protocols 5.1 Signaling Backhaul Ken Morneault presented the updated signalling backhaul draft. 5.2 ISUP tunneling Greg Sidebottom - gregside@nortelnetworks.com presented ISUP tunneling draft, which provides an MTP3 interface suitable for use by ISUP and SCCP. 5.3 Transport ALI John Mason presented draft-benedyk-sigtran-tali-00.txt - created to provide bridging of SCN protocols to IP devices. TALI uses TCP to carry the SCN protocol from host to host. The first day of the meeting ended with a suggestion from the chair that people interested in adaptation layers talk on the side to pull together a common structure and set of proposals to move the work quickly. 2nd day of SIGTRAN - Friday, July 15, 1999 6. TCP The role of TCP for signaling transport was discussed. There was support for keeping TCP as means for systems to support signaling transport. (Vern also suggested using one TTCP session per stream with some application level glue to handle fail-over.) Concerns were raised about adaptation layers and how easy it would be for them to support two transport methods. Folks addressing the adaptation layers were asked to look into the possibility of supporting both TCP and SCTP as transport options. 7. Review of Adaptation Work We looked at the various approaches and they were mostly common in their design. MTP2, MTP3 and Q.921 looked good and were moved forward. SCCP will be sometime in the future. Ken Morneault talked about fail-over situations between the SG and MGC. Ken will submit a slide which he diagramed describing this scheme. 8. ITU-T Work ITU-T SG11 Q15 established a liaison with a need to explore common work. SG15 Q21 sent a liaison statement looking for input on protocols to be implemented in an SG. 15/11 is developing an enhanced SSCOP for transport of SS7 over multiple AAL5 streams which would also work for a connectionless network. Q2111 is the document. In SG16 H.323 annex E as signalling transport system is for carrying H.225 messages over UDP. 9. New Topics New topics have been popping up on the mailing list. Our goals are to identify the issues, discuss how to address them and discuss the next steps. Non-goals are trying to solve the issues or expanding the scope of the WG. Goutam Shaw (goutam.shaw@bridgewatersys.com) discussed issues for semantic interoperability between SG and MGC/IP-SCP. How does an MGC register/deregister with an SG or vice-versa? The registration should b based on protocol. Do we use the FQDN for registration purposes which could provide fault-tolerance thru multi-homing? Do we require inter-SG communication for registration data for sharing links to common STP's. What about load distribution from an SG to multiple MGC's/IP-SCP's. What about connection restrictions based on IP address, SSN's, CIC? What about message authentication? What about MGC/SG failure detection and fail-over. Does it require a special registration mechanism? Do we require inter-SG communications for fail-over? It was mentioned that dynamic registration may not be needed in many systems. Most should be able to handle static registration due to long-lived associations. It was noted that many of these issues are policies of the implementation, but shouldn't necessarily be standardized as they may limit innovative schemes. It was pointed out by a service provider, that automation of provisioning is a very good thing. But difficulties lie in provisioning between multiple vendors. So standardization of certain registration functions could be very useful. It was noted that a MIB for our group would help to answer some of thiese issues and is urgently needed. Greg Sidebottom (gregside@nortelnetworks.com) (see newtopic2) discussed the IPS7 architecture and terminology for general SS7/IP interworking, and in particular discussed the ITUN address translation function. The ITUN layer maintains an address mapping table of relevant SS7 address information to an MGC process owning the MG Trunk termination. Possible SS7 information to be considered includes the IPC, DPC, SLS and/or ISUP CIC. >From the POV of an SS7 switch, a DPC now represents a virtual switch which could be a set of MGC's. Issues include SS7 point code conservation, MGC capacity, SS7 network complications, Impacts on Registration/Deregistration protocol, fail-over issues, and carryover to SCCP addressing issues. Draft-sidebotton-ips7-00.txt is available on the IETF server and covers these issues in more detail. Virgil Long (see newtopic3) presented similar ideas from the work going on for TALI. Chip Sharp (chsharp@cisco.com) talked about Security and pointed out RFC 2196 and RFC 2401for IP security references. Also discussed were address spoofing, packet sniffing, data theft, and data alteration. On the SS7 side, screening of messages is important. MTP3 mediation and TCAP protection. Brian Rosen suggested that IPSEC might not be available on small systems. In MEGACO, an option to put the AH field into the MEGACO message has been agreed for cases where the MG is built on an OS that does not support IPSEC. Participants are asked to consider whether this may occur for SIGTRAN systems as well. Rich Garrett (jrgarre@uswest.com) talked about a TALI implementation for US West's Wireless network and issues that this brings up for SS7 interworking. (See newtopic4). Rich noted that this implementation runs over TCP. We discussed CAS and what to do. Matt suggested that it is a non-issue since in his view, CAS can be mapped into DSS1 at the MG and transported using the SIGTRAN DSS1 adaptation protocol. SIGTRAN does not specify what mapping may be taking place in the MG, so there was no action taken. Ways forward: It was suggested that we develop a SIGTRAN Applicability Statement or perhaps one for SCTP and one for Adaptation Protocols. We have a relatively clear idea of what to write for the adaptation protocols and their usage, but SCTP has other dependencies which may take a bit longer to resolve. It was strongly requested that people address the creation of a MIB for signaling transport. Loede Coene (Lode.Coene@SIEMENS.ATEA.BE) has organized a small group to put together an Internet Draft on network architecture for signaling transport, intended to be proposed as an informational RFC. This may be a vehicle to address some of the registration and address mapping issues that were identified. It was agreed that any email discussions on this Internet Draft should be targeted towards the ss7-internet@standards.nortelnetworks.com list since they are out of scope for SIGTRAN.