MEGACO 45th IETF Oslo - Thursday, July 14, 1999 Chair: Tom Taylor taylor@nortelnetworks.com Reported by Matt Holdrege holdrege@lucent.com 226 people signed the blue sheet. The agenda (file taylor.pdf, charts 1-3), was accepted. Tom gave the design team report (file taylor.pdf, chart 4 ). There was no time for questions or comments. The design team agreed to split audit into two commands, status discovery and capability discovery. The MGC must support both SDP and SG16-determined encoding of H.245. An MG may support either and this reserves the possibility of migration to a new syntax. There was a political impasse on encoding. Tom decided for text by flipping a coin. The issue is relative value of development speed versus performance. Note that this conclusion was reached at a second meeting which did not include the whole design team. Paul Sijben (sijben@lucent.com) led a discussion on Capabilities requirements (file sijben.pdf), essentially in support of the I-D by Rosen et al. Capabilities must be protocol agnostic and bearer (transport) agnostic. Capabilities must be able to express simultaneous and mutually exclusive capabilities. SDP in its original form is unable to do so, while H.245 is overly complex. Christian Huitema (huitema@research.telcordia.com) pointed out that he had demonstrated how to overcome this perceived deficiency of SDP. Paul explained that the Template concept is like a macro. He proposed that we use flexible tags that can be registered with IANA for all properties. We already use such tags for signals and events and private properties. One of those tags could be an EmbeddedSDP tag. In this way, the native way of encoding descriptors in the protocols is coherent but if you want to implement SDP or H.245 in the MG you can. Brian Rosen - brosen@ENG.FORE.COM led a talk on the protocol syntax, presenting a set of ABNF based on the decision to use text. This syntax included the optional use of Authentication Headers at the application level when IPSEC is unavailable. The Chair pointed out that we had received advice from the Security Area directorate that IPSEC work-arounds like this are undesirable. After Brian Rosen argued that the available real-time operating systems for small MGs do not yet implement IPSEC, Scott Bradner declared himself convinced that we had a legitimate reason to use the application-level AH. The AD said that the WG must think about the security issues. But we shouldn't blindly use IPsec. Matt Holdrege said that this isn't fair to the vendors who did the right thing by supporting IPsec. Christian proposed a compromise. Since gaining IPsec support for larger the OS's is relatively easier, the rough consensus is that MGC's MUST support IPsec, but MG's may choose to support the alternate authentication scheme. Again, SDP and H.245 must be extended to support Frame Relay and other features. We have been fairly careful to provide X- extensions for experimental features. It was questioned when we will see a proposal for H.245 media descriptor and media capability descriptor encoding? Tom said that the upcoming SG16 Berlin meeting would handle that and perhaps would use TLV. There will always be a small standardization lag between what MEGACO does and what SG16 does. It was questioned whether we should use domain names or some other identifier for MGs and MGCs. The suggestion was it could be a string for a FQDN or a decimal address. It was noted that the MSF requirements for sending statistics to the MGC are not included in Brian's proposal and should be. Fernando Cuervo (cuervo@nortelnetworks.com) led a talk on transport for MEGACO. He pointed out that the proposed solutions fell into two classes. TCP, SIGTRAN, and TUDP all assume that transport reliability and congestion avoidance are handled in a separate layer. Application-layer framing (ALF) differs in kind from these other proposals because it requires the application to address these issues. Application level timers and their relation to transport timers were discussed with no resolution although it was noted that we will always need application level timers. Randy Stewart (rstewar1@email.mot.com talked on MDTP. The SIGTRAN design team is working on improving MDTP and reducing the amount of code. TUDP and MDTP are very similar. TUDP has timers to back off during congestion. It was noted that MDTP uses more commands to handle congestion management than TCP. For the fanout issue, it was noted that each proposal (TCP, TUDP or MDTP) should be able to properly handle many thousands of connections. It was noted that TUDP and MDTP should be able to handle diff-serv while TCP already has this feature. One choice for transport must be mandatory as per the AD. The others could be options. Congestion should not be in transport, it should be pushed down into the network. You should be able to tell your transport manager when you can send data. The application gets to choose millisecond by millisecond what to send. There should be much tighter coupling between transport and application. By a series of hum polls, the meeting determined a rough consensus that the MGC must support both TCP and ALF, but the MG may support either or both. The MG determines the choice of transport in any specific association, because it is always the initiator of that association. MDTP and TUDP were not considered in this decision process, because it was framed in terms of explicit transport layer versus ALF and the list had already agreed that TCP had to be one of the alternatives. The next section of the meeting was on packages. The Chair presented an inventory of the packages which have been proposed to Megaco in draft-ietf-megaco-protocol-01.txt, draft-ietf-megaco-R2package-00.txt, and draft-ietf-megaco-ipphone-00.txt (file taylor.pdf, charts 5-6). Mike Kallas (mkallas@nortelnetworks.com) presented a proposal for a package documentation format (file kallas.pdf). We must set up a procedure with IANA to define codepoints. Packages will be one such item that needs to be registered. Packages should be defined as informational RFC's. SG16 will likely take a subset of these RFC's and publish them as annexes of H.248. Mike Kallas and Christian Huitema are tasked with drafting the IANA Considerations section for this purpose. We are looking for volunteers as editors to put together the actual package documents. One of these documents should provide a "starter kit" of commonly used packages, which would be incorporated by reference into the protocol document. Package is described by a document and consists of a set of termination properties, events, and signals and their properties. The MG can be audited to determine what packages it supports and the ranges of values it supports for the properties. Someone questioned whether response codes should be package specific. The final moments of the meeting dealt with the work plan going forward for the requirements and protocol documents (file taylor.pdf, chart 8). We will have last call for the requirements after the SG16 meeting. SG16 must have a complete H.248 spec for ballot done by the beginning of October [actually mid-November]. Corrections can be added up to February 2000. WG Last Call should probably happen as soon as the protocol and basic package documents are considered to be stable -- perhaps in late August. The question to be resolved is whether we have IETF last call after WG last call is complete or after H.248 has been approved. We must also decide which packages are to be included in the "starter kit" document.