idnits 2.17.1 draft-foster-mgcp-redirect-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2003) is 7589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Foster 2 Internet Draft F. Andreasen 3 Document: Cisco Systems 4 Category: Informational July 2003 6 Media Gateway Control Protocol (MGCP) Redirect and Reset Package 8 Status of this Document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The base Media Gateway Control Protocol (MGCP) specification (RFC 32 3435) allows endpoints to be re-directed one endpoint at a time. 33 This document provides extensions in the form of a new MGCP package 34 that provides mechanisms for redirecting and resetting a group of 35 endpoints. It also includes the ability to more accurately re-direct 36 endpoints by allowing a list of Call Agents to be specified in a 37 preferred order. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [1]. 45 Table of Contents 47 1. Introduction......................................................2 48 2.0. Redirect and Reset Package......................................3 49 2.1. NotifiedEntityList Extension Parameter.........................3 50 2.2. Endpoint Specifier.............................................4 51 2.2.1. EndpointList and EndpointMap Extension Parameters..........4 52 2.2.2. Application to Out-of-Service Endpoints....................5 53 2.3. Redirect.......................................................6 54 2.4. Reset Extension Parameter......................................7 55 2.5. Return Codes...................................................7 56 3.0. IANA Considerations.............................................8 57 4.0. Security Considerations.........................................8 58 5.0. Normative References............................................8 59 Authors' Addresses....................................................8 60 Intellectual Property Statement.......................................8 61 Full Copyright Statement..............................................9 62 Acknowledgement.......................................................9 64 1. Introduction 66 The base Media Gateway Control Protocol (MGCP) specification [2] 67 allows a Call Agent to specify a new NotifiedEntity parameter in 68 order to re-direct one or more endpoints to a new Call Agent. This 69 must be done in a NotificationRequest or a connection handling 70 command. However, because these commands affect endpoint or 71 connection state, such a request cannot typically be sent to a group 72 of endpoints with a single command. This means that in a case where 73 a new Call Agent takes over for a failed one, the new Call Agent must 74 re-direct endpoints one at a time. If there is a large number of 75 endpoints (e.g., within a large trunking gateway) this could take a 76 considerable amount of time. 78 This document defines a new redirect and reset package for MGCP that 79 allows the Call Agent to re-direct a group of endpoints without 80 affecting endpoint or connection state. 82 Also included is a new NotifiedEntityList parameter, which is similar 83 to the NotifiedEntity parameter but allows for multiple domain names 84 to be provided. This allows the Call Agent to more accurately direct 85 endpoints to a preferred ordered list of alternate Call Agents. 87 A third capability contained within this package is the ability to 88 efficiently reset and re-initialize one or more groups of endpoints. 89 Such a capability is useful during Call Agent failover situations. 91 2.0. Redirect and Reset Package 93 Package Name: RED 94 Version: 0 96 The purpose of this package is to: 98 * Define a new NotifiedEntityList extension parameter. This works 99 the same as the NotifiedEntity parameter in [2] but allows more 100 than one domain name to be specified. 101 * Allow a Call Agent to pass a new NotifiedEntity or 102 NotifiedEntityList to a collection of endpoints specified by an 103 "all of" wildcard. This is useful in the case where a new Call 104 Agent takes over from a previous one and wants to re-direct 105 endpoint(s) to send "Notifies" etc. to it from now on. 106 * Allow a Call Agent to request one or more groups of endpoints to 107 do a reset, which can be useful following certain types of 108 failures. 110 2.1. NotifiedEntityList Extension Parameter 112 The NotifiedEntityList parameter is encoded as "NL" and is followed 113 by a colon and a comma-separated list of NotifiedEntity values as 114 defined in the MGCP specification [2], e.g.: 116 RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net 118 The NotifiedEntityList works in a similar way to the NotifiedEntity 119 parameter, except that it allows multiple domain names to be listed. 120 The NotifiedEntityList thus specifies a new "notified entity" for the 121 endpoint. 123 The NotifiedEntityList parameter is optional in any command or 124 response where the NotifiedEntity parameter is allowed. Following a 125 restart, the NotifiedEntityList is initially empty, unless 126 provisioned otherwise. In subsequent commands, it retains its 127 current value until explicitly changed. If both a NotifiedEntity 128 parameter and a non-empty NotifiedEntityList parameter have been set 129 (not necessarily at the same time), the NotifiedEntity parameter 130 value will be viewed as implicitly added to the beginning of the 131 NotifiedEntityList parameter. The NotifiedEntity parameter thus 132 always defines the first domain name to contact, unless it has 133 explicitly been set to empty. In that case, the NotifiedEntityList 134 defines the "notified entity". If the NotifiedEntityList is also 135 empty, then the normal MGCP handling of having an empty "notified 136 entity" applies. We will refer to the list of domain names that 137 result from the above rules as the "notified entity list". 139 When the "notified entity list" is non-empty, transmission is first 140 attempted with the first domain name in the list as in the normal 141 MGCP retransmission procedures described in [2]. Each of the IP- 142 addresses for this domain name MUST first be tried as specified in 143 [2], and if this is unsuccessful, each of the IP-addresses for the 144 second domain name MUST then be attempted, etc. following the normal 145 MGCP retransmission procedures, with "N" (the number of 146 retransmissions) set to zero for each domain name (see Section 4.3 in 147 [2]). Whenever retransmission to a new domain name is initiated, the 148 default retransmission timer value (RTO) etc. SHOULD be used - the 149 estimator (T-DELAY) and measurements (AAD and ADEV) used for the 150 transmission to the previous domain name are considered obsolete. 151 Note however, that the maximum transaction lifetime considerations 152 apply as usual, and hence retransmission to any of the IP-addresses 153 for any of the domain names MUST NOT occur more than T-Max seconds 154 after the initial sending of the command, irrespective of where it 155 was sent. The Max1 DNS query MAY be performed for each of the domain 156 names, or it MAY simply be performed for the first domain name. The 157 Max2 DNS query however MUST NOT be performed for any but the last 158 domain name. Also note, that only the last IP-address for the last 159 domain name can reach Max2 retransmissions, and hence retransmission 160 to all other IP-addresses MUST end after Max1 retransmissions. 162 The current value of the NotifiedEntityList parameter can be audited 163 via AuditEndpoint; the value of the NotifiedEntity parameter will not 164 be included here and hence must be audited separately. Support for 165 the NotifiedEntityList in AuditConnection is permissible, but it is 166 neither required nor recommended. 168 2.2. Endpoint Specifier 170 2.2.1. EndpointList and EndpointMap Extension Parameters 172 A simple "all-of" wildcard as defined in [2] may not be sufficient to 173 accurately specify endpoints of interest. An example of this is a 174 case where a Call Agent fails over, resulting in a state mismatch for 175 endpoints involved with transient calls. In order to re-synchronize, 176 one Call Agent procedure involves using the reset extension parameter 177 described in section 2.4 of this document to ensure that idle 178 endpoints are in fact idle. However, these endpoints may be randomly 179 distributed across the available endpoints in a large trunk gateway. 181 In order to satisfy this requirement, the RED package introduces some 182 new parameters that MAY be used to specify the endpoints of interest 183 for the EndpointConfiguration Command. These are the EndpointList 184 and the EndpointMap extension parameters. These parameters MUST only 185 be used when specifying a virtual endpoint corresponding to the 186 gateway as the LocalEndpointName i.e.: 188 EPCF 1200 MG@gw1.whatever.net MGCP 1.0 190 where "MG" is the virtual endpoint name associated with the gateway. 192 The EndPointList parameters is a list of the endpoint names which can 193 include one or more lines in the following format: 195 "RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName) 197 where RangedLocalName is a LocalEndpointName that may include the 198 ranged wildcard notation described in Appendix E (section E.5) of 199 [2], i.e.: 201 RangeWildcard = "*" / "[" NumericalRange *("," NumericalRange)"]" 202 NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ] 204 Example: 206 RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24] 208 Including an EndpointMap parameter with the following format can 209 further specify the endpoints: 211 "RED/MP:" 0*WSP TrueOrFalse 0*(TrueOrFalse) 213 TrueOrFalse = "T" / "F" 215 where "T" indicates that the command should be applied to this 216 endpoint and "F" indicates that it should not. This parameter can be 217 used in conjunction with the reset extension parameter described in 218 section 2.4 of this document to force arbitrarily distributed 219 endpoints to an idle state. 221 If the EndpointMap parameter is used it MUST be immediately preceded 222 (i.e. on the previous line) by an EndPointList parameter to specify 223 the endpoints that the EndpointMap is referring to. Several 224 EndpointList and EndpointMap parameter lines MAY be provided. It is 225 considered to be an error if the EndpointMap parameters extend beyond 226 the endpoints specified in the preceding EndPointList parameter. In 227 that case, return code 800 MUST be used (see section 2.5). 229 The EndpointList and EndpointMap parameters MUST only be used with 230 the EndpointConfiguration command. The EndpointList parameter MAY be 231 provided without an EndpointMap parameter. However, as indicated 232 earlier, an EndpointMap parameter MUST be immediately preceded by an 233 EndpointList parameter. Neither of these parameters is auditable. 235 For an example of EndpointMap parameter usage, refer to section 2.4. 237 2.2.2. Application to Out-of-Service Endpoints 239 Note that the EndpointConfiguration command is normally only valid 240 for in-service endpoints. If an EndpointConfiguration request is 241 sent to a wild-carded LocalEndpointName [2] and any of the endpoints 242 specified are out-of-service, the command will fail with return code 243 501 (endpoint not ready). 245 However, as long as the gateway is in-service and able to respond to 246 MGCP commands, the gateway can apply the endpoint configuration 247 command to endpoints specified by the EndpointList and/or EndpointMap 248 parameters (regardless of whether those endpoints are in-service or 249 not). The endpoint configuration information of course will not be 250 maintained over gateway restarts (i.e. the Call Agent would have to 251 re-apply the endpoint configuration after it receives an RSIP with 252 restart method "restart"). 254 EndpointList and/or EndpointMap parameters MUST only be used with a 255 virtual endpoint name corresponding to the gateway (as indicated 256 above). If used with any other endpoint name (whether wild-carded or 257 not), then error code 801 (section 2.5) MUST be returned. 259 2.3. Redirect 261 A new extension parameter for use with the EndpointConfiguration 262 command is defined. A new NotifiedEntity value can be included with 263 a "RED/N" parameter as follows: 265 EPCF 1200 *@gw1.whatever.net MGCP 1.0 266 RED/N: ca1@ca1234.whatever.net 268 This changes the "notified entity" for the endpoint(s) to the value 269 specified. If the "all of" wildcard convention is used, the 270 NotifiedEntity value replaces all of the existing "notified entities" 271 for those endpoints. If NotifiedEntity is omitted in a subsequent 272 EndpointConfiguration command, the "notified entity" remains 273 unchanged. 275 In the case where the "notified entity" is a domain name that 276 resolves to multiple IP addresses, one of the resolved addresses MUST 277 be selected. If one of those IP addresses is the IP address of the 278 Call Agent sending the request, that IP address SHOULD be selected 279 first. 281 The NotifiedEntityList parameter can also be specified in an endpoint 282 configuration command, e.g.: 284 EPCF 1200 *@gw1.whatever.net MGCP 1.0 285 RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net 287 As indicated in section 2.2, it can also apply this to the gateway 288 virtual endpoint e.g.: 290 EPCF 1200 MG@gw1.whatever.net MGCP 1.0 291 RED/EL: * 292 RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net 294 As indicated in section 2.1, the NotifiedEntityList ("RED/NL") 295 parameter MAY be used with any command for which a NotifiedEntity 296 parameter is allowed. However, the "RED/N" parameter SHOULD only be 297 used with the endpoint configuration command. 299 The "RED/N" parameter does not have a default value, and the auditing 300 behavior for auditing the "NotifiedEntity" is unchanged from that 301 specified in [2], regardless of how the "NotifiedEntity" was set 302 (i.e. there is no specific audit associated with the "RED/N" 303 parameter and hence the "RED/N" parameter cannot be audited). 305 2.4. Reset Extension Parameter 307 Another EndpointConfiguration parameter ("RED/R"), allows the Call 308 Agent to reset one or more endpoints. The ABNF syntax for the 309 parameter line is as follows: 311 "RED/R:" 0*WSP "reset" 313 This has the effect of re-setting and re-initializing the specified 314 endpoints (i.e. any connections on the endpoint will be deleted, and 315 the endpoint will be returned to its clean default state without any 316 active signals, etc.). 318 Example: 320 EPCF 1200 mg@gw1.whatever.net MGCP 1.0 321 RED/EL: ds/e1-3/[1-30] 322 RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF 323 RED/EL: ds/e1-5/[1-30] 324 RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT 325 RED/R: reset 327 In this case, the particular endpoints specified by "T" by the 328 EndpointMap parameter in the E1 spans ds/e1-3 and ds/e1-5 are reset. 330 The "RED/R" parameter MUST NOT be used with any command other than 331 the endpoint configuration parameter. There is no default value for 332 the parameter and hence when omitted, it does not affect operation. 333 There is no specific audit behavior associated with this parameter, 334 i.e. it cannot be audited. 336 2.5. Return Codes 338 The following package specific return codes are defined for the "RED" 339 package: 341 Code Text Explanation 343 800 EndpointMap Either the EndpointMap parameters 344 Out of Range are outside the range specified by 345 the EndpointList parameter or the 346 EndpointList Parameter was not 347 included when an EndpointMap 348 parameter was included. 350 801 Incorrect Usage Incorrect usage of parameters such 351 Of Parameters as EndpointList parameter used 352 where the endpoint name was not 353 the virtual endpoint name 354 corresponding to the gateway. 356 3.0. IANA Considerations 358 The MGCP package title "Redirect and Reset" with the name "RED" and 359 version number 0 should be registered with IANA as indicated in 360 Appendix C.1 in [2]. 362 4.0. Security Considerations 364 Section 5 of the base MGCP specification [2] discusses security 365 requirements for the base protocol, which apply equally to the 366 package defined in this document. Use of a security Protocol such as 367 IPsec (RFC 2401, RFC 2406) that provides per message authentication 368 and integrity services is required in order to ensure that requests 369 and responses are obtained from authenticated sources and that 370 messages have not been modified. Without such services, gateways and 371 Call Agents are open to attacks. 373 For example, without such security services an attacker could 374 masquerade as a Call Agent and initiate a denial of service attack by 375 resetting endpoints that were involved in valid calls. Another attack 376 using the package described in this document could involve re- 377 directing endpoints to itself so that it now acts as the Call Agent 378 for those endpoints. 380 5.0. Normative References 382 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 383 Levels", BCP 14, RFC 2119, March 1997. 385 [2] F. Andreasen, B. Foster "Media Gateway Control Protocol (MGCP) 386 Version 1.0", RFC 3435, January 2003 388 Authors' Addresses 390 Flemming Andreasen 391 Cisco Systems 392 499 Thornall Street, 8th Floor 393 Edison, NJ 08837 394 EMail: fandreas@cisco.com 396 Bill Foster 397 Cisco Systems 398 EMail: bfoster@cisco.com 400 Intellectual Property Statement 402 The IETF takes no position regarding the validity or scope of any 403 intellectual property or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; neither does it represent that it 407 has made any effort to identify any such rights. Information on the 408 IETF's procedures with respect to rights in standards-track and 409 standards-related documentation can be found in BCP-11. Copies of 410 claims of rights made available for publication and any assurances of 411 licenses to be made available, or the result of an attempt made to 412 obtain a general license or permission for the use of such 413 proprietary rights by implementors or users of this specification can 414 be obtained from the IETF Secretariat. 416 The IETF invites any interested party to bring to its attention any 417 copyrights, patents or patent applications, or other proprietary 418 rights which may cover technology that may be required to practice 419 this standard. Please address the information to the IETF Executive 420 Director. 422 Full Copyright Statement 424 Copyright (C) The Internet Society (2003). All Rights Reserved. 426 This document and translations of it may be copied and furnished to 427 others, and derivative works that comment on or otherwise explain it 428 or assist in its implementation may be prepared, copied, published 429 and distributed, in whole or in part, without restriction of any 430 kind, provided that the above copyright notice and this paragraph are 431 included on all such copies and derivative works. However, this 432 document itself may not be modified in any way, such as by removing 433 the copyright notice or references to the Internet Society or other 434 Internet organizations, except as needed for the purpose of 435 developing Internet standards in which case the procedures for 436 copyrights defined in the Internet Standards process must be 437 followed, or as required to translate it into languages other than 438 English. 440 The limited permissions granted above are perpetual and will not be 441 revoked by the Internet Society or its successors or assigns. 443 This document and the information contained herein is provided on an 444 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 445 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 446 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 447 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 448 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 450 Acknowledgement 452 Funding for the RFC Editor function is currently provided by the 453 Internet Society.