idnits 2.17.1 draft-fajardo-dime-app-design-guide-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 665. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (April 18, 2007) is 6190 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-01 == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintanence and V. Fajardo, Ed. 3 Extensions (DIME) Toshiba America Research Inc. 4 Internet-Draft T. Asveren 5 Intended status: Informational Sonus Network 6 Expires: October 20, 2007 H. Tschofenig 7 Siemens Networks GmbH & Co KG 8 G. McGregor 9 Alcatel-Lucent 10 J. Loughney 11 Nokia Research Center 12 April 18, 2007 14 Diameter Applications Design Guidelines 15 draft-fajardo-dime-app-design-guide-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 20, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The Diameter Base protocol provides rules on how to extend Diameter 49 and to create new Diameter applications. This is a companion 50 document to clarify these rules. This document does not intended to 51 add, remove or change these rules, rather it helps protocol designers 52 to extend Diameter. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3 59 4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4 60 4.1. Rules on Extending Existing Applications . . . . . . . . . 5 61 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Diameter Accounting Support . . . . . . . . . . . . . . . 7 63 5.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 8 64 5.3. Updating an existing Application . . . . . . . . . . . . . 9 65 5.4. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 10 66 5.5. Deleting AVPs from a Command ABNF . . . . . . . . . . . . 10 67 5.6. Justifying the Allocation of Application-Id . . . . . . . 11 68 5.7. Use of Application-Id in a Message . . . . . . . . . . . . 11 69 5.8. Support for Server Initiated Requests . . . . . . . . . . 11 70 5.9. System Architecture and Deployment . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Intellectual Property and Copyright Statements . . . . . . . . . . 15 80 1. Introduction 82 The Diameter Base protocol document defines rules on how one would 83 extend Diameter (see Section 1.2 of [1]). In the context of this 84 document, extending Diameter means that a new Diameter application is 85 being defined which may or may not be based on an existing Diameter 86 application. A decision to define a new application would mean 87 allocation of a new application ID. 89 By themselves, the rules defined in the Diameter Base protocol are 90 not necessarily comprehensive enough that one can easily derive good 91 design decisions from them. The effect of this can be seen in 92 various attempts to extend Diameter where protocol designers have no 93 clear answer on whether to even define a new application or not. At 94 worst, some existing Diameter applications that had purposely been 95 derived from another existing application resulted in some in- 96 appropriate design decision in which both applications are no longer 97 interoperable in certain conditions. 99 The intent of this document is to influence ongoing and future 100 Diameter application design by providing the following content: 102 o Clarify existing Diameter extensibility rules present in the 103 Diameter Base Protocol. 105 o Clarify usage of certain Diameter functionality which are not 106 explicitly described in the Diameter Base specification. 108 o Discuss design choices when defining new applications. 110 o Present tradeoffs of design choices. 112 Note that it is not always possible to offer a complete and concise 113 answer to certain design choices. There is, however, the belief that 114 at a minimum, this document can be used as a guide to Diameter 115 extensibility. 117 2. Terminology 119 This document reuses the terminology used in [1]. 121 3. Diameter Application Model 123 As it is currently interpreted and practiced, the Diameter Base 124 protocol is a two-layer protocol. The lower layer is mainly 125 responsible for managing connections between neighboring peers and 126 for message routing. The upper layer is where the Diameter 127 applications reside. This model is inline with a Diameter node 128 having an application layer and a peer-to-peer delivery layer. The 129 Diameter Base protocol document completely defines the architecture 130 and behavior of the message delivery layer and then provides the 131 framework for designing Diameter applications on the application 132 layer. This framework includes definitions of application sessions 133 and accounting support (see Section 8 and 9 of [1]). The remainder 134 of this document also treats a Diameter node as a single instance of 135 a Diameter message delivery layer and one or more Diameter 136 applications using it. 138 4. Rules on Diameter Extensibility 140 The general theme of Diameter extensibility is to reuse AVPs, AVP 141 values, commands and applications as much as possible. However, 142 there are also rules for extending Diameter as specified in Section 143 1.2 of [1]. As is, the rules apply to the scenario where one is 144 trying to define a new Diameter application. Defining a new Diameter 145 application can be done by: 147 Defining a completely new application 149 This case applies to applications which have requirements that 150 cannot be filled by existing applications and would require 151 definition of new command(s), AVPs and AVP values. Typically, 152 there is little ambiguity about the decision to create these types 153 of applications. Some examples are the interfaces defined for the 154 IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh 155 ([4] and [5]) etc . Though some decisions may be clear, designers 156 should also consider certain aspects of the application itself. 157 Some of these are described in Section 5. Applications design 158 should also follow the theme of Diameter extensibility which 159 advocates reuse of AVPs and AVP values as much as possible even in 160 newly defined commands. In certain cases where accounting will be 161 used, the models described in Section 5.1 should be considered. 163 Extending an existing application 165 In this case, the requirements of the new applications are not 166 completely unique and there are existing application's that can be 167 reused to solve some or all of the application requirements. 168 Thus, there is a greater likelihood of ambiguity on how much of 169 the existing application can be reused, to what extent and what 170 the implications for both the new and existing application. 171 Section 4.1 discusses some of the issues in this case. 173 4.1. Rules on Extending Existing Applications 175 The Diameter base protocol provides a clear set of rules on when one 176 should define a new Diameter application. In the context of this 177 document, the rules are: 179 Adding an AVP to a command ABNF of an existing application 181 The rules are strict in the case where the AVP(s) to be added is 182 mandatory to be understood and interpreted. This means that the 183 M-bit is set and the AVP(s) is required to exist in command ABNF. 184 Note that this mandatory AVP rule applies to AVP(s) that either 185 already exist in the same or in another application or the AVP(s) 186 are yet to be defined. In the latter case, the ambiguity arises 187 when trying to decide whether the AVP(s) should be mandatory or 188 not. There are several questions that application designers 189 should contemplate when trying to decide: 191 * Does the AVP(s) change the state machine of the application ? 193 * Would the presence of the AVP(s) cause additional message 194 round-trips; effectively changing the state machine of the 195 application ? 197 * Will the AVP be used to fulfill new required functionality ? 199 * Would the AVP be used to differentiate between old and new 200 versions of the same application ? 202 * Will it have duality in meaning; i.e., be used to carry 203 application related information as well as be used to indicate 204 that the message is for a new application ? 206 These questions are not comprehensive in any way but in all cases 207 the semantics of the application must change to justify the use of 208 mandatory AVPs. 210 However, care should also be taken when opting for optional AVPs 211 instead of mandatory AVPs simply to avoid allocating new 212 applications. Optional AVPs that fall into any of the categorical 213 questions above would have consequences. See Section 5.4 for 214 details. 216 Add a new AVP value to an to an existing AVP 218 In this case, the rule applies to existing mandatory AVPs already 219 present in a command ABNF where the semantics of the AVP changes. 220 This means that the meaning or usage of the AVP has changed and 221 significantly affects the behavior of the application. Although 222 this case may be less common or seem more subtle, the exact same 223 considerations given in the first scenario above apply here as 224 well. 226 Add a command to an existing application 228 In this case, the rule applies to defining a new command for an 229 existing application or importing an existing command from another 230 application so as to inherit some or all of the functionality of 231 that application. In the first case, the decision is straight 232 forward since this is typically a result of adding new 233 functionality that does not yet exist. The latter case would 234 result in a new application but it has a more subtle issue such as 235 deciding whether importing of commands and functionality is really 236 better than simply using the existing application as it is in 237 conjunction with any new application. 239 A typical example would be the Diameter MIPv6 split scenario (see 240 [6]) in which several application models would have been possible 241 during the design phase; one model would reuse existing Diameter 242 EAP application combined with a new Diameter MIPv6 application to 243 form a complete authentication and authorization scheme and 244 another would be to reuse Diameter EAP like commands within the 245 new Diameter MIPv6 application to accomplish the same result. In 246 this case, the latter model was chosen which would permit the 247 reuse of commands and/or AVPs from one application to another. 248 Other applications such as Diameter QoS (see [7]) would likely 249 face similar decisions. 251 In general, it is difficult to come to a hard and fast guideline 252 for this scenario so a case by case study of each application 253 requirement should be applied. Before importing a command, 254 application designers should consider whether: 256 * The existing application can be reused as is without 257 fundamental changes; i.e. an optional AVP is sufficient to 258 indicate support for new optional functionality if any. There 259 are pitfalls to this as well. See Section 5.4 261 * Reuse of existing applications would result in a distributed 262 environment which may not be conducive to certain requirements 263 of the applications; i.e. security and or deployment 264 difficulties - because of Diameter routing, messages for 265 different applications providing service to the same user may 266 end up in different servers would then need to be co-related. 267 This could mean extra signaling between application servers. A 268 typical example would be the initial proposal for Diameter 269 MIPv6 split scenario (see [6]) where authorization and 270 authentication is separated. 272 5. Design Considerations 274 The following are some of the design considerations that apply to a 275 Diameter application. 277 5.1. Diameter Accounting Support 279 Accounting can be treated as an auxiliary application which is used 280 in support of other applications. In most cases, accounting support 281 is required when defining new applications. However, the lack of 282 clarity in the base protocol document has prevented easy use the base 283 accounting messages (ACR/ACA). This document provides two(2) 284 possible models for using accounting: 286 Split Accounting Model 288 In this model, the accounting messages will use the Diameter base 289 accounting application ID (value of 3). The design implication 290 for this is that the accounting is treated as an independent 291 application, especially during routing. This means that 292 accounting commands emanating from an application may be routed 293 separately from the rest of the other application messages. This 294 also implies that the messages generally end up in a central 295 accounting server. A split accounting model is a good design 296 choice when: 298 * The application itself will not define its own unique 299 accounting commands. 301 * The overall system architecture permits the use of centralized 302 accounting for one or more Diameter applications. 304 From a Diameter architecture perspective, this model should be the 305 typical design choice. Note that when using this model, the 306 accounting server must use the Acct-Application-Id AVP to 307 determine which application is being accounted for. Therefore, 308 the application designer should specify the proper values used in 309 Acct-Application-Id AVP when sending ACR messages. 311 Coupled Accounting Model 313 In this model, the accounting messages will use the application ID 314 of the application using the accounting service. The design 315 implication for this is that the accounting messages is tightly 316 coupled with the application itself; meaning that accounting 317 messages will be routed like any other application messages. It 318 would then be the responsibility of the application server 319 (application entity receiving the ACR message) to send the 320 accounting records carried by the accounting messages to the 321 proper accounting server. The application server is also 322 responsible for formulating a proper response (ACA). A coupled 323 accounting model is a good design choice when: 325 * The system architecture or deployment will not provide an 326 accounting server that supports Diameter. 328 * The system architecture or deployment requires that the 329 accounting service for the specific application should be 330 handled by the application itself. 332 * The application server is provisioned to use a different 333 protocol to access the accounting server; i.e., via LDAP, XML 334 etc. This includes attempting to supporting older accounting 335 systems that are not Diameter aware. 337 In all cases above, there will generally be no direct Diameter 338 access to the accounting server. 340 These models provide a basis for using accounting messages. 341 Application designers may obviously deviate from these models 342 provided that the factors being addressed here have also been taken 343 into account. Though it is not recommended, examples of other 344 methods would be defining a new set of commands to carry application 345 specific accounting records. 347 Additionally, the application ID in the message header and 348 Accounting-Application-Id AVP are populated depending on the 349 accounting model used for a specific application, as described in 350 [1]. Therefore, application designers have to specify the accounting 351 model used to guarantee proper routing of accounting requests. 353 5.2. Generic Diameter Extensions 355 Generic Diameter extensions are AVPs, commands or applications that 356 are designed to support other Diameter applications. They are 357 auxiliary applications meant to improve or enhance the Diameter 358 protocol itself or Diameter applications/functionality. Some 359 examples include the extensions to support auditing and redundancy 360 (see [8]), improvements in duplicate detection scheme (see [9]). 362 Since generic extensions can cover many aspects of Diameter and 363 Diameter applications, it is not possible to enumerate all the 364 probable scenarios in this document. However, some of the most 365 common considerations are as follows: 367 o Backward compatibility: Dealing with existing applications that do 368 not understand the new extension. Designers also have to make 369 sure that new extensions do not break expected message delivery 370 layer behavior. 372 o Forward compatibility: Making sure that the design will not 373 introduce undue restrictions for future applications. Future 374 applications attempting to support this feature should not have to 375 go through great lengths to implement any new extensions. 377 o Tradeoffs in signaling: Designers may have to choose between the 378 use of optional AVPs piggybacked onto existing commands versus 379 defining new commands and applications. Optional AVPs are simpler 380 to implement and may not need changes to existing applications; 381 i.e., use of proxy agents. However, the drawback is that the 382 timing of sending extension data will be tied to when the 383 application would be sending a message. This has consequences if 384 the application and the extensions have different timing 385 requirements. The use of commands and applications solves this 386 issue but the tradeoff is the additional complexity of defining 387 and deploying a new application. It is left up to the designer to 388 find a good balance among these tradeoffs based on the 389 requirements of the extension. 391 5.3. Updating an existing Application 393 An application that is being upgraded must follow the same rules 394 mentioned Section 4. Even if the new version is fundamentally the 395 same application, allocation of a new application ID is possible if 396 it meets those criteria. 398 Optional AVPs can also be used to indicate version differences. If 399 this approach is chosen, it is recommended that the optional AVP is 400 used specifically to indicate version information only and nothing 401 else. Additionally, the use of too many optional AVPs to carry 402 application enhancements should be avoided since such approach has a 403 tendency to become unmanageable and introduce interoperability 404 issues. These pitfalls are discussed in Section 5.4 405 For the same reason, care should be taken in attempting to justify 406 allocation of new application ID for every change. The pitfalls of 407 this approach is discussed in Section 5.6. 409 5.4. Use of optional AVPs 411 Problems arise when there is a tendency by applications designers to 412 keep adding optional AVPs to an existing command so they can 413 circumvent the extension rules in Section 4. Some of the pitfalls 414 that application designers should avoid are: 416 o Use of optional AVPs with intersecting meaning; one AVP has 417 partially the same usage and/or meaning as another AVP. The 418 presence of both can lead to confusion. 420 o Optional AVPs with dual purpose; i.e.; to carry applications data 421 as well as to indicate support for one or more features. This has 422 a tendency to introduce interpretation issues. 424 o Use of optional AVPs with a minimum occurrence of one(1) in the 425 command ABNF. This is generally contradictory. Application 426 designers should not use this scheme to circumvent definition of 427 mandatory AVPs. 429 All of these practices generally result in interoperability problems 430 so they should be avoided as much as possible. 432 5.5. Deleting AVPs from a Command ABNF 434 Although this scenario is not as common, the deletion of AVPs from a 435 command ABNF is significant when trying to extend an existing 436 application. Deletion can be categorized between deletion of 437 mandatory and optional AVPs. 439 In the unlikely event that an application designer would require that 440 mandatory AVPs must be deleted then it constitutes a fundamental 441 change to an existing application. Though not specified in [1], 442 deletion of mandatory would require the allocation of a new 443 application since it dictates changes in the behavior and semantics 444 of an application. 446 The deletion of an optional AVP may not necessarily indicate 447 allocation of a new application. An optional AVP with a minimum 448 occurrence of at least one(1) in the command ABNF would mean that the 449 AVP is required and that if deleted, there would effectively be 450 changes to the behavior of the application as well. Such cases are 451 highly dubious to begin with since those AVPs already exhibits 452 properties of mandatory AVPs. It should therefore fall into the 453 category of deleting mandatory AVPs. 455 In other cases, it is recommended that application designers reuse 456 the command ABNF as is and safely ignore (but not delete) any 457 optional AVP that will not be used. This is to maintain 458 compatibility with existing applications that will not know about the 459 new functionality as well as maintain the integrity of existing 460 dictionaries. 462 5.6. Justifying the Allocation of Application-Id 464 Application designers should avoid justifying the allocation of 465 application IDs for every change that is made to an existing 466 application. Proliferation of application ID can lead to confusion 467 and an in-efficient use of the application ID namespaces. 468 Application designers should always use Section 4 as a basis for 469 justifying allocation of a new application ID. 471 5.7. Use of Application-Id in a Message 473 When designing new applications, designers should specify that the 474 application ID carried in all session level messages must be the 475 application ID of the application using those messages. This 476 includes the session level messages defined in base protocol, i.e., 477 RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled 478 accounting model, see Section 5.1. Existing specifications may not 479 adhere to this rule for historical or other reasons. However, this 480 scheme is followed to avoid possible routing problems for these 481 messages. 483 Additionally, application designers using the Vendor-Specific- 484 Application-Id AVP should note that the Vendor-Id AVP will not be 485 used in any way by the Diameter message delivery layer. Therefore 486 its meaning and usage should be segregated only within the 487 application. 489 5.8. Support for Server Initiated Requests 491 Section 8 of [1] implies that only client sessions can initiate a 492 request messages. Assuming that the Diameter client and server 493 sessions can be de-coupled from application client and server 494 entities, an application design requiring server initiated request 495 can simply create a Diameter client session and the client entity can 496 then initiate a corresponding Diameter server session. 498 5.9. System Architecture and Deployment 500 The following are some of the architecture considerations that 501 applications designers should contemplate when defining new 502 applications: 504 o For general AAA applications, Diameter requires more message 505 exchanges for the same set of services compared to RADIUS. 506 Therefore, application designers should consider scalability 507 issues during the design process. 509 o Application design should be agnostic to any Diameter topology. 510 Application designers should not always assume a particular 511 Diameter topology; i.e., assume that there will always be 512 application proxies in the path or assume that only intra-domain 513 routing is applicable. 515 o Security Considerations. Application designers should take into 516 account that there is no end-to-end authentication built into 517 Diameter. 519 o Application design should consider some form of redundancy. 520 Session state information is the primary data necessary for 521 backup/recovering endpoints to continue processing for an 522 previously existing session. Carrying enough information in the 523 messages to reconstruct session state facilitates redundant 524 implementations and is highly recommended. 526 o Application design should segregate message delivery layer 527 processing from application level processing. An example is the 528 use of timers to detect lack of a response for a previously sent 529 requests. Although the Diameter base protocol defines a watchdog 530 timer Tw, its use on application level is discouraged since Tw is 531 a hop-by-hop timer and it would not be relevant for end-to-end 532 message delivery error detection. In such a case, it is 533 recommended that applications should define their own set of 534 timers for such purpose. 536 6. IANA Considerations 538 This document does not require actions by IANA. 540 7. Security Considerations 542 This document does provides guidelines and considerations for 543 extending Diameter and Diameter applications. It does not define nor 544 address security related protocols or schemes. 546 8. Acknowledgments 548 We greatly appreciate the insight provided by Diameter implementers 549 who have highlighted the issues and concerns being addressed by this 550 document. 552 9. References 554 9.1. Normative References 556 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 557 "Diameter Base Protocol", RFC 3588, September 2003. 559 [2] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message 560 contents", 3GPP TS 29.228 Version 7.0.0 2006. 562 [3] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol; 563 Protocol details", 3GPP TS 29.229 Version 7.0.0 2006. 565 [4] 3GPP, "IMS Sh interface : signalling flows and message content", 566 3GPP TS 29.328 Version 6.8.0 2005. 568 [5] 3GPP, "IMS Sh interface based on the Diameter protocol; Protocol 569 details", 3GPP TS 29.329 Version 6.6.0 2005. 571 [6] Bournelle, J., "Diameter Mobile IPv6: HA-to-AAAH support", 572 draft-ietf-dime-mip6-split-01 (work in progress), October 2006. 574 [7] Zorn, G., "Diameter Quality of Service Application", 575 draft-ietf-dime-diameter-qos-00 (work in progress), 576 February 2007. 578 9.2. Informative References 580 [8] Calhoun, P., "Diameter Resource Management Extensions", 581 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 582 March 2001. 584 [9] Asveren, T., "Diameter Duplicate Detection Cons.", 585 draft-asveren-dime-dupcons-00 (work in progress), August 2006. 587 Authors' Addresses 589 Victor Fajardo (editor) 590 Toshiba America Research Inc. 591 One Telcordia Drive 592 Piscataway, NJ 08854 593 USA 595 Email: vfajardo@tari.toshiba.com 597 Tolga Asveren 598 Sonus Network 599 4400 Route 9 South 600 Freehold, NJ, 07728 601 USA 603 Email: tasveren@sonusnet.com 605 Hannes Tschofenig 606 Siemens Networks GmbH & Co KG 607 Otto-Hahn-Ring 6 608 Munich, Bavaria 81739 609 Germany 611 Phone: +49 89 636 40390 612 Email: Hannes.Tschofenig@siemens.com 613 URI: http://www.tschofenig.com 615 Glenn McGregor 616 Alcatel-Lucent 617 USA 619 Email: glenn@aaa.lucent.com 621 John Loughney 622 Nokia Research Center 623 USA 625 Email: john.loughney@nokia.com 627 Full Copyright Statement 629 Copyright (C) The IETF Trust (2007). 631 This document is subject to the rights, licenses and restrictions 632 contained in BCP 78, and except as set forth therein, the authors 633 retain all their rights. 635 This document and the information contained herein are provided on an 636 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 637 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 638 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 639 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 640 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 641 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 643 Intellectual Property 645 The IETF takes no position regarding the validity or scope of any 646 Intellectual Property Rights or other rights that might be claimed to 647 pertain to the implementation or use of the technology described in 648 this document or the extent to which any license under such rights 649 might or might not be available; nor does it represent that it has 650 made any independent effort to identify any such rights. Information 651 on the procedures with respect to rights in RFC documents can be 652 found in BCP 78 and BCP 79. 654 Copies of IPR disclosures made to the IETF Secretariat and any 655 assurances of licenses to be made available, or the result of an 656 attempt made to obtain a general license or permission for the use of 657 such proprietary rights by implementers or users of this 658 specification can be obtained from the IETF on-line IPR repository at 659 http://www.ietf.org/ipr. 661 The IETF invites any interested party to bring to its attention any 662 copyrights, patents or patent applications, or other proprietary 663 rights that may cover technology that may be required to implement 664 this standard. Please address the information to the IETF at 665 ietf-ipr@ietf.org. 667 Acknowledgment 669 Funding for the RFC Editor function is provided by the IETF 670 Administrative Support Activity (IASA).