Internet Engineering Task Force B. Foster Internet Draft Cisco Systems Document: Category: Informational January 2005 Media Gateway Control Protocol (MGCP) Ownership Packages Status of this Document By submitting this Internet-Draft, each author certifies that any applicable patent or other IPR claims of which the author is aware have been disclosed, or will be disclosed, and any of which each author becomes aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-draft, the authors accept the provisions of Section 3 of RFC 3667 (BCP 78). 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. Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In the Media Gateway Control Protocol Specification [2], there is nothing preventing multiple Call Agents talking to the same endpoint. However, this can present a problem if they are both trying to control the endpoint at the same time. The packages defined in this document solve this problem and provide new (and better) mechanisms for endpoint ownership control. 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 [1]. B. Foster Informational [Page 1] MGCP Ownership Packages January 2005 Table of Contents 1. Introduction......................................................2 2.0. Ownership Policy Package.........................................3 2.1. Purpose.........................................................3 2.2. Audit...........................................................3 2.3. Response Codes..................................................4 2.4. Request for Ownership Transfer..................................4 2.5. Procedures......................................................4 3.0. Re-associate Package............................................5 3.1. Purpose.........................................................5 3.2. Preference Parameters...........................................5 3.3. New Restart Method..............................................6 3.4. Procedures......................................................6 4.0 Notified Entity List Package......................................7 4.1. Purpose.........................................................7 4.2. NotifiedEntityList Extension Parameter.........................7 5.0. Usage............................................................9 6.0. IANA Considerations............................................10 7.0. Security Considerations........................................10 8.0. Normative References...........................................11 Author's Address.....................................................11 Intellectual Property Statement......................................11 Full Copyright Statement.............................................11 Acknowledgement......................................................12 1. Introduction This document includes three packages that have to do with endpoint ownership. In the Media Gateway Control Protocol Specification [2], there is nothing preventing multiple Call Agents talking to the same endpoint. However, this can present a problem if they are both trying to control the endpoint at the same time. This problem can be solved by defining an ownership policy (ownership policy package) that allows the endpoint to reject requests that are not from its present owner. In order to facilitate change of ownership when bringing a Call Agent in and out of service, a re-associate package is also introduced. The third package that is introduced is a notified entity list package. This package allows better control over endpoint selection of Call Agents by providing the endpoint with a preferred ordered list of Call Agents to select. Section 2 describes the ownership policy ("OP") package, section 3 describes the re-associate package, and section 4 describes the notified entity list package. Section 5 describes the typical usage (and motivation behind the introduction) of these packages. B. Foster Informational [Page 2] MGCP Ownership Packages January 2005 2.0. Ownership Policy Package Package Name: OP Version: 0 2.1. Purpose In order to avoid the problem of two or more Call Agents thinking that they are in control of an endpoint at a given point in time, an ownership policy package is introduced. Ownership policy is provisioned on the endpoint. If the policy is provisioned as "single owner", the endpoint is able to reject a command from a Call Agent with which it is not presently associated. The package consists of new auditable parameters, a parameter indicating ownership and a package specific response code. Also included is a parameter that allows the Call Agent to request that the policy be overridden. 2.2. Audit Ownership Policy is a configurable parameter that presently allows for two ownership policy values: * No policy. * Single Owner. The ownership policy package introduces two new audit endpoint parameters: * ownership policy (with values "no" or "single") * present owner (IP address of the Call Agent with which the endpoint is presently associated) The Call Agent can request an audit of these values using two new request info parameters "PO" and "OP". So for example a request for ownership policy could include the following request for information parameter line: F: OP/OP Response to ownership policy would include a parameter line with the following syntax: "OP/OP:" 0*WSP "no" | "single" Response to request for present owner would include a parameter line with the following syntax: "OP/PO:" 0*WSP ipaddress where the ipaddress is either an IPV4 or IPV6 IP address in the same format as DomainName in appendix A of [2], e.g., [128.96.41.12] B. Foster Informational [Page 3] MGCP Ownership Packages January 2005 2.3. Response Codes The following package-specific response code is included as part of the ownership policy package: 800 Invalid owner 801 Ownership over-ride condition not met 2.4. Request for Ownership Transfer A new parameter is introduced which allows the Call Agent to over-ride the ownership policy and request that the ownership be transferred to it under certain conditions. The parameter consists of acceptance conditions provided as a list of condition parameters with the following ABNF syntax: "OP/C:" 0*WSP condition (","0*WSP condition) condition = "IDL" | "NOHB" | other where other conditions may be specified in future packages or extensions to this package. An empty parameter value indicates no conditions. The value "IDL" indicates that that the endpoint is idle and has no connections on it. The value "NOHB" indicates that a heartbeat from its present owner is missing. The list of conditions in a single parameter line indicates the ANDing of the conditions in that parameter line, i.e. all conditions in the parameter line MUST be met. Multiple parameter lines may be included. The overall condition that MUST be made is determined by ORing the resulting conditions from each parameter line. Example: the request includes two parameter lines. The first parameter line contains conditions "A" AND "B", while the second parameter line contains condition "C". In that case the condition that MUST be met is: ("A" AND "B") OR "C" If a request is made and the conditions specified are not met, the endpoint MUST return response code 801. 2.5. Procedures Ownership policy defines the behavior of an endpoint when it receives a notification, connection or endpoint configuration request. Audit requests may come from multiple sources. B. Foster Informational [Page 4] MGCP Ownership Packages January 2005 If the ownership policy is defined as "single" and there is no condition parameter or the condition is not met, the endpoint MUST reject notification, connection and endpoint configuration requests from a Call Agent for which it is not associated with response code 800, "incorrect owner". If the ownership policy is "no" (no policy) or there is a condition parameter and the condition is met, the endpoint MUST accept the request. Note that acceptance of requests with condition parameters also indicate transfer of ownership. The endpoint will now be associated with the Call Agent that made the request and a request from the previous owner will be rejected if the ownership policy is "single" and no condition is specified or a specified condition is not met. 3.0. Re-associate Package Package Name: RA Version: 0 3.1. Purpose The purpose of this package is to allow a Call Agent to request an endpoint or endpoints to re-associate with a Call Agent, specifying a temporary preference. 3.2. Preference Parameters The request to re-associate is specified by including a preference parameter in the endpoint configuration ("EPCF") command. The ABNF syntax for the preference parameter line is as follows: "RA/PR:" 0*WSP "NL" | other other = prefvalue ("," 0*WSP prefvalue) prefvalue = ("PL:" 0*WSP preferred |"RL:" 0*WSP renounce) preferred = CAaddress (";" 0* CAaddress) renounce = CAaddress (";" 0* CAaddress) where CAaddress has the same syntax as specified in Appendix A of [2] for NotifiedEntity, consisting of a DomainName and optional port. The DomainName portion can be either a fully qualified domain name or an IPv4 or IPv6 IP address. If "NL" is specified, the endpoint uses the existing notified entity or notified entity list to identify the Call Agent with which to re- associate. If a notified entity list exists, the endpoint tries to re-associate based on the preferred order specified by the list. Note that if either the notified entity or the first item on the notified entity list already resolves to the existing Call Agent, the B. Foster Informational [Page 5] MGCP Ownership Packages January 2005 endpoint(s) will not re-associate to another Call Agent but will remain associated with the existing Call Agent instead. Parameter values for "PL" may contain a single item or a list. If a list is provided, it is in preferred order. On the other hand, if the parameter value is empty, this parameter is ignored. If the endpoint receives a value for "PL", it tries to re-associate with the address of a Call Agent in the list included with this parameter. If it is unable to do so, it will return to try the Call Agents identified in the notified entity or notified entity list. Parameter values supplied with "RL" indicate addresses to exclude when re-associating. Parameter values supplied with "PL" or "RL" have the effect of temporarily modifying the notified entity or notified entity list. The resulting list is only valid until the endpoint either develops a new association with a Call Agent or fails to contact any Call Agent at all based on this temporary list. In the latter case, if the temporary list is exhausted without contacting a Call Agent, the endpoint goes into the disconnected state and reverts to the original notified entity or notified entity list. Note that if there are no parameter values for "RA/PR", then the MG will not re-associate. 3.3. New Restart Method When a request is made to re-associate by sending the endpoint or endpoints parameters as specified in section 2.2, and the decision is made to re-associate with a different Call Agent, the endpoint(s) will try to re-associate by sending a RestartInProgress (RSIP) command using a new restart method "reassociate" (based on the IP addresses within the temporary list). Note that in the case where the request to re-associate is sent to the entire gateway (i.e., "all of" wild-card), the resulting RSIP SHOULD also be sent with the same consolidated wildcard for the endpoints that are being re-associated. Note that the "any of" wildcard convention MUST NOT be used. The "restart delay" also MUST NOT be used. Its value is considered to be zero for this restart method. 3.4. Procedures If a request to re-associate results in the endpoint moving to a different Call Agent, the endpoint will begin re-associating by sending a RestartInProgress command with method "reassociate" based on the preferences specified by the "RA/PR" parameter(s). As an example: * If "NL" is specified, the endpoint will attempt to re-associate based on the existing notified entity or notified entity list. In the case of the of a notified entity list the attempt to re- B. Foster Informational [Page 6] MGCP Ownership Packages January 2005 associate will be based on the preferred order specified by the list. If in the process of doing this, the notified entity or the item on the notified entity list resolves to the address of the Call Agent with which it is presently associated, the endpoint will not do anything. It will simply remain associated with the existing Call Agent. On the other hand, if it resolves to some other Call Agent's IP address, the endpoint MUST send a RestartInProgress command with method "reassociate". If the request is rejected or there is no response after the configured number or retries, the endpoint will continue with the remaining items on the list. * If the "PL" and/or "RL" parameters are specified, the endpoint will create a temporary notified entity list. It will consist of a preferred order consisting of: * The IP addresses or FQDN's specified with the "PL" parameters, followed by * The existing notified entity or notified entity list with values from the "RL" parameters removed. The endpoint MUST then send the RSIP with method "reassociate" in the order specified by this temporary list. If it manages to re-associate (is accepted by a Call Agent on the list), then the re-association request is complete. If it fails to contact any of the Call Agents on the list, it MUST go into a "disconnected" state and behave as described in [2] (or [3] for the NCS profile of MGCP). Note that the recommended use of this package is to temporarily modify an existing notified entity or notified entity list, e.g. the notified entity or notified entity list remains as its provisioned value and is only modified temporarily for the purpose of re- associating. Once a new association is established the list reverts to the previous notified entity or notified entity list value. 4.0 Notified Entity List Package Package Name: NL Version: 0 4.1. Purpose The purpose of this package is to allow the use of a NotifiedEntityList. This is similar to the NotifiedEntity parameter in [2] but allows multiple domain names and/or IP addresses to be provided. This in turn allows endpoints to be more accurately directed to alternate Call Agents in a preferred order. 4.2. NotifiedEntityList Extension Parameter When requested by a Call Agent or when returned as part of an audit endpoint request, 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], e.g.: B. Foster Informational [Page 7] MGCP Ownership Packages January 2005 NL/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net The NotifiedEntityList works in a similar way to the NotifiedEntity parameter, except that it allows multiple domain names and/or IP addresses 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 or IP address 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 and/or IP addresses 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, 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. 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, and hence retransmission to all other IP-addresses MUST end after Max1 retransmissions. Note that each entries in the NotifiedEntityList follow the syntax of DomainName as defined in Appendix A of [2]. Any entry may be either a fully qualified domain name or IP address. The current value of the NotifiedEntityList parameter can be audited via AuditEndpoint; the value of the NotifiedEntity parameter will not B. Foster Informational [Page 8] MGCP Ownership Packages January 2005 be included here and hence must be audited separately. Support for the NotifiedEntityList in AuditConnection is permissible, but it is neither required nor recommended. 5.0. Usage The ownership packages described in this draft can be used in any way allowed by the package definitions described above. This section describes a particular approach. As indicated in the description of the NL package, the notified entity list can be used under any situation that the notified entity could be used in [2] or [3]. One particular approach is to provision the notified entity list and then use the re-associate package to make temporary adjustments as required. With this approach the Call Agent never sends down a new notified entity or notified entity list. Instead, it used the re-associate package to make these temporary adjustments. An endpoint boots up with its notified entity list indicating the preferred order and ownership policy (ownership package) set to "single". After boot-up, it starts sending RSIP with RestartMethod "restart" to Call Agents in the order specified by the list. As soon is it gets a positive response from a Call Agent, it takes that as its present owner and will reject any request from any other Call Agent (based on the ownership policy). If the endpoint is unable to communicate with that Call Agent, it will begin to try other Call Agents based on the order in its notified entity list. Once it finds a new Call Agent, that Call Agent becomes the new owner and requests from other Call Agents will be rejected. The above behavior prevents situations where two Call Agents may erroneously think that they "own" an endpoint at a given point in time. This could occur for example if there was a temporary partition between the endpoint and its Call Agent, the endpoint switched to another Call Agent, then the first Call Agent came back and started trying to control the endpoint based on its mistaken belief that it is still the owner. In order to take a Call Agent out of service, the Call Agent that "owns" the endpoint can use the re-associate package to temporarily remove itself from the notified entity list. In doing so, the Call Agent may suggest specific changes to the list (preferred alternatives). The result is that the endpoint begins to send RSIP's with RestartMethod "reassociate" based on the temporary list. Once it gets a positive response from a new owner, it takes that Call Agent as its present owner and will reject any requests from other Call Agents. Returning a Call Agent to service involves requesting the Call Agents that have taken temporary ownership of endpoints to renounce themselves. One simple way to do that is for the Call Agents to send a re-associate request with the "RA/PR" parameter set to "NL". This results in all endpoints reverting back to the Call Agents specified by their provisioned order (notified entity list). B. Foster Informational [Page 9] MGCP Ownership Packages January 2005 A further situation can occur, where on an incoming call, the Call Agent that is the present owner of the endpoint cannot be contacted. Under this situation, some other Call Agent that can be contacted may try to take over ownership. In order to do that, it has to be able to over-ride the ownership policy based on some condition (for example, only of the endpoint is idle). This mechanism is provided by the "OP/C" parameter in the ownership policy package. If the condition is met, the endpoint accepts the request and the Call Agent making the request becomes the new owner of the endpoint. If the condition is not met, the endpoint will reject the request and the call will fail. The approach described above is just one of many possible ways of using the ownership packages described in this document. Other approaches are also possible. 6.0. IANA Considerations The MGCP packages included in this document should be registered with IANA as indicated in Appendix C.1 in [2] using the following information: Package Name Title Version Number RA Reassociate 0 OP Ownership Policy 0 NL Notified Entity List 0 7.0. Security Considerations Section 5 of the base MGCP specification [2] discusses security requirements for the base protocol, which apply equally to the package defined in this document. Use of a security Protocol such as IPsec (RFC 2401, RFC 2406) that provides per message authentication and integrity services is required in order to ensure that requests and responses are obtained from authenticated sources and that messages have not been modified. Without such services, gateways and Call Agents are open to attacks. For example, without such security services 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 re- directing endpoints to itself so that it now acts as the Call Agent for those endpoints. B. Foster Informational [Page 10] MGCP Ownership Packages January 2005 8.0. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] F. Andreasen, B. Foster "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003 [3] PacketCableTM Network-Based Call Signaling Specification Author's Address Bill Foster Cisco Systems EMail: bfoster@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, 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. B. Foster Informational [Page 11] MGCP Ownership Packages January 2005 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Foster Informational [Page 12]