[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 3991

Internet Engineering Task Force                             B. Foster
Internet Draft                                           F. Andreasen
Document: <draft-foster-mgcp-redirect-01.txt>           Cisco Systems
Category: Informational                                 November 2002


                    MGCP Redirect and Reset Package

Status of this Document

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as work in progress.

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

Abstract

  The base MGCP specification (RFC XXXX eds note: RFC # to be supplied
  for draft-andreasen-mgcp-rfc2705bis-05.txt) allows endpoints to be
  re-directed one endpoint at a time. This document provides an
  extension 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 re-direct endpoints by allowing a list
  of Call Agents to be specified in a preferred order.

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 RFC-2119.












B. Foster, F. Andreasen      Informational                     [Page 1]

                    MGCP Redirect and Reset Package       November 2002

                           Table of Contents

Table of Contents.....................................................2
1. Introduction.......................................................2
2.0. Redirect and Reset Package.......................................3
 2.1. NotifiedEntityList Extension Parameter..........................3
 2.2. Endpoint Specifier..............................................4
 2.3. Redirect........................................................5
 2.4. Reset...........................................................6
3.0. IANA Considerations..............................................6
4.0. Security Considerations..........................................6
5.0. References.......................................................6
6.0. Authors' Addresses...............................................7
7.0. Full Copyright Statement.........................................8



1. Introduction

  The Base MGCP specification [3] allows a Call Agent to specify a new
  NotifiedEntity parameter (in order to re-direct the endpoint to a new
  Call Agent) in a notification request 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 in a case where a
  Call Agent fails over, it must re-direct endpoints one at a time. If
  there are a large number of endpoints (e.g. within a large trunk
  gateway) this could take a considerable amount of time. This document
  contains a new redirect and reset package for MGCP that allows the
  Call Agent to re-direct a group of endpoints without affecting
  endpoint or connection state.

  Also included is a new NotifiedEntityList parameter, which is similar
  to a Notified Entity but allows for multiple domain names. This
  allows the Call Agent to more accurately direct endpoints to a
  preferred ordered list of alternate Call Agents.

  A third capability contained within this package is the ability to
  reset and re-initialize a group of endpoints.
















B. Foster, F. Andreasen      Informational                     [Page 2]

                    MGCP Redirect and Reset Package       November 2002

2.0. Redirect and Reset Package

  Package Name: RED
  Version: 0

  Package Description: The purpose of this package is to:

     * Introduce a new NotifiedEntityList extension parameter. This
       works the same as the NotifiedEntity parameter but allows more
       than one domain name to be specified.
     * Allow a Call Agent to pass a new NotifiedEntity or
       NotifiedEntityList to a collection of endpoints specified by an
       "all of" wild card. This is useful in the case where a new Call
       Agent takes over from a previous one and wants to re-direct
       endpoint(s) to send "Notifies" etc. to it from now on without
       interfering with current event processing (as compared to the
       alternative, which is to send a NotificationRequest command,
       which would be interfering with current event processing).
     * Allow a Call Agent to request a group of endpoints to do a
       reset.

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 [3], e.g.:

    RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net

  The NotifiedEntityList works 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 implicitly added to the beginning of 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 having 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 normal MGCP
  retransmission. Each of the IP-addresses for this domain name MUST
  first be tried as specified in [3], 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,

B. Foster, F. Andreasen      Informational                     [Page 3]

                    MGCP Redirect and Reset Package       November 2002

  with "N" set to zero for each domain name (see Section 4.3 in [3]).
  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, and hence retransmission to any of the IP-addresses
  for any of the domain names MUST NOT occur more than T-Max seconds
  after the initial sending of the command, irrespective of where it
  was sent to. The Max1 DNS query MAY be performed for each of the
  domain names, or it MAY simply be performed for the first. 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, and hence retransmission to all
  other IP-addresses 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 hence must be audited separately. Support for
  the NotifiedEntityList in AuditConnection is permissible, but it is
  neither required nor recommended.

2.2. Endpoint Specifier

  The RED package introduces some additional parameters that MAY be
  used to further specify the endpoints of interest for the Endpoint
  Configuration Command. These are the EndpointList and the EndpointMap
  Parameter.

  The EndPointList parameters is a list of the endpoint names which can
  include one or more lines in the following format:

     "RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)

  where RangedLocalName is a LocalEndpointName that may include the
  ranged wildcard notation described in Appendix E (section E.5) of
  [3], i.e.:

    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"

  where "T" indicates that the command should be applied to this
  endpoint and "F" indicates that it should not.

B. Foster, F. Andreasen      Informational                     [Page 4]

                    MGCP Redirect and Reset Package       November 2002

  If the EndpointMap parameter is used it MUST be preceded by an
  EndPointList parameter to specify the endpoints that the EndpointMap
  is referring to. Several EndpointList and EndpointMap parameter lines
  MAY be provided. For an example of usage - refer to section 2.4.

  Note that the EndpointConfiguration command is normally only valid
  for in-service endpoints. If an EndpointConfiguration request is sent
  to a wild-carded LocalEndpointName [3] and any of the endpoints
  specified are out of service, the command will fail with return code
  501 (endpoint not ready).

  However, it is possible to specify a virtual endpoint corresponding
  to the gateway as the LocalEndpointName i.e.:

     EPCF 1200 MG@gw1.whatever.net MGCP 1.0

  where MG is the virtual endpoint name associated with the gateway. As
  long as the gateway is in-services and able to respond to MGCP
  commands, the gateway can apply the endpoint configuration command to
  endpoints specified by the EndpointList and/or EndpointMap parameters
  (regardless of whether those endpoints are in-service or not). The
  endpoint configuration information of course will not be maintained
  over gateway re-boots (i.e. the Call Agent would have to re-apply the
  endpoint configuration after it receives an RSIP with restart method
  "restart").

2.3. Redirect

  Redirect uses the EndpointConfiguration command. A new NotifiedEntity
  parameter can be included with a "RED/N" parameter as follows:

     EPCF 1200 *@gw1.whatever.net MGCP 1.0
     RED/N: ca1@ca1234.whatever.net

  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.

  In the case where the "notified entity" is a domain name that
  resolves to multiple IP addresses: if one of the IP addresses is the
  IP address of the Call Agent sending the request, that IP address
  SHOULD be selected first. Otherwise, any one of the addresses MUST be
  selected.

  The NotifiedEntityList parameter can also be specified in a redirect
  endpoint configuration command, e.g.:

     EPCF 1200 *@gw1.whatever.net MGCP 1.0
     RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net



B. Foster, F. Andreasen      Informational                     [Page 5]

                    MGCP Redirect and Reset Package       November 2002

  As indicated in section 2.2, it can also apply this to the gateway
  virtual endpoint e.g.:

     EPCF 1200 MG@gw1.whatever.net MGCP 1.0
     RED/EL: *
     RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net

2.4. Reset

  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:

     "RED/R:" 0*WSP "reset"

  This has the effect of re-setting 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, etc.).

  Example:

     EPCF 1200 *@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.

3.0. IANA Considerations

  The MGCP package title "Redirect and Reset" with the name "RED"
  should be registered with IANA as indicated in Appendix C.1 in [3].

4.0. Security Considerations

  The MGCP packages contained in this document do not require any
  further security considerations beyond those indicated in the base
  MGCP specification[3].

5.0. References

  [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

  [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

  [3] F. Andreasen, B. Foster "Media Gateway Control Protocol (MGCP)
      Version 1.0", RFC XXXX {editors note - to be put in when RFC
      number is assigned to draft-andreasen-mgcp-rfc2705bis-04.txt)

B. Foster, F. Andreasen      Informational                     [Page 6]

                    MGCP Redirect and Reset Package       November 2002


6.0. 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











































B. Foster, F. Andreasen      Informational                     [Page 7]

                    MGCP Redirect and Reset Package       November 2002

7.0. Full Copyright Statement

  Copyright (C) The Internet Society (2002).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS 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.

  Acknowledgement

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























B. Foster, F. Andreasen      Informational                     [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/