NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Lyndon Ong <lyndon_ong@eudoramail.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:sigtran@standards.nortelnetworks.com
To Subscribe: major@standards.nortelnetworks.com
In Body: subscribe sigtran
Archive: http://www.nortelnetworks.com/standards
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.
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. |
Done |
|
Submit IP-based transport protocol draft to IESG for publication as a Standards-track RFC |
Done |
|
Submit initial adaptation drafts to IESG for consideration as a Proposed Standard |
Nov 00 |
|
Submit protocol MIB draft to IESG for consideration as an Proposed Standard |
Done |
|
Submit protocol Applicability Statements draft to IESG for consideration as an Informationl RFC |
Feb 01 |
|
Submit secondary adaptation drafts to IESG for consideration as a Proposed Standard |
· SS7 MTP2-User Adaptation Layer
· SS7 MTP3-User Adaptation Layer (M3UA)
· Stream Control Transmission Protocol Management Information Base using SMIv2
· Stream Control Transmission Protocol Applicability Statement
· SS7 SCCP-User Adaptation Layer (SUA)
· Telephony Signalling Transport over SCTP applicability statement
· SS7 MTP2-User Peer-to-Peer Adaptation Layer
· SS7 MTP3-User Adaptation Layer (M3UA)Management Information Base using SMIv2
· SCTP Unreliable Data Mode Extension
· SCTP Dynamic Addition of IP addresses
· Generic Method for Transmitting Reliable SCTP Control Chunks
RFC |
Status |
Title |
RFC2719 |
Architectural Framework for Signaling Transport | |
RFC2960 |
PS |
Stream Control Transmission Protocol |
RFC3057 |
PS |
ISDN Q.921-User Adaptation Layer |
Signaling Transport WG (sigtran) Meeting Notes
Reported by La Monte H.P. Yarroll <piggy@acm.org>
THURSDAY, March 22 at 1300-1500
================================
CHAIR: Lyndon Ong <lyndon_ong@eudoramail.com>
[The group is headed down the home stretch!]
1. Review of WG Milestones
4 milestones remain to be completed:
1/2 done - Submit initial adaptation drafts to IESG for consideration as Proposed Std. IUA has now reached Proposed Std. status, M3UA is in WG Last Call, M2UA is close to initiation of LC. TBD - Submit SCTP MIB to IESG 1/2 done - SCTP Applicability statements draft to IESG. Now being revised based on comments. TBD - Submit 2ndary adaptation drafts to IESG for consideration as a Proposed Std. These currently include SUA, M2PA, V5UA and DUA.
The WG's aim is to complete milestones and go "dormant". That means mailing list is still active, we run B*k*offs, but no regular face-to-face meetings. The WG also needs to move proposed status specs to Draft via testing.
It was suggested that some adaptation drafts could be finished while the group has already gone dormant. This was accepted as a possibility especially if the adaptation layers remaining are not complex.
2. SCTP Status
SCTP discussion has now been moved to TSVWG. This should be viewed as a sign of success, as SCTP has reached stable state and is considered a potentially important general purpose transport alternative. In particular, work on SCTP extensions will take place in TSVWG rather than in Sigtran.
The MIB and Applicability work WILL continue to be in SIGTRAN. Signalling-specific issues should probably be brought up jointly in SIGTRAN and TSVWG.
3. Adaptation Layers Status
IUA is now Proposed STD.
M3UA is in WG Last call
M2UA and M2PA are to follow RSN
SUA to follow
V5UA to follow
The chair suggested that there was a need to cap UA work at this point. There was a note that DUA should also be included, but that it was a "tertiary" adaptation layer, not a major work item.
There was consensus hum that a sufficient range of UA's has now been covered by the items under work by the WG.
4. Applicability Statement Status
The SCTP AS is moving to Info RFC as soon as comments from the A-Ds are addressed and it moves past IESG review. There is a "signalling" AS still in draft form, which will include further information about the UAs.
5. Interoperability Testing
It was noted that we only need 2 implementations to be documented as interoperating to satisfy the formal requirement in IETF, but that operation of all features needs to be documented.
The question was raised as to whether interoperability is documented as a separate internet draft or just in a report form, the chair volunteered to find out more about the process of documentation.
It was suggested that interoperability issues are resolved, if necessary, by reissue of the RFC when going from Proposed to Draft, but that interoperability documentation itself is by a statement prepared by the WG chair.
The question was raised as to future bakeoffs of SCTP extensions, now that SCTP extensions are being discussed in TSV WG. The chair suggested that the Sigtran mailing list could still be used as a means of coordinating testing, since there is a large pool of interested parties making up the list. Results could be fed back into both groups.
6. Summary of TSV WG SCTP discussion
Randy Stewart gave a brief review of TSV discussion of SCTP extensions. The Reliable Request draft will be withdrawn, so that extensions will utilize new control chunks - this cuts down on the opportunity for feature creep into the protocol. The Unreliable extension was somewhat contentious, but also received support from several quarters, in particular from the ips activity.
Question was raised on when SCTP should be considered stable enough to work on header compression. The RFC is already quite stable, there will be very limited extension.
7. Applicability Statements
Present version of the SCTP AS is 05. Had a WG Last Call which identified an issue from the A-Ds that the document does not explain when to use SCTP. In 2 weeks time there will be a new draft and another WG Last Call. The draft is destined for Informational.
Signalling transport over SCTP AS needs further work. Prefer that UA editors have a look to see if the descriptions contained are accurate and to notify Lode Coene on any issues. New version due out before the London meeting.
8. Status of SCTP MIB v03
Javier Pastor reported on MIB status: updates include removal of association creation, plus some shifting of tables. This should be ready for Last Call after the next version, but may be held up to incorporate changes from the revision of the TCP MIB, so that the two are aligned.
9. M3UA Status and Issues
Greg Sidebottom reported on remaining issues with M3UA, which is now in WG Last Call (closing Friday March 30). There were a number of small issues, but generally nothing critical. The main addition to the last version was an improved set of Registration/Deregistration procedures.
A remaining clarification is to update the definition of Network Appearance with SUA terminology. If there is consensus approval the next draft will be recommended to the A-Ds for review.
Greg also provided status and update on the V5UA, for Dr. Eva Weilandt. This is now specified in the form of a standalone UA and not an extension to IUA, although the final format is flexible. It will involve a separate protocol payload ID.
10. SUA Status and Issues
John Loughney reported on status of SUA, which is in version 5. Some further clarification is needed, and further alignment with M3UA. Discussion needed on the timeframe for completion. It was noted by Ian Rytina that ITU-T SG11 Question 13 is looking at specifying a "transport-independent" SCCP, a new item which will probably be completed sometime in mid-2002.
11. M2PA Status and Issues
Tom George reported on status of M2PA, where changes included inclusion of a format for supporting Japanese SS7, examples of link alignment, and other minor changes. An open issue was noted on the impact of SCTP slow start on changeover, where a burst of messages resulting from changeover might be delayed due to slow start. Analysis is needed to determine if SCTP parameters can be set to minimize the problem. (Note: this has been pointed out as an issue in the past as well.)
Tom also identified a need for a proving mechanism, consisting of sending Link Status Provisioning to measure SRTT over some provisionable length of time.
He also suggested that it may be possible to have M2PA running in a node without MTP3 above it, e.g., in an SS7 - to - IP link converter. This raised questions about whether this overlaps in functionality with M2UA needing further comment.
M2PA is expected to be ready for WG Last Call after the next version. Tom noted that Alcatel was interested in hosting interop testing in Plano, TX in June and asked other interested parties to contact him.
12. M2UA Status and Issues
Ken Mourneault reported on M2UA status. Version 7 was released in February with editorial corrections and clarifications. There is an open issue on whether M2UA would receive notification of IP congestion from SCTP and the corresponding action. It was pointed out by Lamonte Yarroll that the socket API does not provide such notification.
The group will push to resolve open issues by the end of April, and do WG Last Call prior to the next meeting.
Ken also noted that an IUA test specification has been posted as a draft for comment. It was noted that test specs are not an official work item of the group, but may be published as informational documents if the authors choose to pursue this. There was interest from about 5 parties in doing an IUA bakeoff, potentially in coordination with the Megaco bakeoff in August at UNH.
Jan Bouwen discussed drafts on Megaco/Sigtran Interactions, and an ISDN L1 Activation UA. The first draft has been presented in Megaco, but did not fit into that group's charter. The document discusses synchronization of actions in Megaco and control of SCTP association. Since this is also not on the Sigtran charter, it was suggested that this be progressed as an individual submission, but that discussion could use the Sigtran mailing list to get comment and further support.
The second draft proposed a mechanism for transporting L1 activation messaging for an ISDN access. It was suggested that this was not a new UA but an extension to IUA instead, and that a new UA would not fit into the group charter but an extension to IUA very well might. Further discussion was left to the list.
13. SCTP Interoperability Test
Michael Tuexen reported on the next SCTP interoperability test, scheduled for April 23-27 and hosted by ETSI testing center in Sofia Antipolis, France. Contact url is http://www.etsi.org/bakeoff/2UpcomingBackoffs/2001
SCTP/SCTP_generalinfo.htm and contact persons are:
Nathalie.Guinet@etsi.fr
Michael Tuexen (for technical issues)
Registration ends at end of March
Services:
- Internet access (wireless)
- Testbed (same as first bakeoff)
- IPv4, IPv6, DNS
- Test scenarios
Test the Address parameter stuff in INIT, INIT-ACK
Test IPv6
Test flow control using limited bandwidth (10KB range)
"Anything goes!"
Please contact MT for suggestions about other tests...
14. M3UA Interoperability Test
Maria-Carmen Belinchon provided information on the M3UA test scheduled for May 7-11 and hosted by Ericsson, Madrid. Current setup:
-Up to 40 people and power connections
-SGP/ASP function to be tested, participants could act Alternatively as SGP or ASP
- No real MTP-L3 users
- No real MTP SS7 network
- SCTP RFC compliant (mandatory functionality)
Url for more information:
http://standards.ericsson.net/m3ua-interop
Test scope (available on web page)
- Scenario 1: No redundancy
- Scenario 2: Redundancy
2 ASPs serving same AS
1 ASP serving 2 ASs
2 ASPs in different ASs
Open issues included whether v5 or v6 of M3UA would be used as the baseline. Greg Sidebottom pointed out that based on these scenarios, there would be little difference. Greg and Maria were to discuss offline whether v5 or v6 was appropriate and what the differences would actually be.
Note: Please contact Lyndon if you are interested in other UA Bakeoffs.
FTP slide locations:
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/as.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/m2pa.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/M2UA.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/M3UA.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/M3UAbake.ppt
ftp://standards.nortelnetworks.com/sigtran/presentations/minn01/Megaco_Sigtr
an.ppt
SCTP Applicability Statement
MTP2 Peer-to-Peer Adaptation Layer (M2PA)
M2UA Status Update
M3UA (MTP3-User Adaptation Layer)
M3UA interoperability test
Megaco/Sigtran & ISDN