Tsunemasa Hayashi, NTT
     Internet Draft                                 Haixiang He, Nortel
     Document:draft-ietf-mboned-maccnt-req-03.txt    Hiroaki Satou, NTT
     Expires: June 18, July 14, 2006                           Hiroshi Ohta, NTT
                                         Susheela Vaidya, Cisco Systems

                                                      December 15, 2005

                                                       January 10, 2006

      Requirements for Accounting, Authentication and Authorization in
                    Well Managed IP Multicasting Services

  Status of this Memo
     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of BCP 79.

     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-

     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

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

     This Internet-Draft will expire on June 18, July 14, 2006.

  Copyright Notice

     Copyright (C) The Internet Society (2005) (2006)


     This memo presents requirements in the area of accounting and
     access control for multicasting.  General requirements for
     accounting capabilities including quality-of-service (QoS) related
     issues are listed.  This I-D assumes that these capabilities can be
     realized by functions implemented at edges of a network based on
     IGMP or MLD.  Finally, cases for Content Delivery Services
     (CDS) are described as application examples which could benefit
     from multicasting accounting and access control capabilities as
     described in the I-D.  It is proposed that this I-D be used as a
     starting point for further discussion on these issues.

                              Table of contents

     Copyright Notice.................................................1
     1. Introduction..................................................2
     2. Definitions and Abbreviations.................................4
     2.1 Definitions..................................................4
     2.2 Abbreviations................................................4
     3. Problem statement.............................................5 statement.............................................4
     3.1  Accounting issues...........................................5
     3.2  Relationship with secure multicasting (MSEC)................6
     4. General AAA-related functional requirements for well managed IP
     5. Application example and its specific requirements............10
     5.1 IP Multicast-based Content Delivery Service (CDS): CP and
         NSP are different entities (companies)......................10
     5.1.1 Network model for Multicast Content Delivery Service......10
     5.1.2 Content Delivery Service Requirements.....................12 Accounting Requirements.................................12 Authorization Requirements..............................13 Authentication Requirements.............................13
     5.2 IP Multicast-based Content Delivery Service (CDS): CP and
         NSP are the same entities (companies).......................14
     6. Acknowledgements.............................................15
     7. IANA considerations..........................................15
     8. Security considerations......................................15
     9. Conclusion...................................................15
     Normative References............................................15
     Authors' Addresses..............................................15
     Full Copyright Statement........................................17
     Intellectual Property...........................................17

  1. Introduction

     The intention of this memo is to define

     This I-D will present general functional requirements related to
     accounting, authentication and authorization issues for "well-
     managed in IP multicasting" services ("well-managed" defined at
     multicasting networks. A multicast network which fulfills all of
     these requirements will be called a "fully AAA enabled" IP
     multicasting network. Fulfillment of all or some of the
     requirements will make possible more robust management of this introduction). IP
     multicasting networks, and as such these capabilities contribute to
     the provision of well-managed IP multicasting services.

     IP multicasting is becoming widely used as a method to save network
     resources such as bandwidth or CPU processing power of the sender's
     server for cases where a large volume of information needs to be
     distributed to a large number of receivers.  This trend can be
     observed both in enterprise use and in broadband services provided
     by network operator/service providers.

     Distance learning within a university and in-house (in-company)
     sharing of multimedia information are examples of enterprise use.
     In these examples, sources generate high-bit rate (e.g., 6Mbit/s)
     streaming information.  When the number of receivers becomes large,
     such systems do not scale well without multicasting.

     On the other hand, a Content Delivery Service (CDS) is an example
     of a broadband service provided by network operators/service
     providers.  Distribution of movies and other video programs to each
     user are typical services.  Each channel requires large bandwidth
     (e.g., 6Mbit/s) and operator/service providers need to provide many
     channels to make their service attractive.  In addition, the number
     of receivers is large (e.g., more than a few thousands).  The
     system to provide this service does not scale well without

     As such, multicasting can be useful to make the network more
     scalable when a large volume of information needs to be distributed
     to a large number of receivers.  However, multicasting according to
     current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks
     compared to unicasting when one applies it to commercial services.
     Accounting of each user's actions is not possible with multicasting
     as it is with unicasting.  Accounting consists of grasping each
     user's behavior, when she/he starts/stops to receive a channel,
     which channel she/he receives, etc.

     IP multicasting can be used to distribute free material efficiently,
     but there are limitations to multicasting in usage models where
     usage accounting is necessary, such as many commercial applications.
     These limitations have prevented the widespread deployment of
     multicasting.  Alternatively, one could develop and use a
     proprietary solution to address this issue.  However, non-standard
     solutions have drawbacks in terms of interoperability or cost of
     development and maintenance.

     Without accounting capability in multicasting, information
     providers desiring accounting capability are forced to use
     unicasting even when multicasting would otherwise be desirable from
     a bandwidth/server resource perspective.  If multicasting could be
     used with user-based accounting capabilities, its applicability
     would be greatly widened.

     This I-D first describes problems on accounting issues in
     multicasting.  Then the general requirements for this capability
     including QoS related issues are listed.  Finally, application
     examples which could benefit from multicasting with accounting
     capabilities are shown.  It is proposed that this I-D be used as a
     starting point for a discussion on these issues.

     This I-D will present general functional requirements related to
     accounting, authentication and authorization issues in IP
     multicasting networks, and a multicast network which fulfills these
     requirements will be called a "well managed" IP multicasting

  2. Definitions and Abbreviations

  2.1 Definitions

     Authentication: action for identifying a user as a genuine one.

     Authorization: action for giving permission for a user to access
     content or the network.

     User-based accounting: actions for grasping each user's behavior,
     when she/he starts/stops to receive a channel, which channel she/he
     receives, etc.

  2.2 Abbreviations

     ASM: Any-Source Multicast

     CDS: Content Delivery Service

     CP: Content Provider

     IGMP: Internet Group Management Protocol

     MLD: Multicast Listener Discovery

     NSP: Network Service Provider

     SSM: Single-Source Multicast

     QoS: Quality of Service

  3. Problem statement
  3.1  Accounting issues

     In unicast communications, the server (information source) can
     identify the client (information receiver) and only permits
     connection by an eligible client when this type of access control
     is necessary.  In addition, when necessary, the server can grasp
     what the client is doing (e.g., connecting to the server, starting
     reception, what information the client is receiving, terminating
     reception, disconnecting from the server).

     On the other hand, in multicast communication with current
     standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its
     information to the multicast router [as in Fig.1].  Then, the
     multicast router replicates the data to any link which has at least
     one client requesting the information.    In this process, no
     eligibility check is conducted.  Any client can receive information
     just by requesting it.  In other words, the current standards do
     not provide multicasting with authorization or access control
     capabilities sufficient to meet the requirements of accounting.

       | user   |\
       +--------+ \
                   \+------+    +------+    +------+    +------+
       +--------+   |Multi-|    |Multi-|    |Multi-|    |      |
       | user   |---|cast  |----|cast  |----|cast  |----|Server|
       +--------+   |router|    |router|    |router|    |      |
                   /+------+    +------+    +------+    +------+
       +--------+ /
       | user   |/

              Fig.1 Example network for multicast communication

     This is the major reason why multicasting is only used for cases
     where no user-based accounting capabilities are necessary.  However,
     since more and more information is transferred over IP-based
     networks and some of these applications may require accounting
     capabilities, it is easy to envision the requirement of supporting
     such cases.  For example, accounting is needed if one wants to
     charge for distributed information on a non-flat-fee basis.  If the
     volume of information and number of clients are large, it is
     beneficial to use multicasting for purposes of network resource

     As such, the same level of user-based accounting capabilities as
     provided in unicast networks should be provided in multicast

  3.2  Relationship with secure multicasting (MSEC)

     In many cases, content encryption (e.g. MSEC) is an effective
     method for preventing unauthorized access to original content (in
     other words, the ability to decode data to return it to its
     generally useable form.)  This I-D presents requirements for
     multicasting networks in the areas of 1) access control to prevent
     unauthorized access to the network, and 2) accounting to grasp user
     activity.  The functional requirements do not require content
     encryption although it might solve some of the related problems.
     At this point, it is not yet clear whether encryption would be part
     of a solution and if so, what other components (if any) would also
     be required.

  4. General AAA-related functional requirements for well managed IP multicasting

     In consideration of the issues presented in section 3, the
     following requirements have been derived:

     (1) User identification

     The network should be able to identify each user when they attempt
     to access the service so that necessary access controlling actions
     can be applied.  Also, it is necessary to identify the source
     (user) of each request (e.g., join/leave) for user accounting

     With current protocols (IGMP/MLD), the sender cannot distinguish
     which receivers (end hosts) are actually receiving the information.
     The sender must rely on the information from the multicasting
     routers. This can be complicated if the sender and routers are
     maintained by different entities.

     (2) Issue of network resource protection

     In order to guarantee certain QoS it is important for network
     providers to be able to protect their network resources from being
     wasted, (either maliciously or accidentally).

     For comparisons sake, in the case of unicast this issue can be
     resolved e.g. by using RSVP.

     (2.1) Access control
     The network should be able to apply necessary access controlling
     actions when an eligible user requests.  The network should be able
     to reject any action requested from an ineligible user.

     (2.2) Control mechanism to support bandwidth of multicast stream
          from a physical port of edge router or switch

     The network may need to control the combined bandwidth for all
     groups both at the physical port of the edge router or switch so that
     these given physical entities are not overflowed with traffic.

     (2.3) Control mechanism of number of groups delivered from a
          physical port of edge router and switch

     If an NSP desires to guarantee a certain level of QoS to CP and the
     receivers, it is necessary that the NSP be able to control the
     number of groups delivered from a physical port of an edge router
     and a switch so that the combined bandwidth between content servers
     and multicast routers can be within the limit.

     For comparisons sake, in the case of unicast this issue can be
     resolved e.g. by using RSVP.

     (3) User authentication

     The network should be able to authenticate a user.

     (4) User authorization

     The network, at its option, should be able to authorize a user's
     access to content or a multicast group, so as to meet any demands
     by a CP to prevent content access by ineligible users.  In the case
     that the NSP may wish to provide a service based on guaranteed
     delivery, the NSP would not want to waste its network resources on
     ineligible users.  Eligibility can be defined in several ways.  The
     definition of an "eligible user" should be discussed further.

     (5) Accounting and billing

     In many commercial multicast situations, NSPs would like to be able
     to precisely grasp network resource consumption and CPs would like
     to be able to precisely grasp the content consumption by end-users.
     Such information might be used for identifying highly viewed
     content for advertising revenue, ratings calculations, programming
     decisions, etc., as well as billing and auditing purposes. Also
     content and network providers may wish to provide users with access
     to their usage history.

     To assemble such an understanding of end-user behavior, it is
     necessary to precisely log information such as who (host/user) is
     accessing what content at what time (join action) until what time
     (leave action).  The result of the access-control decision (e.g.
     results of authorization) would also be valuable information.  The
     desired degree of logging precisions would depend on the
     application used.

     (5.1) How to share user information

     For commercial multicast applications it is important for NSP and
     CP to be able to share information regarding user's behaviour (as
     described in (5) in standardized ways.

     (6) Notification to users of the result of the join request

     It should be possible to provide information to the user about the
     status of his/her join request(granted/denied/other).

     (7) Service and terminal portability

     Depending on the service, networks should allow for a user to
     receive a service from different places and/or with a different
     terminal device.

     (8) Support of ASM and SSM

     Both ASM (G), and SSM (S,G) should be supported as multicast models.

     (9) Admission control for join action

     In order to maintain a predefined QoS level, depending on the NSP's
     policy, an edge router should be able to control the number of
     streams it serves to a user, and total bandwidth consumed to that
     user. For example if the number of streams being served to a
     certain user has reached the limit defined by the NSP's policy,
     then the edge router should not accept a subsequent "join" until
     one of the existing streams is terminated.  Similarly, if the NSP
     is controlling by per-user bandwidth consumption, then a subsequent
     "join" should not be accepted if delivery of the requested stream
     would push the consumed bandwidth over the NSP policy-defined limit.

     (10)  Channel Join Latency and Leave Latency

     Commercial implementations of IP multicasting are likely to have
     strict requirements in terms of user experience.  Join latency is
     the time between when a user sends a "join" request and when the
     requested data streaming first reaches the user.  Leave latency is
     the time between when a user sends a "leave" signal and when the
     network stops streaming to the user.

     Leave and Join latencies impact the acceptable end-user experience
     for fast channel surfing. In an IP-TV application, users are not
     going to be receptive to a slow response time when changing
     channels.  If there are policies for controlling the number of
     simultaneous streams a user may access then channel surfing will be
     determined by the join and leave latencies.

     Furthermore, leave affects resource consumption:  with a low "leave
     latency" network providers could minimize streaming content when
     there are no audiences.

     It is important that any overhead for authentication, authorization,
     and access-control be minimized at the times of joining and leaving
     multicast groups so as to achieve join and leave latencies
     acceptable in terms of user experience. For example this is
     important in an IP-TV application, because users are not going to
     be receptive to a slow response time when changing channels.

     (11)  Scalability

     Solutions that are used for well managed IP multicasting should
     scale enough to support the needs of content providers and network

     (12) Small impact on the existing products

     Impact on the existing products (e.g., protocols, software, etc.)
     should be as minimal as possible.

     Ideally the NSP should be able to use the same infrastructure (such
     as access control) to support commercial multicast services for the
     so called "triple play" services: voice (VoIP), video, and
     broadband Internet access services.

     (13) Deployable as alternative to Unicast

     IP Multicasting would ideally be available as an alternative to IP
     unicasting when the "on-demand" nature of unicasting is not
     required. Therefore interfaces to multicasting should allow for
     easy integration into CDS systems that support unicasting.
     Especially equivalent interfaces for authorization, access control
     and accounting capabilities should be provided.

     (14) Multicast replication

     The above requirements should also apply if multicast replication
     is being done on an access-node (e.g. DSLAMs or OLTs).

     Specific functional requirements for each application can be
     derived from the above general requirements.  An example is shown
     in the section 5.

  5. Application example and its specific requirements

     This section shows an application example which could benefit from
     multicasting.  Then, specific functional requirements related to
     user-based accounting capabilities are derived.

  5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are
     different entities (companies)

     Broadband access networks such as ADSL (Asymmetric Digital
     Subscriber Line) or FTTH (Fiber to the Home) have been deployed
     widely in recent years. Content Delivery Service (CDS) is expected
     to be a major application provided through broadband access
     networks. Because many services such as television broadcasting
     require huge bandwidth (e.g., 6Mbit/s) and processing power at
     content server, IP multicast is used as an efficient delivery
     mechanism for CDS.

     One way to provide high quality CDS is to use closed networks
     ("walled-garden" model).

     This subsection shows an example where CP and NSP are different
     entities (companies).

  5.1.1 Network model for Multicast Content Delivery Service

     As shown in Fig.2, networks for CDS contain three different types
     of entities: Content Provider (CP), Network Service Provider (NSP),
     and end user clients. An NSP owns the network resources
     (infrastructure). It accommodates content providers on one side and
     accommodates end user clients on the other side. NSP provides the
     network for CDS to two other entities (i.e., CPs and end user
     clients). A CP provides content to each end-user client through the
     network of NSPs. NSPs are responsible for delivering the content to
     end user clients, and for controlling the network resources.

       +-------------+  +-------------+  +-------------+
       | CP          |  | CP          |  | CP          |
       |          #1 |  |          #2 |  |          #3 |
       | +---------+ |  | +---------+ |  | +---------+ |
       | | content | |  | | content | |  | | content | |
       | | server  | |  | | server  | |  | | server  | |
       | +-------+-+ |  | +----+----+ |  | +-+-------+ |
       +----------\--+  +------|------+  +--/----------+
                   \           |           /
                    \          |          / <- network/network
                     \         |         /     interface
       +------------- \ ------ | ------ / ----+
       |               \       |       /      |
       |   NSP         +-+-----+-----+-+      |
       |               | Provider Edge |      |
       |               +-------+-------+      |   +-----------------+
       |                       |              |---| Information     |
       |                       |              |   | server          |
       |             +--+------+---+          |   +-----------------+
       |             | User Edge   |          |
       |             +--+---+---+--+          |
       |               /    |    \            |
       +------------- / --- | --- \ ----------+
                     /      |      \
                    /       |       \ <- user/network interface
                   /        |        \
        +---------++  +-----+----+   ++---------+
        |client #a |  |client #b |   |client #c |
        +----------+  +----------+   +----------+
        End user A    End user B     End user C

                 Fig.2 Example of CDS network configuration

     The NSP provides the information server for all multicast channels,
     and a CP gives detailed channel information (e.g., Time table of
     each channel) to the information server. An end-user client gets
     the information from the information server. In this model,
     multicast is used in the NSP's CDS network, and there are two
     different contracts. One is the contract between the NSP and the
     end user which permits the user to access the basic network
     resources of the NSP.  Another contract is between the CP and end
     user to permit the user to subscribe to multicast content. Because
     the CP and NSP are different entities, and the NSP generally does
     not allow a CP to control (operate) the network resources of the
     NSP, user authorization needs to be done by the CP and NSP
     independently. Since there is no direct connection to the
     user/network interface, the CP cannot control the user/network
     interface. An end user may want to move to another place, or may
     want to change her/his device (client) anytime without interrupting
     her/his reception of services.  As such, IP Multicast network
     should support portability capabilities.

  5.1.2 Content Delivery Service Requirements

     To have a successful business providing multicast, there are some
     specific requirements for the IP Multicast-based Content Delivery
     Service. Accounting Requirements

     Since the CP and NSP are different business entities, they need to
     share the revenue. Such a revenue sharing business relationship
     requires accurate and near real-time accounting information about
     the end user clients' activity on accessing the content services.
     The accounting information should be per content/usage-base to
     enable varied billing and charging methods.

     The user accessing particular content is represented by the user's
     activities of joining or leaving the corresponding multicast
     group/channel (<g> or <s,g>). In multicast networks, only NSPs can
     collect group joining or leaving activities in real-time through
     their last-hop multicast access edge devices. The NSPs can transfer
     the accounting information to related CPs for them to generate end
     user billing information. The normal AAA technology can be used to
     transfer the accounting information.

     To match the accounting information with a particular end-user
     client, the end-user client has to be authenticated. Usually the
     account information of an end-user client for content access is
     maintained by the CP. An end user client may have different user
     accounts for different CPs. The account is usually in the format of
     (username, password) so an end user client can access the content
     services from anywhere. For example, an end user client can access
     the CP from different NSPs. It should be noted that the user
     account used for content access can be different from the one used
     for network access maintained by NSPs.

     The NSP-CP model represents a multi-domain AAA environment. There
     are plural cases of the model depending on the trust relationship
     between the NSP and CP, and additional service requirements such as
     a certain QoS level guarantee or service/terminal portability.

     A mechanism is necessary to allow a CP and NSP to grasp each user's
     behavior independently.

     Another requirement related to accounting is the ability to notify
     a user when accounting really starts.  When a "free preview"
     capability is supported, accounting may not start at the same time
     as the user's joining of the stream. Authorization Requirements

    The NSPs are responsible for delivering content and are required to
    meet certain QoS levels or SLA (service level agreements). For
    example, video quality is very sensitive to packet loss. So if an
    NSP cannot meet the quality requirements due to limited network
    resources if it accepts an additional user request, the NSP should
    reject that end user's access request to avoid charging the
    existing (i.e., already joined) user for bad services.  For example,
    if an access line is shared by several users, an additional user's
    join may cause performance degradation for other users.  If the
    incoming user is the first user on an edge node, this will initiate
    the transmission of data between the multicast router and the edge
    node and this extra network traffic may cause performance
    degradation.  There may also be policies that do not necessarily
    give highest priority to the "first-come" users, and these should
    also be considered.

    In order to protect network resources against misuse/malicious
    access and maintain a QoS level, appropriate admission control
    function for traffic policing purposes is necessary so that the NSP
    can accept or reject the request without degrading the QoS beyond
    the specified level. Authentication Requirements

     There are two different aims of authentication.  One is
     authentication for network access, and another one is for content
     access. For the first case of authentication, NSP has a AAA server,
     and for the second case, each CP has a AAA server. In some cases,
     CPs delegate (outsource) the operation of user authentication to

     As such, in addition to network access, multicast group access by a
     user also needs to be authenticated.  Content authentication should
     support the models where:
          - authentication for multicast content is outsourced to the

          - authentication for multicast content access is operated by
            the content provider

  5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are
     the same entities (companies)

     Another application example is the case where the content provider
     (CP) and network service provider (NSP) are the same entity
     (company) as shown in Fig. 3.  In the case that the CP and NSP are
     the same entity, some of the requirements indicated in 4.1 are not

     This model does not require the following items:

          - Communication method between sender (server) and user (end
            host).  Since they belong to the same company, they can use
            all the available information.

          - Methods to share user-related information between network
            providers and content providers.
       |              +---------+                            |
       |              | content |                            |
       |              | server  |                            |
       |              +----+----+                            |
       |                   |                                 |
       | CP+NSP    +-------+-------+                         |
       |           | Provider Edge |                         |
       |           +-------+-------+  +--------------------+ |
       |                   |          | Information server | |
       |                   |          +--------------------+ |
       |           +-------------+                           |
       |           | User Edge   |                           |
       |           +--+---+---+--+                           |
       |             /    |    \                             |
       +----------- / --- | --- \ ---------------------------+
                   /      |      \
                  /       |       \ <- user/network interface
                 /        |        \
      +---------++  +-----+----+   ++---------+
      |user #a   |  |user #b   |   |user #c   |
      +----------+  +----------+   +----------+
        End user A    End user B     End user C

                 Fig.3 Example of CDS network configuration
  6. Acknowledgements

     The authors of this draft would like to express their appreciation
     to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert
     of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper,
     Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T-
     Systems, as well as the participants of the MBONED WG in general.

     Funding for the RFC Editor function is currently provided by the
     Internet Society.

  7. IANA considerations

     This I-D does not raise any IANA consideration issues.

  8. Security considerations

     Accounting capabilities can be used to enhance the security of
     multicast networks by excluding ineligible clients from the

  9. Conclusion

     This I-D describes general requirements for providing "well
     managed" IP multicasting services. It lists issues related to
     accounting, authentication, authorization and admission control for
     multicast content delivery, with the goal of finding a solution
     implemented at edges of the network based on IGMP or MLD. delivery.  Content Delivery Services with
     different business models is cited as an application which could
     benefit from the capabilities of "well managed" IP multicasting
     described in this document.
     It is proposed that this document be used as a starting point for
     discussing requirements for "well managed" IP multicasting services.

  Normative References

     [1] B. Cain, et. al., "Internet Group Management Protocol, Version
         3", RFC3376, October 2002.

     [2] R. Vida, et. al., "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC3810, June 2004.

  Authors' Addresses

             Tsunemasa Hayashi
             NTT Network Innovation Laboratories
             1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
             Phone: +81 46 859 8790
             Email: hayashi.tsunemasa@lab.ntt.co.jp

             Haixiang He
             600 Technology Park Drive Billerica, MA 01801, USA
             Phone: +1 978 288 7482
             Email: haixiang@nortel.com

             Hiroaki Satou
             NTT Network Service Systems Laboratories
             3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
             Phone: +81 422 59 4683
             Email: satou.hiroaki@lab.ntt.co.jp

             Hiroshi Ohta
             NTT Network Service Systems Laboratories
             3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
             Phone: +81 422 59 3617
             Email: ohta.hiroshi@lab.ntt.co.jp

             Susheela Vaidya
             Cisco Systems, Inc.
             170 W. Tasman Drive San Jose, CA 95134
             Phone: +1 408 525 1952
             Email: svaidya@cisco.com
  Full Copyright Statement

     Copyright (C) The Internet Society (2005). (2006).

     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

  Intellectual Property

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights 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; nor does it
     represent that it has made any independent effort to identify any
     such rights.  Information on the IETF's procedures with respect to
     rights in IETF Documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard.  Please address the information to the IETF at ietf


     Funding for the RFC Editor function is currently provided by the
     Internet Society.