[From nobody Sun May 1 23:09:42 2016 Message-ID: <C51ED84B6F47D211917A0000F8BCBD11EBDFEF@zcard00g.ca.nortel.com> From: "Taylor, Tom-PT [CAR:5V00-I:EXCH]" <taylor@americasm01.nt.com> To: megaco@BayNetworks.COM Subject: Requirements Part II Date: Tue, 16 Mar 1999 23:38:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" This is a follow-up to my earlier message, indicating the results of discussion of the remaining set of requirements that I had compiled. The editors will ensure that any additional requirements already in the draft are preserved. Moreover, the MSF and TIPHON requirements will be included unless discussion suggests otherwise. The editors want to turn around a new draft by the beginning of April. Your comments are welcomed. Per-Call Requirements (cont'd) 5.6 Accounting a. Support collection of specified accounting information from trusted MGs, at end of call and in mid-call upon polling * start and stop time, by media flow * volume of content carried, by media flow * QOS statistics, by media flow Discussion: this list can be expanded. It was noted that some items are meaningful only for certain transport types. 5.7 Signalling Control It was accepted that we should have requirements under this heading. Details should be discussed on the list. The following items are suggestions. a. Allow the MGC to specify where messages from specific facility-associated signalling channels should be sent b. Allow the MGC to direct on a per-call basis whether channel-associated signalling is to be reported in the form of event reports or as Q.931 signalling messages on the backhaul interface. c. Allow the MGC to control the operation of signalling links from the SCN into the MG. This was actually presented to Sigtran as a proposed Sigtran-provided capability, and that may well be its more sensible home. 6. Resource Control 6.1 Status Management a. Allow the MG to report changes in status of physical entities supporting bearer endpoints, media resources, and facility-associated signalling channels, due to failures, recovery, or administrative action Accepted. b. Allow the MG to report impending resource exhaustion Discussion: does the MGC provide thresholds to guide the generation of these reports, or would it be strictly a matter of MG implementation? Is it possible to get more specific information from the MG on utilization? In any event, there is definitely a requirement that the MG be able to indicate that it was unable to perform a requested action because of resource exhaustion. It may be that this is the only requirement. c. Allow the MGC to block and unblock the use of specified sets of circuit endpoints Discussion: as this relates to ISUP-controlled circuits, it is unnecessary -- the MGC controls their use. It may be meaningful for MF and R2-signalled trunks, where supervisory states are set to make the trunks unavailable at the far end. The list is invited to suggest more requirements in this area. 7. Operational Requirements 7.1 Assurance Of Control General: provide the means to minimize duration of loss of control due to loss of contact or state mismatches a. Support detection and recovery from loss of contact * due to failure/congestion of communication links * due to MG or MGC failure Accepted. Note that failover arrangements are one of the mechanisms which could be used to meet this requirement. b. Support detection and recovery from loss of synchronized view of resource and connection states between MGCs and MGs Accepted. Note that this absorbs the "audit" category of requirements I suggested in an earlier note on the organization of the requirements document. Audits are a mechanism to achieve the stated objective. 7.2 MIB Requirements a. MG MIB should provide information on * mapping between resources and supporting physical entities * statistics on quality of service on the control and signalling backhaul interfaces * statistics required for traffic engineering within the MG * ... b. MGC MIB should provide ... Discussion: MIB requirements should focus solely on the management of the operation of the Media Gateway control protocol itself. Other MIBs cover the topics suggested here, except possibly for the traffic engineering statistics. The point was raised that the MGC should not have to implement a manager function, because of the complications this would pose for security administration. This raises a requirement for the MGC to be able to discover the resources and other necessary information pertaining to a given MG by means of the Media Gateway control protocol. A suggestion was also made that the MG needs to discover certain information about the MGC. The list is invited to comment, both on the proper Media Control MIB requirements and on the requirements for discovery. 8. General Protocol Requirements a. Transaction-oriented, with multiple operations possible per application [issue: semantics] Discussion: this was rephrased to say "Multiple operations can be invoked in one message and treated as a single transaction." b. Extensible Discussion: extensions must be controlled (e.g. by providing clear rules for allocation of new codepoints) c. Flexible in allocation of intelligence between MG and MGC Discussion: this may have validity as a general requirement, but it is preferable to give details specific instances where the flexibility should be offered. d. Scalable from very small to very large MGs Accepted. Can be backed up by numbers as in the current document. e. Scalable from very small to very large MGC span of control Accepted. f. Allows independent upgrade of MG, MGC Discussion: the wording was not satisfactory. The intent is that MGCs and MGs can run different versions of the protocol and interoperate. This extends to the possibility that different MGs controlled by the same MGC are running different protocol versions, or vice versa. 9. Transport Requirements a. Reliable delivery of messages Accepted. b. Sequenced delivery of messages associated with the same transaction or the same source of events Discussion: more precise wording needed. "Transaction" is not the applicable context. The basic requirement is for partial ordering. c. Ability to abort delivery of obsoleted messages Discussion: add "at the sending end if their transmission has not been successfully completed." Example: aborting a command which has been overtaken by events. d. Support of priority messages Accepted. Discussion: should add timing requirements, support of large fanout at the MGC. 10. Security Requirements Provide defense against the following threats: * denial of service attacks * unauthorized use of resources * modification of message content * loss of confidentiality of user service * repudiation of commands Discussion: Scott Bradner noted that we will have to include an extended discussion of security requirements, offering more precision on each threat and giving a complete picture of the defense including non-protocol measures such as configuration. Other discussion added the threat of denial of service attacks at the media flow level. Tom Taylor E-mail: taylor@nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) This is frequently forwarded to my residence. ]