NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 28-Nov-00
Lyndon Ong <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <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:
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 IP-based transport protocol draft to IESG for publication as a Standards-track RFC
Submit initial adaptation drafts to IESG for consideration as a Proposed Standard
Submit protocol MIB draft to IESG for consideration as an Proposed Standard
Submit protocol Applicability Statements draft to IESG for consideration as an Informationl RFC
Submit secondary adaptation drafts to IESG for consideration as a Proposed Standard
Request For Comments:
Architectural Framework for Signaling Transport
Stream Control Transmission Protocol
Sigtran Working Group
Thu Dec 14, 2000
Reported by: Lamonte Yarroll
The Sigtran WG met on Dec. 14th, with 164 persons attending. The group first discussed the agenda and progress of the work. The agenda was approved with no comments, while the chair noted that the group is now in view of completion of its objectives within 2-3 meetings.
1. Bakeoff report
The chair gave an overview of the 2nd SCTP bakeoff:
- 23 implementations from 22 participants
- about 50 people total
- hosted by MCNC Oct 23-27 2000, with network support from Nortel
- Bakeoffs are not per se a requirement, but they help for advancing the drafts and debugging the protocol specification.
- Most multi-homed, a few single-homed, 3 kernel implementations
- 11 OS's used for implementation
- interest in all of the adaptation layers
- Generally successful testing except kernel implementations (maturing)
- Not all features tested (e.g. IPv6, Host name addresses)
- New draft has been started on protocol and implementation issues
(<http://ietf.org/internet-drafts/draft-stewart-ong-sctpbakeoff-sigtran-00.txt>), results to be incorporated in the next version of SCTP.
Please see the draft for details. If you find other implementation issues, let Randy and Lyndon know and they'll add to the draft.
- Next Bakeoffs
Connectathon (San Jose) in March - SCTP, limited participation
ETSI Labs (in Nice) in April - SCTP, wider participation
Ericsson (Madrid) in April - M3UA and possibly IUA
- Volunteers requested for SCTP test design team
Michael Tuexen, John Mischo, Javier Kim have volunteered
2. Adaptation Layer Work
2.1 IUA Current Status (Ken)
Ken Morneault reported on the status of IUA and M2UA work:
- IUA now past WG and IESG Last Call
- Last minute comments with minor edits, make notify message mandatory
There was group consensus by hum to add these changes, and to avoid another Last Call round if possible.
2.2 M2UA Current Status (Ken)
- 9 issues still outstanding--informal discussion yesterday brought 1 or 2 solutions for each of these, to appear as proposals on the list.
-- Push to resolve by end of January
-- Updated Doc for review early Feb
-- Goal: Last Call before MN
2.3 M3UA Current Status (Greg Sidebottom)
Greg reported on the status of M3UA work, nearing completion.
- Changes in M3UA 5 (already posted to list)
-- SS7 routing label terminology
-- Layer mgmt corrected/expanded
-- MTP3 Network Indicator not used instead of Netwk Appear
-- SCON message format change
-- All parameters are TLV
-- IANA extensibility text
-- Remove ALI Param
-- Explicit ack timer
- Current issues (some addressed in meeting yesterday)
-- Routing Key parameter in ASP-UP
There are some reservations about simplicity.
-- Notify message will be mandatory
-- Message Priority variation for Japanese nets
Proposal is to define a new data2 parameter
-- SCON from ASP to SG removed by mistake
-- Fix Payload data error
-- Draft 6 ASAP (end of next week if possible...)
There was group consensus by hum to do WG Last Call on Draft 6.
There is a lot of interest in M3UA both from within and without, as other standards bodies such as ITU-T and 3GPP are waiting on M3UA completion.
2.4 SUA (John Loughney)
John gave a report on status of SUA, now in version04:
-- Added back SCON
-- Everything is TLV
-- IANA Extensibilty added
-- Source Dest suggestion
-- Message Routing Scenarios added
-- Editorial concerns
-- Segmenting/Reassembly within SUA (mandatory for SG)
-- Inactivity Test
-- SUA Message Routing Issues
-- Routing Keys for SUA: only SSN and network appearance?
-- Use of NA is incomplete. Could be multihome problem.
-- Clean up appendices. Are these useful? Please get back to John on the list if you think this is useful.
-- Next Draft due out next week
-- Another draft after that for editorial and cleanup
-- Ready for Last Call after that? Possibly in February.
-- Interest in an SUA Bakeoff (April 2001)?
2.5 M2PA(Tom George)
Tom gave a report on status of M2PA, esp. remaining Open Issues:
-- LI octet and Japanese SS7 - New message type seems like the best approach
-- state transitions -- add details
-- link initialization will get a new example
-- processor outage - procedure like MTP2 or fail like ATM?
-- Common header
-- What to check for in proving period?
-- Can Link Init be symmetric?
- Future plans
-- M2PA Applicability Statement, MIB
-- Need port and SCTP Proto IDS
-- Last Call target around March, after MN meeting
There was a proposal for a new work item on a DPNSS adaptation layer
-- first suggestion was to integrate this into V5UA
-- further comments that this may not work due to differences, ffs.
There was a medium hum in favor of V.5UA--some interest, enough to make this a WG item. List will investigate viability of merging the two.
3. SCTP Extensions (Qiaobing Xie and Randy Stewart)
Randy and Qiaobing made proposals to accept three new extensions to SCTP.
3.1 Unreliable Streams draft-xie-usctp-sigtran-01.txt
- Want to combine reliable and unreliable streams in the same associations
E.g. reliable control and unreliable data
- There are about 49 advantages (well 7 anyway)
1. congestion ctl
2. Link level fault tolerance
3. bundling reliable and unreliable
4. Auto mux/demux
5. Service 1: Ordered delivery and loss detection
6. Service 2: Limited reliability capability
7. Service 3: Partial payload checksum capability
- Unreliable Streams parameter in INIT and INIT ACK
- Forward Cumulative TSN Chunk
Concern was expressed that this should not be solely focused on carrying real-time media streams, esp. given that RTP does real-time media. It was noted that this could be used for other types of flows, incl. IP storage.
- partial checksum parameter
Question raised (Jonathan Wood) on the performance cost of partial checksum.
Considered an issue for further implementation experience. It was suggested that "vi over IP" would be a great potential application (David Black) since the unreliable stream method could be used to avoid some hang up cases that now occur.
3.2 Add/Delete IP and Reliable Chunk mechanism
- Do we always return a status positive or negative?
Probably not, negative should suffice
- Order of execution currently not specified
- Does it makes sense to allow a TLV to request "no report".
- Do we need a set primary?
-- If so should it be an option flag in the add?
-- Or should it be its own TLV?
-- If we allow it as an option will add an already existing be allowed to set a primary?
Please flame Randy on the list for any of these issues.
- Should draft be split into 2 - reliable chunk and add/delete IP?
Put feedback on the list.
- Latest draft incorporates comments made on the list
- Should we place a negotiation flag in INIT/INIT-ACK?
-- Pro: fewer messages
-- Con: more INIT header...
3.3 Stream-based flow control
- like the above 2 extensions, a requested extension.
There was a consensus hum for accepting all three as WG items. There was a request to hold finalization until after the London meeting, to allow more time for implementation experience.
4. Applicability Statements (Lode Coene)
Lode presented a report on the current status of the SCTP AS. There was some discussion of heartbeat added, routing interactions and NAT interactions. Generally the document appears in good shape.
Status: No open issues, ready for WG LC after updated draft in first week of January
4.2 Signaling transport over SCTP applicability statement
- After some discussion it was agreed to hold off on Last Call until the SCTP applicability statement is completed. One reason is that we may be able to put more information on the adaptation layers into this AS and avoid having to do a separate AS for each adaptation layer.
- comment - do we need mention of IP telephony signalling over SCTP? No, it was pointed out that there is already work going on in other groups to do this, esp. there is a SIP over SCTP draft that is being incorporated into the SIP main spec, and that this same arrangement can apply to other IP signaling work in IETF and other groups.
5.1 SCTP MIB (J. Javier Pastor)
An assortment of fields have changed. Some of the main issues:
-- should this be a read-only MIB or r/w MIB?
-- When should tables be created and deleted?
-- further issues were moved to informal discussion and the list.
5.2 M3UA MIB (Antonio Roque)
This was presented for the first time. The following points were discussed:
-- M3UA configuration
Protocol fields are RW, but connection specific fields are RO
- Follows a detailed account of the fields in the MIB.
- The MIB allows you to create endpoints via SNMP
- Open issues
-- recomended timer values
-- stream and ASP/SGP Loadsharing
-- issue of whether the MIB can be used to directly create associations through SNMP, this was deferred to informal discussion and the list.
It was agreed by hum to accept this as a WG item.
6. Socket API
Randy presented information on the status and open issues:
-- Examples still not filled in
-- Notification socket is dead!
Notifications will come as errors on the normal socket followed by a flagged readmsg().
-- sctp_bindx() may need to be expanded so we can better support UDP-style socket.
-- Security issues may not be fully complete. [Who do I need to talk to?]
-- Terminology on primary address is confusing
-- sctp_bindx() can ignore port numbers after first bind().
-- Association ID will replace sockaddr where appropriate.
-- Do we COMM_DOWN and COMM_CLOSED notification?
Probably not--new socket mechanism will provide this info.
Jonathon: "shutdown() does nothing..."
-- Why are error TLV's passed up to application?
-- Will trial in Linux kernel.
Jonathon Wood pointed out another open issue: local primary address--source address selection. Randy commented that it is a mess.
The draft is not intended to be a WG item, but a separate effort that will be submitted directly to IESG to become an Informational document. The projected timing is for completion after the London meeting. There will be a developer's release of the Linux kernel implementation for SCTP on Jan. 19th, 2001 that will incorporate the socket API. For further information, contact Lamonte Yarrall (firstname.lastname@example.org).
ITU-T SG9 has solicited comments from IETF Sigtran WG and SG11 on cable-related specifications for signaling transport that they may standardize. There is some dispute between SG11 and SG9 already on this. The chair will post the liaison statement to the list and generate a proposed response and circulate this to the list.
8. Wrap Up
Ian Rytina asked for an update for payload protocol ID registration with IANA. Lyndon responded that IANA has put up a page with SCTP numbers and IANA is in the process of creating a form for requesting new protocol IDs. ITU has already requested additional protocol ID values 7 for H.248 and 8 for BICC.
Adding IP Addresses
IUA and M2UA Status Update
M3UA (MTP3-User Adaptation Layer)
MTP2 Peer-to-Peer Adaptation Layer
SCTP Sockets Draft
SCCP User Adaptation Layer
SCTP Extension: Unreliable Streams