GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3991

Network Working Group B. Foster Request for Comments: 3991 F. Andreasen Category: Informational Cisco Systems

                                                         February 2005
 Media Gateway Control Protocol (MGCP) Redirect and Reset Package

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

IESG Note

 This document is being published for the information of the
 community.  It describes a non-IETF protocol that is currently being
 deployed in a number of products.  Implementers should be aware of
 RFC 3015, which was developed in the IETF Megaco Working Group and
 the ITU-T SG16, and which is considered the standards-based
 (including reviewed security considerations) way to meet the needs
 that MGCP was designed to address by the IETF and the ITU-T.

Abstract

 The base Media Gateway Control Protocol (MGCP) specification (RFC
 3435) allows endpoints to be redirected one endpoint at a time.  This
 document provides extensions in the form of a new MGCP package that
 provides mechanisms for redirecting and resetting a group of
 endpoints.  It also includes the ability to more accurately redirect
 endpoints by allowing a list of Call Agents to be specified in a
 preferred order.

Foster & Andreasen Informational [Page 1] RFC 3991 MGCP Redirect and Reset Package February 2005

Table of Contents

 1.  Introduction..................................................  2
     1.1.  Conventions Used in This Document.......................  3
 2.  Redirect and Reset Package....................................  3
     2.1.  NotifiedEntityList Extension Parameter..................  3
     2.2.  Endpoint Specifier......................................  4
           2.2.1.  EndpointList and EndpointMap Extension
                   Parameters......................................  4
           2.2.2.  Application to Out-of-Service Endpoints.........  6
     2.3.  Redirect................................................  6
     2.4.  Reset Extension Parameter...............................  7
     2.5.  Return Codes............................................  8
 3.  IANA Considerations...........................................  9
 4.  Security Considerations.......................................  9
 5.  Normative References..........................................  9
 Authors' Addresses................................................ 10
 Full Copyright Statement.......................................... 11

1. Introduction

 The base Media Gateway Control Protocol (MGCP) specification [2]
 allows a Call Agent to specify a new NotifiedEntity parameter in
 order to redirect one or more endpoints to a new Call Agent.  This
 must be done in a NotificationRequest or a connection handling
 command.  However, because these commands affect endpoint or
 connection state, such a request cannot typically be sent to a group
 of endpoints with a single command.  This means that if a new Call
 Agent takes over for a failed one, the new Call Agent must redirect
 endpoints one at a time.  If there is a large number of endpoints
 (e.g., within a large trunking gateway), this could take considerable
 time.
 This document defines a new redirect and reset package for MGCP that
 allows the Call Agent to redirect a group of endpoints without
 affecting endpoint or connection state.
 Also included is a new NotifiedEntityList parameter, which is similar
 to the NotifiedEntity parameter but allows for multiple domain names
 to be provided.  This allows the Call Agent to more accurately direct
 endpoints to a preferred ordered list of alternate Call Agents.
 A third capability contained in this package is the ability to reset
 and re-initialize one or more groups of endpoints efficiently.  This
 capability is useful in Call Agent failover situations.

Foster & Andreasen Informational [Page 2] RFC 3991 MGCP Redirect and Reset Package February 2005

1.1. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [1].

2. Redirect and Reset Package

 Package Name: RED
 Version: 0
 This package does the following:
  • Defines a new NotifiedEntityList extension parameter. This

works the same as the NotifiedEntity parameter in [2] but

       allows more than one domain name to be specified.
  • Allows a Call Agent to pass a new NotifiedEntity or

NotifiedEntityList to a collection of endpoints specified by an

       "all of" wildcard.  This is useful if a new Call Agent takes
       over from a previous one and wants to redirect endpoint(s) to
       send messages to it from now on.
  • Allows a Call Agent to request one or more groups of endpoints

to do a reset, which can be useful following certain types of

       failures.

2.1. NotifiedEntityList Extension Parameter

 The NotifiedEntityList parameter is encoded as "NL" and is followed
 by a colon and a comma-separated list of NotifiedEntity values as
 defined in the MGCP specification [2], as follows:
    RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
 The NotifiedEntityList works in a way similar to the NotifiedEntity
 parameter, except that it allows multiple domain names to be listed.
 The NotifiedEntityList thus specifies a new "notified entity" for the
 endpoint.
 The NotifiedEntityList parameter is optional in any command or
 response where the NotifiedEntity parameter is allowed.  Following a
 restart, the NotifiedEntityList is initially empty, unless
 provisioned otherwise.  In subsequent commands, it retains its
 current value until explicitly changed.  If both a NotifiedEntity
 parameter and a non-empty NotifiedEntityList parameter have been set
 (not necessarily at the same time), the NotifiedEntity parameter
 value will be viewed as being implicitly added to the beginning of

Foster & Andreasen Informational [Page 3] RFC 3991 MGCP Redirect and Reset Package February 2005

 the NotifiedEntityList parameter.  The NotifiedEntity parameter thus
 always defines the first domain name to contact unless it has
 explicitly been set to empty.  In that case, the NotifiedEntityList
 defines the "notified entity".  If the NotifiedEntityList is also
 empty, then the normal MGCP handling of an empty "notified entity"
 applies.  We will refer to the list of domain names that result from
 the above rules as the "notified entity list".
 When the "notified entity list" is non-empty, transmission is first
 attempted with the first domain name in the list, as in the normal
 MGCP retransmission procedures described in [2].  Each of the IP
 addresses for this domain name MUST first be tried as specified in
 [2], and if this is unsuccessful, each of the IP-addresses for the
 second domain name MUST then be attempted, etc., following the normal
 MGCP retransmission procedures, with "N" (the number of
 retransmissions) set to zero for each domain name (see Section 4.3 in
 [2]).  Whenever retransmission to a new domain name is initiated, the
 default retransmission timer value (RTO), etc., SHOULD be used.  The
 estimator (T-DELAY) and measurements (AAD and ADEV) used for the
 transmission to the previous domain name are considered obsolete.
 Note, however, that the maximum transaction lifetime considerations
 apply as usual; therefore, retransmission to any of the IP addresses
 for any of the domain names MUST NOT occur more than T-Max seconds
 after the command is initially sent, irrespective of where it was
 sent.  The Max1 DNS query MAY be performed for each of the domain
 names, or it MAY simply be performed for the first domain name.  The
 Max2 DNS query however MUST NOT be performed for any but the last
 domain name.  Also note that only the last IP-address for the last
 domain name can reach Max2 retransmissions; therefore, retransmission
 to all IP addresses other than the last IP address of the last domain
 name in the list MUST end after Max1 retransmissions.
 The current value of the NotifiedEntityList parameter can be audited
 via AuditEndpoint; the value of the NotifiedEntity parameter will not
 be included here and must be audited separately.  Support for the
 NotifiedEntityList in AuditConnection is permissible, but it is
 neither required nor recommended.

2.2. Endpoint Specifier

2.2.1. EndpointList and EndpointMap Extension Parameters

 A simple "all-of" wildcard, as defined in [2], may not be sufficient
 to accurately specify endpoints of interest.  An example of this is a
 case where a Call Agent fails over, resulting in a state mismatch for
 endpoints involved with transient calls.  To re-synchronize, the Call
 Agent can use the reset extension parameter described in section 2.4
 of this document, to ensure that idle endpoints are in fact idle.

Foster & Andreasen Informational [Page 4] RFC 3991 MGCP Redirect and Reset Package February 2005

 However, these endpoints may be randomly distributed across the
 available endpoints in a large trunk gateway.
 To satisfy this requirement, the RED package introduces some new
 parameters that may be used to specify the endpoints of interest for
 the EndpointConfiguration Command.  These are the EndpointList and
 the EndpointMap extension parameters.  These parameters MUST only be
 used when a virtual endpoint corresponding to the gateway is
 specified as the LocalEndpointName, such as:
    EPCF 1200 MG@gw1.whatever.net MGCP 1.0
 where "MG" is the virtual endpoint name associated with the gateway.
 The EndPointList parameters is a list of endpoint names that can
 include one or more lines in the following format:
    "RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
 RangedLocalName is a LocalEndpointName that may include the range
 wildcard notation described in Appendix E (section E.5) of [2] as
 well as an "all" wildcard, but the two forms MUST NOT be mixed in a
 single command:
    RangeWildcard  = "*" / "[" NumericalRange *("," NumericalRange)"]"
    NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
 Example:
    RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
 Including an EndpointMap parameter with the following format can
 further specify the endpoints:
    "RED/MP:" 0*WSP TrueOrFalse 0*(TrueOrFalse)
    TrueOrFalse = "T" / "F"
 "T" indicates that the command should be applied to the corresponding
 endpoint, and "F" indicates that it should not.  This parameter can
 be used in conjunction with the reset extension parameter described
 in section 2.4 of this document to force arbitrarily distributed
 endpoints into an idle state.
 If the EndpointMap parameter is used, it MUST be immediately preceded
 (i.e., on the previous line) by an EndPointList parameter to specify
 the endpoints the EndpointMap is referring to (the EndPointList MUST
 NOT contain the "all" wildcard).  Several EndpointList and

Foster & Andreasen Informational [Page 5] RFC 3991 MGCP Redirect and Reset Package February 2005

 EndpointMap parameter lines can be provided.  It is considered an
 error if an EndpointMap parameter extends beyond the endpoints
 specified in the preceding EndPointList parameter.  In that case,
 return code 800 MUST be used (see section 2.5).
 The EndpointList and EndpointMap parameters MUST only be used with
 the EndpointConfiguration command.  The EndpointList parameter MAY be
 provided without an EndpointMap parameter.  However, as indicated
 earlier, an EndpointMap parameter MUST be immediately preceded by an
 EndpointList parameter.  Neither of these parameters is auditable.
 For an example of EndpointMap parameter usage, see Section 2.4.

2.2.2. Application to Out-of-Service Endpoints

 Note that the EndpointConfiguration command is normally only valid
 for in-service endpoints.  If an EndpointConfiguration request is
 sent to a wildcarded LocalEndpointName [2] and any of the endpoints
 specified are out-of-service, the command will fail with return code
 501 (endpoint not ready).
 However, as long as the gateway is in service and able to respond to
 MGCP commands, it can apply the endpoint configuration command to
 endpoints specified by the EndpointList and/or EndpointMap parameters
 (regardless of whether those endpoints are in-service).  Of course,
 the endpoint configuration information will not be maintained over
 gateway restarts (as the Call Agent would have to reapply the
 endpoint configuration after it receives an RSIP with the restart
 method "restart").  For example, if a new "notified entity" was
 provided, it would have no effect since the provisioned value would
 be used upon restart.
 EndpointList and/or EndpointMap parameters MUST only be used with a
 virtual endpoint name corresponding to the gateway (as indicated
 above).  If it is used with any other endpoint name (whether wild-
 carded or not), then error code 801 (section 2.5) MUST be returned.

2.3. Redirect

 A new extension parameter for use with the EndpointConfiguration
 command is defined.  A new NotifiedEntity value can be included with
 a "RED/N" parameter as follows:
    EPCF 1200 *@gw1.whatever.net MGCP 1.0
    RED/N: ca1@ca1234.whatever.net

Foster & Andreasen Informational [Page 6] RFC 3991 MGCP Redirect and Reset Package February 2005

 This changes the "notified entity" for the endpoint(s) to the value
 specified.  If the "all of" wildcard convention is used, the
 NotifiedEntity value replaces all of the existing "notified entities"
 for those endpoints.  If NotifiedEntity is omitted in a subsequent
 EndpointConfiguration command, the "notified entity" remains
 unchanged.
 If the "notified entity" is a domain name that resolves to multiple
 IP addresses, one of the resolved addresses MUST be selected.  If one
 of those IP addresses is the IP address of the Call Agent sending the
 request, that IP address SHOULD be selected first.
 The NotifiedEntityList parameter can also be specified in an endpoint
 configuration command, such as follows:
    EPCF 1200 *@gw1.whatever.net MGCP 1.0
    RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
 Note that this command will only succeed if all the endpoints on the
 gateway are in-service.
 As indicated in section 2.2, it can also apply this to the gateway
 virtual endpoint:
    EPCF 1200 MG@gw1.whatever.net MGCP 1.0
    RED/EL: *
    RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
 Note that the outcome of this command is not affected by the service
 state of the endpoints on the gateway.
 As indicated in section 2.1, the NotifiedEntityList ("RED/NL")
 parameter may be used with any command for which a NotifiedEntity
 parameter is allowed.  However, the "RED/N" parameter SHOULD only be
 used with the endpoint configuration command.
 The "RED/N" parameter does not have a default value, and the auditing
 behavior for auditing the "NotifiedEntity" is unchanged from that
 specified in [2], regardless of how the "NotifiedEntity" was set
 (i.e., there is no specific audit associated with the "RED/N"
 parameter, and therefore the "RED/N" parameter cannot be audited).

2.4. Reset Extension Parameter

 Another EndpointConfiguration parameter ("RED/R") allows the Call
 Agent to reset one or more endpoints.  The ABNF syntax for the
 parameter line is as follows:

Foster & Andreasen Informational [Page 7] RFC 3991 MGCP Redirect and Reset Package February 2005

    "RED/R:" 0*WSP "reset"
 This has the effect of resetting and re-initializing the specified
 endpoints (i.e., any connections on the endpoint will be deleted, and
 the endpoint will be returned to its clean default state without any
 active signals).
 Example:
    EPCF 1200 mg@gw1.whatever.net MGCP 1.0
    RED/EL: ds/e1-3/[1-30]
    RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF
    RED/EL: ds/e1-5/[1-30]
    RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT
    RED/R: reset
 In this case, the particular endpoints specified by "T" by the
 EndpointMap parameter in the E1 spans ds/e1-3 and ds/e1-5 are reset.
 The "RED/R" parameter MUST NOT be used with any command other than
 the endpoint configuration command.  There is no default value for
 the parameter, and therefore it is unaffected when omitted.  There is
 no specific audit behavior associated with this parameter, i.e., it
 cannot be audited.

2.5. Return Codes

 The following package-specific return codes are defined for the "RED"
 package:
    Code   Text                     Explanation
     800    EndpointMap              Either the EndpointMap parameters
            Out of Range             are outside the range specified
                                     by the EndpointList parameter, or
                                     the EndpointList Parameter was
                                     not included when an EndpointMap
                                     parameter was included.
     801    Incorrect Usage          Incorrect usage of parameters,
            Of Parameters            such as EndpointList parameter,
                                     used where the endpoint name was
                                     not the virtual endpoint name
                                     corresponding to the gateway.

Foster & Andreasen Informational [Page 8] RFC 3991 MGCP Redirect and Reset Package February 2005

3. IANA Considerations

 The MGCP package title "Redirect and Reset" with the name "RED" and
 version number 0 has been registered with IANA, as indicated in
 Appendix C.1 in [2].

4. Security Considerations

 Section 5 of the base MGCP specification [2] discusses security
 requirements for the base protocol that apply equally to the package
 defined in this document.  Use of a security protocol that provides
 per message authentication and integrity services, such as IPsec (RFC
 2401 [3], RFC 2406 [4]), is required in order to ensure that requests
 and responses are obtained from authenticated sources and that
 messages have not been modified.  Without these services, gateways
 and Call Agents are open to attacks.
 For example, an attacker could masquerade as a Call Agent and
 initiate a denial of service attack by resetting endpoints that were
 involved in valid calls.  Another attack using the package described
 in this document could involve redirecting endpoints to the attacker
 so that it acts as the Call Agent for those endpoints.

5. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
      (MGCP) Version 1.0", RFC 3435, January 2003.
 [3]  Kent, S. and R. Atkinson, "Security Architecture for the
      Internet Protocol", RFC 2401, November 1998.
 [4]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
      (ESP)", RFC 2406, November 1998.

Foster & Andreasen Informational [Page 9] RFC 3991 MGCP Redirect and Reset Package February 2005

Authors' Addresses

 Flemming Andreasen
 Cisco Systems
 499 Thornall Street, 8th Floor
 Edison, NJ 08837
 EMail: fandreas@cisco.com
 Bill Foster
 Cisco Systems
 EMail: bfoster@cisco.com

Foster & Andreasen Informational [Page 10] RFC 3991 MGCP Redirect and Reset Package February 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and at www.rfc-editor.org, and except as set
 forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the ISOC's procedures with respect to rights in ISOC Documents can
 be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Foster & Andreasen Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3991.txt · Last modified: 2005/02/15 20:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki