NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Feb-99
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 Request For Comments
Sigtran Working Group
Reported by Tom Taylor.
The Sigtran Working Group met on Tuesday afternoon, March 16.
There were 200 attendees.
Lyndon Ong, Chair, opened the meeting by reminding attendees of the terms of the group's charter and schedule. The proposed agenda was approved.
2. Architecture and Functional Requirements (draft-ietf-sigtran-framework-arch-00.txt)
Lyndon Ong led discussion on this document. The contents of this document were agreed to be stable. The group intends to bring it to WG last call in accordance with the original schedule of April 1999. The current draft contains four sections:
- architectural model
- protocol architecture
- functional requirements.
Work was still needed on sections for management and security. An editing session to review the document and flesh out those sections was set for the next day (March 17).
The presentation concluded by reviewing the functional requirements as are presented in the current draft. No comments were offered by the meeting.
3. Sigtran Performance Requirements
The group currently has two drafts on performance requirements:
- draft-seth-sigtran-sigtran-req-00.txt (considered in December)
Paul Lin presented the latter to the meeting, working from a chart based on Figure 2 of the draft with time values filled in. His chart showed a breakdown of a 350 ms TCAP response time. Within this, 150 ms is available for message transfer. As against this, a single round trip is in the order of 100 ms. If the initial try succeeds, the transfer is within budget; otherwise it is not.
Discussion turned to how much delay Diffserv processing would add. Scott Bradner intervened at this point to suggest that it was far too early to worry about Diffserv delays: we don't know yet what Diffserv will do for us.
Paul was asked whether the 350 ms total budget was for an average response time or some percentile (e.g. 95% of responses are now received within 350 ms of query transmission). The point is that if this is an average and the average probability of retransmission is low enough, then the average (i.e expected value) of message transfer time will be within budget.
The discussion of the TCAP presentation concluded with a suggestion that transfer time budgets may have more significance for network engineering than for protocol design.
Discussion now turned to call setup performance. It was suggested that Sigtran should aim to support performance as good as users of the PSTN are used to. In particular, they are now accustomed to a post-dialing delay of less than a second. The proposed objective for Sigtran is therefore: Probability(IP portion of call setup > 1 s) = 0.05
Based on typical call flows involving a single tandem IP connection between two decomposed gateways (see charts), a series of 10 messages must be passed to complete call setup. This includes MGC-MG messaging. Assuming that 50% of the 1 second budget is allocated to processing, this leaves a transport budget of 500 ms/10 messages = 50 ms per message (one-way transfer).
Initial discussion included the reminder that transmission delays are distance-sensitive and a suggestion that processing should get more than 50% of the budget, based on current experience with TCAP. There was a suggestion that the call flows on which this presentation was based were faulty, in that the SDP loop should be completed before sending the IAM on to the terminating PSTN. It was noted that message transfer times must be less than typical ISUP messaging timeouts in PSTN switches or signalling will fail. These timeouts are typically in the order of 20 s for receipt of an Address Complete Message (ACM), meaning that the satisfaction of subscriber expectations is a far more stringent requirement.
The question raised at this point was what to do with the numbers that had come out of the discussion. What are the hard requirements on message transfer times? Some more numbers were offered at this point: Bellcore (Telcordia) measurements of post dialling delay give typical figures of around 5 s for a local call, 8 s for an international call.
One possible use of all of these numbers might be to decide whether there is sufficient time to do the three-way handshake required to set up a TCP connection. Scott Bradner commented that this is unlikely to be the show-stopper for TCP. The real problem is the number of sessions which must be supported simultaneously.
The discussion concluded with a note that Paul's draft provides other figures of merit besides end-to-end delay. Subsequent discussion in the editing session led to some of the key requirements on message loss and sequence error being added to the functional requirements document, and an agreement to clearly identify the "hard" and "soft" delay requirements.
4. Protocol Framework
Ian Rytina presented the charts in this section. He began by providing a rationale for a generic protocol framework:
- there are lots of SCN protocols
- their requirements are different.
His proposed approach is to provide common basic services on the one hand, then group protocols in "service levels" according to the additional services they require. The Working Group's first task is thus to define the service levels and allocate protocols to them. Detailed work should start with the protocols most in demand.
In discussion it was noted that the term "service level" may be confusing. In a totally unrelated point, it was noted that QSIG might be transported on its own or might be contained within an ISUP message. The meeting agreed that in the latter case the Sigtran transport need not be aware of the encapsulated protocol.
Lyndon asked if the Working Group has problems with using a modular framework. There was general support for the modular concept, but numerous unresolved issues on the details. The resulting discussion raised several questions.
Question: does modularity imply successive protocol layers, with the overhead they might add?
Response: the Working Group is open to suggestions for increased efficiency.
Question: will Sigtran recognize national variants?
Question: how many layers will be developed?
Response: the Working Group will decide as we go.
Closing remark: how will the group co-class protocols? What criteria will be used? The group needs to develop guidelines.
4.2 Session Manager, Backhaul Application (draft-ietf-sigtran-session-mgr-00.txt,
David Auerbach presented the charts. He and his colleagues viewed the problem as divided into three layers, for which the two drafts named above plus draft-ietf-sigtran-reliable-udp-00.txt provide proposed solutions. The basic model on which the proposals are based assumes that time-sensitive and invariant aspects of the Sigtran protocol are implemented on the SG. Signalling protocol-variant portions of the Sigtran protocol are implemented on the MGC. His presentation in general provided a summary of the rationale and design approach on which the three proposals are based.
There was one question on management. The protocol should allow the MGC to manage signalling links on the MG or SG as the case may be.
Ken Morneault presented the slides dealing specifically with the Session Manager proposal. Lyndon commented that this might be an example of a module within the Sigtran framework. Discussion ensued regarding whether the work proposed in the Session Manager document was really an area for standardization. The meeting did not come to a conclusion on this issue.
4.3 MIME Type/Format Issues (draft-ietf-sigtran-mime-isup-00.txt)
Christian Huitema led the discussion. He explained that to register a MIME type, one had to provide pointers to format specifications for that type. To specify ISUP, one needs additional parameters, which he had defined in his proposal.
Scott Bradner explained that the registration of a new MIME type is being used as a procedural shortcut, obviating the need to publish a new RFC.
Gur Kimchi noted that one could also use registered object identifiers (OIDs) as an alternative to MIME types.
Christian was asked if the MIME type were intended as a per-message identifier. In Christian's view, the answer was "no". Rather, it would be used as part of a management operation setting up a "signalling channel".
Chip Sharp suggested that vendor and version parameters might also be needed. Q.931 provided an example of such a requirement. Jonathan Rosenburg questioned the need for a vendor parameter, since it is normally part of the IANA registration process. In the present case, however, it may be a functional requirement.
Christian will recycle the draft to add the new parameters.
5. Reliable Transport
Lyndon introduced this part of the meeting by expressing the intent that a design team made up of the proponents of the various reliable protocol proposals would sort through them and narrow the set of choices to be made by the Working Group. Volunteers for the design team were taken and it was agreed to begin meeting via conference call in the following week.
5.1 H.323 Annex E
Gur Kimchi presented this protocol. H.323 Annex E can be obtained at ftp://standard.pictel.com/avc-site/9905_San/H.323-annex-e-white.zip.
H.323 Annex E describes a transport mechanism which is independent of H.323, but was designed to carry H.323 call signalling on top of UDP. The header is binary but is not ASN.1-encoded. Gur enumerated the features of the protocol and described the header. Annex E is currently going through balloting and is due to be decided (made a standard) at the next ITU-T Study Group 16 meeting in May. Our understanding is that it is no longer open to modifications.
5.2 MDTP (draft-ietf-sigtran-mdtp-01.txt)
Qiaobing Xie presented the slides for the MDTP presentation. The key feature of this protocol is its ability to provide rapid recovery from network failures. It is based on the use of alternative hot stand-by links to which traffic may be moved in the event of failure. The protocol achieves its advantages by insulating the upper layers from link management.
5.3 RUDP (draft-ietf-sigtran-reliable-udp-00.txt)
Ken Morneault presented the slides for the RUDP presentation. RUDP meets most of the Sigtran requirements. It lacks a congestion avoidance mechanism. The presentation included a list of suggested improvements.
Christian Huitema stated that the purpose of congestion avoidance is not to protect the network: the network can protect itself. Instead, congestion avoidance allows the application to adapt to the network's current capacity. If it does so, it gets to choose which packets get through. If it fails to do so, the network chooses which packets get through. For a different view of congestion avoidance, see below.
5.4 PURDET (draft-toney-purdet-00.txt)
Ken Toney presented a list of the advantages of PURDET, emphasizing its light weight and ease of implementation. He also showed the message flows associated with its use. PURDET satisfies many of the functional requirements for Sigtran, including multiplexing of signaling streams.
Scott Bradner commented that congestion avoidance is a requirement for any protocol to come out of Sigtran. He also urged presenters and their colleagues to attend the SLUMS BOF.
5.5 SSCOP (draft-sidebottom-sigtran-ips7-rtsp-00.txt)
Greg Sidebottom presented an analysis of the possible use of SSCOP to carry signalling over IP. He reviewed the features of that protocol and described the work that would be required to adapt it to IP operation. SSCOP would provide some commonality of transport of signaling in ATM and IP.
This section of the meeting concluded with the comment that TCP is the benchmark against which any other proposals should be measured.