rfc2805.txt

RFC 的详细文档！

   b.   Provide an ability for the MGC to indicate to an MG the resource
        to use for a call (e.g. DS0) exactly, or indicate a set of
        resources (e.g. pick a DS0 on a T1 line or a list of codec
        types) via a "wild card" mechanism from which the MG can select
        a specific resource for a call (e.g. the 16th timeslot, or
        G.723).

   c.   Allow the use of DNS names and IP addresses to identify MGs and
        MGCs. This shall not preclude using other identifiers for MGs or
        MGCs when other non IP transport technologies for the protocol
        are used.

7.  Operational/Management Requirements

7.1.  Assurance of Control/Connectivity

   To provide assurance of control and connectivity, the protocol must
   provide the means to minimize duration of loss of control due to loss
   of contact, or state mismatches.



Greene, et al.               Informational                     [Page 13]

RFC 2805            MG Control Protocol Requirements          April 2000


   The protocol must:

   a.   Support detection and recovery from loss of contact due to
        failure/congestion of communication links or due to MG or MGC
        failure.

        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. (e.g.
        through the use of audits).

   c.   Provide a means for MGC and MG to provide each other with
        booting and reboot indications, and what the MG's configuration
        is.

   d.   Permit more than one backup MGC and provide an orderly way for
        the MG to contact one of its backups.

   e.   Provide for an orderly switchback to the primary MGC after it
        recovers. How MGCs coordinate resources between themselves is
        outside the scope of the protocol.

   f.   Provide a mechanism so that when an MGC fails, connections
        already established can be maintained. The protocol does not
        have to provide a capability to maintain connections in the
        process of being connected, but not actually connected when the
        failure occurs.

   g.   The Protocol must allow the recovery or redistribution of
        traffic without call loss.

7.2.  Error Control

   The protocol must:

   a.   Allow for the MG to report reasons for abnormal failure of lower
        layer connections e.g. TDM circuit failure, ATM VCC failure.

   b.   Allow for the MG to report Usage Parameter Control (UPC) events.

   c.   Provide means to ameliorate potential synchronization or focused
        overload of supervisory/signaling events that can be detrimental
        to either MG or MGC operation. Power restoration or signaling
        transport re-establishment are typical sources of potentially
        detrimental signaling showers from MG to MGC or vice-versa.




Greene, et al.               Informational                     [Page 14]

RFC 2805            MG Control Protocol Requirements          April 2000


   d.   Allow the MG to notify the MGC that a termination was terminated
        and communicate a reason when a terminations is taken out-of-
        service unilaterally by the MG due to abnormal events.

   e.   Allow the MGC to acknowledge that a termination has been taken
        out-of-service.

   f.   Allow the MG to request the MGC to release a termination and
        communicate a reason.

   g.   Allow the MGC to specify, as a result of such a request its
        decision to take termination down, leave it as is or modify it.

7.3.  MIB Requirements

   The Protocol must define a common MG MIB, which must be extensible,
   but must:

   a.   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.   The protocol must allow the MG to provide to the MGC all
        information the MGC needs to provide in its MIB.

   c.   MG MIB must support implementation of H.341 by either the MG,
        MGC, or both acting together.

8.  General Protocol Requirements

   The protocol must:

   a.   Support multiple operations to be invoked in one message and
        treated as a single transaction.

   b.   Be both modular and extensible. Not all implementations may wish
        to support all of the possible extensions for the protocol. This
        will permit lightweight implementations for specialized tasks
        where processing resources are constrained. This could be
        accomplished by defining particular profiles for particular uses
        of the protocol.





Greene, et al.               Informational                     [Page 15]

RFC 2805            MG Control Protocol Requirements          April 2000


   c.   Be flexible in allocation of intelligence between MG and MGC.
        For example, an MGC may want to allow the MG to assign
        particular MG resources in some implementations, while in
        others, the MGC may want to be the one to assign MG resources
        for use.

   d.   Support scalability from very small to very large MGs: The
        protocol must support MGs with capacities ranging from one to
        millions of terminations.

   e.   Support scalability from very small to very large MGC span of
        control: The protocol should support MGCs that control from one
        MG to a few tens of thousands of MGs.

   f.   Support the needs of a residential gateway that supports one to
        a few lines, and the needs of a large PSTN gateway supporting
        tens of thousands of lines. Protocol mechanisms favoring one
        extreme or the other should be minimized in favor of more
        general purpose mechanism applicable to a wide range of MGs.
        Where special purpose mechanisms are proposed to optimize a
        subset of implementations, such mechanisms should be defined as
        optional, and should have minimal impact on the rest of the
        protocol.

   g.   Facilitate MG and MGC version upgrades independently of one
        another. The protocol must include a version identifier in the
        initial message exchange.

   h.   Facilitate the discovery of the protocol capabilities of the one
        entity to the other.

   i.   Specify commands as optional (they can be ignored) or mandatory
        (the command must be rejected), and within a command, to specify
        parameters as optional (they can be ignored) or mandatory (the
        command must be rejected).

8.1.  MG-MGC Association Requirements

   The Protocol must:

   a.   Support the establishment of a control relationship between an
        MGC and an MG.

   b.   Allow multiple MGCs to send control messages to an MG. Thus, the
        protocol must allow control messages from multiple signalling
        addresses to a single MG.





Greene, et al.               Informational                     [Page 16]

RFC 2805            MG Control Protocol Requirements          April 2000


   c.   Provide a method for the MG to tell an MGC that the MG received
        a command for a resource that is under the control of a
        different MGC.

   d.   Support a method for the MG to control the rate of requests it
        receives from the MGC (e.g. windowing techniques, exponential
        back-off).

   e.   Support a method for the MG to tell an MGC that it cannot handle
        any more requests.

8.2.  Performance Requirements

   The protocol must:

   a.   Minimize message exchanges between MG and MGC, for example
        during boot/reboot, and during continuity tests.

   b.   Support Continuity test constraints which are a maximum of 200ms
        cross-MGC IAM (IAM is the name given to an SS7 connection setup
        msg) propagation delay, and a maximum of 200ms from end of
        dialing to IAM emission.

   c.   Make efficient use of the underlying transport mechanism. For
        example, protocol PDU sizes vs. transport MTU sizes needs to be
        considered in designing the protocol.

   d.   Not contain inherent architectural or signaling constraints that
        would prohibit peak calling rates on the order of 140
        calls/second on a moderately loaded network.

   e.   Allow for default/provisioned settings so that commands need
        only contain non-default parameters.

9.  Transport

9.1.  Assumptions made for underlying network

        The protocol must assume that the underlying network:

   a.   May be over large shared networks: proximity assumptions are not
        allowed.

   b.   Does not assure reliable delivery of messages.

   c.   Does not guarantee ordering of messages: Sequenced delivery of
        messages associated with the same source of events is not
        assumed.



Greene, et al.               Informational                     [Page 17]

RFC 2805            MG Control Protocol Requirements          April 2000


   d.   Does not prevent duplicate transmissions.

9.2.  Transport Requirements

   The protocol must:

   a.   Provide the ability to abort delivery of obsolete messages at
        the sending end if their transmission has not been successfully
        completed. For example, aborting a command that has been
        overtaken by events.

   b.   Support priority messages: The protocol shall allow a command
        precedence to allow priority messages to supercede non-priority
        messages.

   c.   Support of large fan-out at the MGC.

   d.   Provide a way for one entity to correlate commands and responses
        with the other entity.

   e.   Provide a reason for any command failure.

   f.   Provide that loss of a packet not stall messages not related to
        the message(s) contained in the packet lost.

   Note that there may be enough protocol reliability requirements here
   to warrant a separate reliable transport layer be written apart from
   the Media Gateway Control Protocol. Also need to compare Megaco
   reliable transport requirements with similar Sigtran requirements.

10.  Security Requirements

   Security mechanisms may be specified as provided in underlying
   transport mechanisms, such as IPSEC.  The protocol, or such
   mechanisms, must:

   a.   Allow for mutual authentication at the start of an MGC-MG
        association

   b.   Allow for preservation of the of control messages once the
        association has been established.

   c.   Allow for optional confidentiality protection of control
        messages.  The mechanism should allow a choice in the algorithm
        to be used.

   d.   Operate across untrusted domains in a secure fashion.




Greene, et al.               Informational                     [Page 18]

RFC 2805            MG Control Protocol Requirements          April 2000


   e.   Support non-repudiation for a customer-located MG talking to a
        network operator's MGC.

   f.   Define mechanisms to mitigate denial of service attacks

   Note: the protocol document will need 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.

   g.   It would be desirable for the protocol to be able to pass
        through commonly-used firewalls.

11.  Requirements specific to particular bearer types

   The bearer types listed in Table 1 can be packaged into different
   types of MGs. Examples are listed in the following sections.  How
   they are packaged is outside the scope of the general Media Gateway
   control protocol. The protocol must support all types of bearer types
   listed in Table 1.