idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 4, 2007) is 6263 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '1') Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED WG Hiroaki Satou, NTT 2 Internet-Draft Hiroshi Ohta, NTT 3 Proposed Status: Informational Christian Jacquenet, France Telecom 4 Expires: September 2, 2007 Tsunemasa Hayashi, NTT 5 Haixiang He, Nortel Networks 6 March 4, 2007 8 AAA Framework for Multicasting 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 41 IP multicast-based services, such as TV broadcasting or 42 videoconferencing raise the issue of making sure that potential 43 customers are fully entitled to access the corresponding 44 contents. There is indeed a need for service and content 45 providers to identify (if not authenticate, especially within the 46 context of enforcing electronic payment schemes) and to invoice 47 such customers in a reliable and efficient manner. This memo 48 describes the framework for specifying the Authorization, 49 Authentication and Accounting (AAA) capabilities that could be 50 activated within the context of the deployment and the operation 51 of IP multicast-based services. This framework addresses the 52 requirements presented in draft-ietf-mboned-maccnt-req-04.txt, 53 "Requirements for Accounting, Authentication and Authorization in 54 Well Managed IP Multicasting Services". 56 1. Introduction 58 1.1 Purpose and Background 59 IP multicasting is designed to serve cases of group communication 60 schemes of any kind, such as 1-to-n (case of TV broadcasting 61 services for example) or n-to-p (case of videoconferencing services, 62 for example). 63 In these environments, IP multicast provides a better resource 64 optimization than using a unicast transmission scheme, where data 65 need to be replicated as many times as there are receivers. 66 Activation of IP multicast capabilities in networks yields the 67 establishment and the maintenance of multicast distribution trees 68 that are receiver-initiated by nature: multicast-formatted data are 69 forwarded to receivers who explicitly request them. 71 IP multicast-based services, such as TV broadcasting or 72 videoconferencing raise the issue of making sure that potential 73 customers are fully entitled to access the corresponding contents. 74 There is indeed a need for service and content providers to identify 75 (if not authenticate, especially within the context of enforcing 76 electronic payment schemes) and to invoice such customers in a 77 reliable and efficient manner. This memo describes the framework for 78 specifying the Authorization, Authentication and Accounting (AAA) 79 capabilities that could be activated within the context of the 80 deployment and the operation of IP multicast-based services. 81 Specifically, this framework addresses the requirements 82 presented in draft-ietf-mboned-maccnt-req-04.txt, "Requirements for 83 Accounting, Authentication and Authorization in Well Managed IP 84 Multicasting Services" MACCNT-REQ-draft describes the requirements 85 in CDN services using IP multicast[1]. The requirements are derived 86 from: 87 - need for user tracking and billing capabilities 88 - need for network access control to satisfy the requirements 89 of the Network Service Provider (NSP) and/or content access control 90 to satisfy the requirements of the Content Provider (CP) 91 - methods for sharing information between the network service 92 provider and content provider to make it possible to fulfill the 93 above two requirements. 95 Detailed requirements are presented in MACCNT-REQ-draft. These 96 requirements include mechanisms for recording end-user requests and 97 provider responses for content-delivery, sharing user information 98 (possibly anonymously depending on the trust model) between content 99 provider and network service provider, and protecting resources 100 through the prevention of network and content access by unauthorized 101 users, as well as other AAA related requirements. 103 The purpose of this memo is to provide a generalized framework for 104 specifying multicast-inferred AAA capabilities that can meet these 105 requirements. This framework is to provide a basis for future work 106 of investigating the applicability of existing AAA protocols to 107 provide these AAA capabilities in IP multicast specific context 108 and/or if deemed necessary, the refining or defining of protocols to 109 provide these capabilities. 111 This draft's scope is limited to discussing SSM, 1-to-n IP 112 multicasting exclusively. 114 2. Definitions and Abbreviations 116 2.1 Definitions 118 For the purpose of this memo the following definitions apply: 120 Accounting: The set of capabilities that allow the retrieval of a 121 set of statistical data that can be defined on a per customer and/or 122 a per service basis, within the context of the deployment of 123 multicast-based services. Such data are retrieved for billing 124 purposes, and can be retrieved on a regular basis or upon 125 unsolicited requests. Such data include (but are not necessarily 126 limited to) the volume of multicast-formatted data that have been 127 forwarded to the receiver over a given period of time, the volume of 128 multicast-formatted data that have been exchanged between a receiver 129 (or set of) and a given source over a given period of time (e.g. the 130 duration of a multicast session), etc. 132 Authentication: action for identifying a user as a genuine one. 134 Authorization: The set of capabilities that need to be activated to 135 make sure a given requesting customer is (1) what he claims to be 136 (identification purposes), and (2) is fully entitled to access a set 137 of services (authentication purposes). 139 Receiver: an end-host or end-client which receives content. A 140 receiver may be identified by a network ID such as MAC address or IP 141 address. 143 User: a human with a user account. A user may possibly use multiple 144 reception devices. Multiple users may use the same reception 145 device. 147 Note: The definition of a receiver (device) and a user (human) 148 should not be confused. 150 2.2 Abbreviations 152 For the purpose of this draft the following abbreviations apply: 154 ACL: Access Control List 155 CDN: Content Delivery Network 157 CDS: Content Delivery Services 159 CP: Content Provider 161 NSP: Network Service Provider 163 TP: Transit Provider 165 3. Common use models and network architecture implications 167 In some cases a single entity may design and be responsible for a 168 system that covers the various common high-level requirements of a 169 multicasting system such as 1) content serving, 2) the 170 infrastructure to multicast it, 3) network and content access 171 control mechanisms. In many cases however the content provision and 172 network provision roles are divided between separate entities. The 173 MACCNT-REQ-draft provides more detail of the multiple versus single 174 entity CDS network models. 176 As such it should not be assumed that the entity responsible for the 177 multicasting structure and the entity responsible for content 178 serving are the same. Indeed because the infrastructure for 179 multicasting is expensive and many content holders are not likely to 180 be competent at building and maintaining complicated infrastructures 181 necessary for multicasting, many content holders would prefer to 182 purchase transport and management services from a network service 183 provider and thus share the infrastructure costs with other content 184 holders. 186 Similarly network service providers in many cases do not specialize 187 in providing content and are unlikely to build and maintain such a 188 resource-intensive system without a certain level of demand from 189 content holders. 191 The use model of a single NSP providing multicasting services to 192 multiple CPs the following general requirements from MACCNT-REQ- 193 draft apply: 195 -Need for user tracking and billing capabilities 196 -Need for network access control and/or content access control 197 satisfactory to the requirements of the CP 198 -Methods for sharing information between the NSP and CP to make 199 the above two possible 201 When the NSP and CP are the same single entity the general 202 requirements are as follows. 204 -Need for user tracking and user-billing capabilities 205 -Need for access control and/or content protection at level the 206 entity deems appropriate 208 4. Framework and Roles of Entities 210 4.1 Framework for multicast AAA 211 A general high-level framework can be represented as follows. 213 +------------------------------+ 214 | user | 215 | | 216 +------------------------------+ 217 | Access ^ Response 218 | Request | & Multicast Data 219 V | 220 +------------------------------+ 221 | NSP | 222 | | 223 +------------------------------+ 224 | Access ^ Response 225 | Request | (Success) 226 v | 227 +------------------------------+ 228 | CP | 229 | | 230 +------------------------------+ 232 For the sake of simplicity, the above diagram portrays a case where 233 there is a single NSP entity and a single CP entity, but multiple 234 CPs can be connected to the same NSP. It is also possible for the 235 same CP to be connected to multiple NSP networks (e.g. network 236 selection). In other words the relationship of NSP:CP can be 237 described as 1:1, 1:N or M:N. Furthermore it is possible that the 238 NSP and CP could be the same entity. 240 Description of Roles: 242 The user (or the user's device) selects a CP and a NSP when the user 243 requests content. The NSP may be automatically selected by a user 244 terminal: e.g. a fixed line NSP for STB or a mobile NSP for mobile 245 phone. In some usage cases it is possible that the NSP used by the 246 user terminal will not always be the same. For example a user may 247 have contracted with different NSPs for fixed line or mobile roaming 248 access. 250 The CP is responsible for Authentication and Authorization of users' 251 access to content that the CP manages. The CP hopes to collect 252 accounting information related to the access of their content. The 253 CP may choose to authenticate and authorize NSPs which are eligible 254 to provide users access to its contents. When the CP cannot (e.g. 255 error or resource issues) or decides not (e.g. policy issues) to 256 deliver content, the CP is responsible for notifying the NSP of the 257 reason. It is up to the NSP how to relay or translate the messages 258 to the user. 260 The NSP is responsible for managing its network resources. The NSP 261 may perform admission control. It is also responsible for relaying 262 the AAA messages from the CP whether the user is eligible to receive 263 content (authentication by proxy), and the NSPs relevant AAA server 264 will make the final decision of whether the connection can be 265 established. When the NSP cannot or decides not to multicast to 266 users, the NSP is responsible for notifying the users of the reason. 268 4.2 Multiple User IDs 270 Users may hold multiple user IDs: IDs which have been separately 271 assigned for each subscription they may have for various NSPs and 272 CPs. The NSPs and CPs control the user IDs for their respective 273 domains. The user IDs are only meaningful in the context of each 274 domain. 276 When the user wants to access content, the user registers the 277 corresponding user ID (including its CP domain information) with a 278 request for content, etc: web authentication is one possible method. 280 Each CP may identify users by the user IDs that it has issued to 281 them. 283 Terminal portability can be realized if the NSP authenticates a user 284 using a NSP-domained user ID. This allows the user to access the 285 content from various network access points. 287 The NSP and CP do not need to know the corresponding user id for the 288 same user in the other provider's domain, and it is not necessary 289 that there is a one to one relationship. It is quite possible for 290 one person to hold multiple user ids for the same provider. 292 The actual mapping rules for NSPs and CPs to map user IDs with the 293 IDs in other provider domains is a matter for the providers. A 294 solution should provide an API between the providers to flexibly 295 support various mapping methods. 297 4.3 Accounting 299 MACCNT-REQ-draft defines requirements for Accounting and Billing. 300 These include the requirement for the NSP to log user behavior such 301 as the join action and the leave action, as well as the result of 302 the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ- 303 draft also specifies that there should be a standardized format for 304 sharing with the CP the user behavior and content reception 305 information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) 306 In order to provide the granularity of user-behavior and actual 307 content reception information as specified in MACCNT-REQ-draft, the 308 NSP should not manage multicast states on a subnet basis, but on a 309 user basis (see in MACCNT-REQ-draft, 4.1 "User identification") 310 because the NSP needs to be able to notify the CP of a user's start 311 and stop times for accounting purposes. This means that the NSP 312 sends to the CP AAA an indication for Join and Leave on a user 313 basis. 315 This framework specifies an accounting API provided by the NSP and 316 accessed by the CP to allow for sharing user-behavior and content- 317 reception information between the NSP AAA and CP AAA. This 318 accounting API should be configurable to allow the CP to request 319 only the logging information it actually requires. Such an API 320 would allow for realtime accounting information sharing by the NSP 321 to the CP. When logging information is shared through the accounting 322 API, it is important that the CP be able to match the user as 323 described in the database operated by the NSP to the user as 324 described in the database operated by the CP. 326 The NSP requires the capability to log both user and host 327 information for each join and leave, indicating the corresponding 328 multicast source for each action. When either a CP source stops 329 sending, or the NSP stops multicasting, in an unsolicited manner, 330 there is also a need to notify the AAA servers accordingly about the 331 users who are impacted by this event. 333 Also, intermittent logs between the join and leave would allow for 334 finer diagnostics and therefore could serve useful in billing 335 discrepancies, and provide for a better estimation of the time span 336 that content was multicasted in the even that users disconnect 337 without sending leave messages. 339 4.4 Access Control and CP selection by NSP 341 When a NSP receives an access request from a user, it is necessary 342 for the NSP to determine to which CP the request is to be directed. 343 It is necessary for the NSP to ensure that it is not spoofed by an 344 inappropriate CP or user. 346 4.5 API for Admission Control Information by NSP 348 After authorizing a user request, the NSP may have further 349 conditions for determining its admission control decision. MACCNT- 350 REQ-draft defines requirements for providing the network capability 351 to conduct admission control based on the network bandwidth usage 352 status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2, 353 4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves 354 are out of the scope of this memo. However the NSP's AAA Server 355 should be provided with an Admission control API that allows for 356 interfacing so that additional conditions can be added to the 357 admission control decision. 359 4.6 Access Control and Distinguishing of Users by CP 361 The user ID and authentication information are forwarded 362 transparently by the NSP so that the CP can distinguish the user, as 363 well as authenticate and authorize the request. 365 4.7 Caching of AAA results 367 An NSP should be able to cache AAA results based upon an agreement 368 between the NSP and a CP. The AAA cache would store information 369 about permissions of a specific user to receive multicast data from 370 specified channel(s) up to specified expiration date(s) and time(s). 371 If such caching is implemented, a method must exist for the CP to 372 communicate this permission information to the NSP. The NSP refers 373 to the AAA cache and if the cache indicates that the user has 374 permission to receive multicast data from a specific channel at that 375 time, the NSP may forward the data without querying the CP. 377 It should be possible for a CP to send unsolicited requests to the 378 NSP to refresh or change the permissions for a user for specific 379 channel(s). 381 When a user is receiving multicast content and the permission is 382 about to expire, the NSP may send a notification to the user client 383 that his session is about to expire, and that he will need to re- 384 connect. The user will have to reestablish a connection. In the 385 case that the user still has permission to the content, they should 386 be able to continue to receive the content without interruption. 388 5. Network Connection Model and Functional Components 390 Section 3.1 introduces the high-level AAA framework for multicasting. 391 This section provides more detail on the network connection model 392 and constituent functional components. 394 5.1 Basic Connection Model 396 +-------------+ 397 | user | 398 | | 399 +-------------+ 400 ^ Access & Resource 401 | Request 402 v 403 +-------------+ 404 | NSP= NAP | 405 | | 406 +-------------+ 407 ^ Access 408 | Request 409 v 410 +-------------+ 411 | CP | 412 | | 413 +-------------+ 415 In this case the NSP is the sole entity providing Network Service 416 Provision including Network Access Provision to the User. First a 417 user that requests content sends an Access request to an NSP which 418 then forwards it on to the appropriate CP for Authentication and 419 Authorization purposes. The CP responds with either "success" or 420 "failure". If "success", the NSP may forward a success response and 421 stream multicast data to the user. 423 In this model the user selects the NSP to which to send its content 424 request. Based on this request the NSP selects an appropriate CP to 425 which it forwards the request. The CP responds to the NSP's request: 426 it may not respond to another NSP in regards to the request. 428 In this model, as described in section 3.1, the relationship between 429 NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple 430 networks, and networks have multiple users. 432 5.2 Transit Provision 434 The diagram below shows that Network Service Provision may include 435 both Network Access Provision to the User and also Transit Provision 436 (request relay) between the Network Access Provider (NAP) and the CP. 437 Transit Provision is the responsibility of the NSP which may or may 438 not contract out this service to a separate NSP that acts as the 439 Transit Provider. The existence of the Transit Provider is 440 transparent to the user. 442 +-------------+ 443 | user | 444 | | 445 +-------------+ 446 ^ Access & Resource 447 | Request 448 v 449 +- - - - - - - - - - - - - - + 450 |+----------------+ 451 | Network Access | | 452 || Provision | Network Service 453 +----------------+ | Provision 454 | ^ Access & Resource 455 | Request | 456 | v 457 +-------------+ | 458 || Transit | 459 | Provision | | 460 |+-------------+ 461 +- - - - - - - - - - - - - - + 462 ^ Access 463 | Request 464 v 465 +-------------+ 466 | CP | 467 | | 468 +-------------+ 470 For the sake of simplification the above diagram shows a 1-1 471 relationship between an NAP and a TP. However it is also possible 472 for a single NAP to connect to multiple TPs, and a single TP to 473 multiple NAPs. 475 A single TP may connect to one or more CPs. Similarly just as a 476 single CP may connect to multiple NAPs (as described in the general 477 high-level framework, section 3.1), a single CP may connect to one 478 or more TPs. 480 A solution will include a mechanism through which the NAPs know 481 which TP(s) are to be used to communicate with which CP(s), and CPs 482 know which TP(s) to use for which NAP(s). When a TP receives an 483 access or resource request from an NAP or CP, it must relay the 484 request to the correct CP or NSP, respectively. Minimally, this 485 means that it must reconstruct the request with translated address 486 information. In this model therefore a TP must understand the 487 format and meaning of the requests. 489 There may be multiple TPs between a NAP and CP so that a TP is 490 actually receiving from and/or sending requests to another TP and 491 not directly from/to a NAP or CP. 493 5.3 Transit with Tunnels 495 In addition to the above model of request relaying, a TP may 496 communicate requests through tunneling based on the contract between 497 the TP and the NAP and/or between the TP and the CP. So in this 498 case the TP will not directly need to process the contents of the 499 access and resource request (such as, header information), but 500 instead pass the request directly to the correct NSP or CP, using a 501 separate protocol to wrap the original requests. 503 Below is a diagram, representing how a TP can provide tunneling 504 between NAP(s) and CP(s). 506 +-----------------+ 507 | user | 508 | | 509 +-----------------+ 510 ^ Access & Resource 511 | Request 512 v 513 + - - - - - - - - - - + 514 +------------------+ 515 || NAP | | 516 | | 517 |+------------------+ | Network 518 |^| 519 | |:| | Service 520 |:| 521 |+-|:|--------------+ | Provision 522 | |:| TP | 523 || |:| | | 524 +-|:|--------------+ 525 + -|:|- - - - - - - - + 526 |:| Tunnel 527 |:| 528 |V| 529 +------------------+ 530 | CP | 531 | | 532 +------------------+ 534 In this model too, the relationship between NAP and TP and between 535 TP and CP can be 1:1, 1:N or M:N. 537 5.4 Constituent Logical Functional Components of the fully enabled AAA 538 Framework 540 Section 3.1 introduces the high-level AAA framework for multicasting. 541 Below is a diagram of a fully enabled multicasting network with AAA, 542 including the logical components within the various entities. 544 +-------------------------------+ 545 | user | 546 | | 547 +-------------------------------+ 548 ^ 549 | Access & resource request 550 v 551 +-------------------------------+ 552 | NSP | 553 | | 554 |+--------------+ +---------+| 555 ||NR Management |<-->|AAA Proxy|| (NR= network resource) 556 |+--------------+ RR +---------+| (RR= resource request) 557 +-------------------------------+ 558 ^ 559 | Access request 560 v 561 +------------------------------+ 562 | CP | 563 | | 564 | +---------+ | 565 | | AAA | | 566 | +---------+ | 567 +------------------------------+ 569 In the fully enabled model the NSP provides proxying of 570 authentication and authorization between the NSP and CP, as well as 571 user-based accounting. The AAA proxy server of the NSP communicates 572 with the CP's AAA server. Although not shown in the above diagram 573 for the sake of simplicity, in addition to direct proxying between a 574 NSP and CP, this proxying may be done through a TP. This means that 575 the transit provider is also cable of supporting AAA proxying. 577 In the fully enabled model the NSP also includes a component that 578 provides network resource management (e.g. QoS management), as 579 described in section 3.4, "Network Resource Management by NSP". 580 When a transit provider is used it may also provide Network Resource 581 management of its own resources. 583 5.5 Modularity of the framework 584 In the interest of flexibility, this framework is modular so that it 585 is possible that partially enabled versions of the models are 586 supported. A AAA-enabled version provides AAA functionality without 587 Network Resource management. A Network-Resource-Management-enabled 588 (QoS-enabled) version provides Network Resource management without 589 AAA functionality. Similarly, the possibility of one or more layers 590 of transit provision between an NSP and CP is in the interest of 591 modularity and extendibility. 593 6. IANA considerations 595 This memo does not raise any IANA consideration issues. 597 7. Security considerations 599 Refer to section 3.3. Also the user information related to 600 authentication with the CP must be protected in some way. 601 Otherwise, this memo does not raise any new security issues which 602 are not already addressed by the original protocols. Enhancement of 603 multicast access control capabilities should enhance security 604 performance. 606 8. Conclusion 608 This memo provides a generalized framework for solution standards to 609 meet the requirements presented in MACCNT-REQ-draft. Further work 610 should be done to break down the content provider and network 611 service provider entities into their functional objects such as edge 612 devices, AAA servers, etc. 614 Normative References 616 [1] Hayashi, et. al., "Accounting, Authentication and Authorization 617 Issues in Well Managed IP Multicasting Services", draft-ietf- 618 mboned-maccnt-req-04.txt, February 2006, Work in Progress. 620 Authors' Addresses 622 Hiroaki Satou 623 NTT Network Service Systems Laboratories 624 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 625 Phone : +81 422 59 4683 626 Email : satou.hiroaki@lab.ntt.co.jp 628 Hiroshi Ohta 629 NTT Network Service Systems Laboratories 630 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 631 Phone : +81 422 59 3617 632 Email: ohta.hiroshi@lab.ntt.co.jp 634 Christian Jacquenet 635 France Telecom 636 3, avenue Francois Chateau 637 CS 36901, 35069 Rennes Cedex, France 638 Phone: +33 2 99 87 63 31 639 Email: christian.jacquenet@francetelecom.com 641 Tsunemasa Hayashi 642 NTT Network Innovation Laboratories 643 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 644 Phone: +81 46 859 8790 645 Email: tsunemasa@gmail.com 647 Haixiang He 648 Nortel 649 600 Technology Park Drive 650 Billerica, MA 01801, USA 651 Phone: +1 978 288 7482 652 Email: haixiang@nortel.com 654 Comments 656 Comments are solicited and should be addressed to the mboned working 657 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 659 Intellectual Property Statement 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Disclaimer of Validity 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 688 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 689 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Copyright Statement 695 Copyright (C) The IETF Trust (2007). This document is subject to the 696 rights, licenses and restrictions contained in BCP 78, and except as 697 set forth therein, the authors retain all their rights. 699 Acknowledgment 701 Funding for the RFC Editor function is currently provided by the 702 Internet Society.