Internet DRAFT - draft-foster-mgcp-ownership
draft-foster-mgcp-ownership
Internet Engineering Task Force B. Foster
Internet Draft Cisco Systems
Document: <draft-foster-mgcp-ownership-00.txt>
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]
