[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-takeda-l1vpn-applicability-enhanced-mode) 00

Network Working Group
Internet Draft                                 Tomonori Takeda (Editor)
Proposed Status: Informational                                      NTT
Expires: May 2007                                         November 2006


    Applicability analysis of Generalized Multiprotocol Label Switching
     (GMPLS) protocols for the Layer 1 Virtual Private Network (L1VPN)
                               Enhanced Mode

            draft-ietf-l1vpn-applicability-enhanced-mode-00.txt


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-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document provides an applicability analysis on the use of
   Generalized Multiprotocol Label Switching (GMPLS) protocols and
   mechanisms to satisfy the requirements of the Layer 1 Virtual Private
   Network (L1VPN) Enhanced Mode.

   L1VPNs provide customer services and connectivity at layer 1 over
   layer 1 networks. The operation of L1VPNs is divided into the Basic
   Mode and the Enhanced Mode, where the Enhanced Mode of operation
   features exchange of routing information between the layer 1 network
   and the customer domain.




T.Takeda, et al.           Expires May 2007                   [Page 1]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   In addition, this document identifies areas where additional protocol
   extensions or procedures are needed to satisfy the requirements of
   the L1VPN Enhanced Mode, and provides guidelines for potential
   extensions.

Table of Contents

   1. Contributors...................................................2
   2. Terminology....................................................3
   3. Introduction...................................................3
   3.1 Work Items....................................................3
   3.2 Existing Solutions Drafts.....................................4
   4. General Guidelines.............................................4
   5. Overlay Extension Service Model................................5
   5.1 Overview of the Service Model.................................5
   5.2 Applicability of Existing Solutions...........................6
   5.3 Additional Work Area(s).......................................6
   6. Virtual Node Service Model.....................................6
   6.1 Overview of the Service Model.................................6
   6.2 Applicability of Existing Solutions...........................6
   6.3 Additional Work Area(s).......................................7
   7. Virtual Link Service Model.....................................7
   7.1 Overview of the Service Model.................................7
   7.2 Applicability of Existing Solutions...........................7
   7.3 Additional Work Area(s).......................................7
   8. Per-VPN Peer Service Model.....................................8
   8.1 Overview of the Service Model.................................8
   8.2 Applicability of Existing Solutions...........................8
   8.3 Additional Work Area(s).......................................8
   9. Discussion.....................................................9
   10. Manageability Considerations..................................9
   11. Security Considerations......................................10
   12. References...................................................10
   12.1 Normative References........................................10
   12.2 Informative References......................................10
   13. Acknowledgments..............................................12
   14. Author's Addresses...........................................12
   15. Intellectual Property Consideration..........................13
   16. Full Copyright Statement.....................................13

1. Contributors

   The details of this document are the result of contributions from
   several authors who are listed here in alphabetic order. Contact
   details for these authors can be found in a separate section near the
   end of this document.

   Deborah Brungard (AT&T)
   Adrian Farrel (Old Dog Consulting)


T.Takeda, et al.           Expires May 2007                   [Page 2]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   Hamid Ould-Brahim (Nortel Networks)
   Dimitri Papadimitriou (Alcatel)
   Tomonori Takeda (NTT)

2. Terminology

   The reader is assumed to be familiar with the terminology in
   [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026] and
   [L1VPN-FW].

3. Introduction

   This document shows the applicability of existing Generalized
   Multiprotocol Label Switching (GMPLS) protocols and mechanisms to the
   Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. In addition,
   this document identifies several areas where additional protocol
   extensions or modifications are needed to meet the L1VPN Enhanced
   Mode service requirements set out in [L1VPN-FW].

   In particular, this document shows section by section (from Section 5
   to 8) the applicability of GMPLS protocols and mechanisms to each
   sub-model of the Enhanced Mode mentioned in [L1VPN-FW], along with
   additional work areas needed to fully support the requirements for
   each sub-model.

   Note that discussion in this document is limited to areas where GMPLS
   protocols and mechanisms are relevant.

   As will be described in this document, support of the Overlay
   Extension service model and the Virtual Node service model are well
   covered by existing protocol mechanisms already described in other
   documents, with only minor protocol extensions required. The Virtual
   Link service model and the Per-VPN Peer service model are not
   explicitly covered by existing documents, but can be realized by
   extending current GMPLS protocols and mechanisms as described in this
   document.

   The following section lists areas where additional work may be
   required to fully support the requirements for each sub-model. Some
   of the requirements are optional, therefore the additional work is
   also optional.

   Commonalities of mechanisms over various sub-models, as well as over
   the L1VPN Basic Mode need to be considered. Also, various mechanisms
   should be coordinated in such a way that services are provided in a
   fully functional manner.

3.1 Work Items



T.Takeda, et al.           Expires May 2007                   [Page 3]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   This list of additional work areas is a summary derived from the main
   body of this document. The list will be updated in later versions of
   this document along with the development of the additional or
   enhanced requirements and increased understanding of the issues. As
   work progresses on protocol extensions, this list will be updated to
   remove completed items, and the body of this document will be updated
   to describe the analysis of protocol extensions. The intention is
   that this whole section is removed when the work has been completed
   and this document progresses to become an RFC.

   o Routing representation (how a VPN should be represented in routing,
     e.g., single area, multi-area, multi-AS). See Sections 6.3 and 7.3.
   o Signaling and routing for support of the Per-VPN Peer service
     model. See Section 8.3.

3.2 Existing Solutions Drafts

   This section lists existing solution documents that describe how the
   L1VPN Enhanced Mode may be constructed using the mechanisms of GMPLS.
   This document draws on those solutions and explains their
   applicability and suggests further extensions to make the solutions
   more closely match the framework described in [L1VPN-FW]. Further
   solution documents may be listed in a future version of this
   document.

   o [GVPN] describes a suite of port-based Provider-provisioned VPN
     services called Generalized VPNs (GVPNs) that use BGP for VPN
     auto-discovery and GMPLS as a signaling mechanism.

   o [L1VPN-BM] addresses the L1VPN Basic Mode signaling.

   Note that although [L1VPN-BM] specifies signaling mechanisms for
   L1VPN Basic Mode, it is applicable to the L1VPN Enhanced Mode, unless
   otherwise specified. Therefore, main focus of this document is how to
   realize routing related information exchange between a CE and a PE.

4. General Guidelines

   This section provides general guidelines for L1VPN solutions. Note
   that applicability to specific sub-models will be separately
   described in following sections.

   One important general guideline is that protocol mechanisms should be
   re-used where possible. This means that solutions should be
   incremental, building on existing protocol mechanisms rather than
   developing wholly new protocols. Further, as service models are
   extended or developed resulting in the requirement for additional
   functionalities, deltas should be added to the protocol mechanisms
   rather than developing new techniques. [L1VPN-FW] describes how the


T.Takeda, et al.           Expires May 2007                   [Page 4]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   service models can be seen to provide "cascaded" functionality, and
   this should be leveraged to achieve re-use of protocol extensions so
   that, for example, it is highly desirable that the same signaling
   protocols and extensions are used in both the Basic Mode and the
   Enhanced Mode.

   In addition, the following are general guidelines.

   - The support of L1VPNs should not necessitate any change to core (P)
     devices. Therefore, any protocol extensions made to facilitate
     L1VPNs need to be made in a backward compatible way allowing GMPLS
     aware P devices to continue to function.
   - Customer (C) devices not directly involved in providing L1VPN
     services should also be protected from protocol extensions made to
     support L1VPNs. Again, such protocol extensions need to be backward
     compatible. Note however, that some L1VPN service models allow for
     VPN connectivity between C devices rather than between CE devices:
     in this case, the C devices may need to be aware of protocol
     extensions.
   - Solutions should aim to minimize the protocol extensions on CE
     devices.
   - Solutions should be scalable and manageable. Solutions should not
     require L1VPN state to be maintained on the P devices as much as
     possible.
   - Solutions should be secure. Providers should be able to screen and
     protect information based on their operational policies.
   - Solutions should provide an operational view of the L1VPN for the
     customer and provider. There should be a common operational and
     management perspective in regard to other (L2 and L3) VPN services.

5. Overlay Extension Service Model

5.1 Overview of the Service Model

   This service model complements the Basic Mode and may assume all of
   the requirements, solutions and work items for that model.

   In this service model, a CE receives from its attached PEs a list of
   TE link addresses to which it can request a VPN connection (i.e.,
   membership information).

   The CE may also receive some TE information concerning these CE-PE
   links within the VPN (e.g., switching type).

   The CE does not receive any of the following from the PE.

   - Routing information about the core provider network.
   - Information about P device addresses.
   - Information about P-P, PE-P or PE-PE TE links.


T.Takeda, et al.           Expires May 2007                   [Page 5]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   - Routing information about other customer sites. The CE may have
     access to routing information about the remainder of the VPN (C-C
     and CE-C links), but this is exchanged by control plane tunneling
     on the CE-CE connections and is not passed to the CE in the control
     plane exchange between PE and CE.

5.2 Applicability of Existing Solutions

   The following are required in this service model (in addition to
   requirements in the L1VPN Basic Mode).

   - VPN membership information exchange between a CE and PE.
   - CE-PE TE link information exchange between a CE and a PE.

   [GVPN] covers the requirement to exchange membership information
   between the CE and the PE based on BGP. Furthermore, [BGP-TE] allows
   the exchange of CE-PE TE link information between a CE and a PE.

5.3 Additional Work Area(s)

   None.

6. Virtual Node Service Model

6.1 Overview of the Service Model

   In this service model, there is a private routing exchange between
   the CE and the PE, or to be more precise between the CE routing
   protocol instance and the VPN routing protocol instance running on
   the PE. The provider network is considered as one private node from
   the customer's perspective. The routing information exchanged between
   the CE and the PE includes CE-PE TE link information, customer
   network (i.e., remote CE sites), and may include TE links (Forwarding
   Adjacencies) connecting CEs (or Cs) across the provider network as
   well as control plane topology information from the customer network
   (i.e., CE sites).

6.2 Applicability of Existing Solutions

   The following are required in this service model.

   - VPN routing
   - Signaling: CE-CE Label Switching Path (LSP) setup, deletion, and
     modification

   [GVPN] covers most of the requirements.

   Specifically, [GVPN] handles VPN routing by a per VPN database called
   the GVSI (Generalized Virtual Switching Instance) held in each PE.


T.Takeda, et al.           Expires May 2007                   [Page 6]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   GVSIs are inter-connected by tunnel-based control channels, and
   routing adjacencies are established between them. BGP is used for
   auto-discovery of remote GVSIs (VPN auto-discovery) in the same VPN.
   GVSIs advertise VPN routing information by using a single ROUTER_ID
   to represent the provider network as one node.

   It is also possible to use IGP-based auto-discovery (based on [L1VPN-
   OSPF-DISC]), instead of BGP-based auto-discovery.

   Signaling mechanisms are covered by [L1VPN-BM].

6.3 Additional Work Area(s)

   o Routing Representation

     [GVPN] allows flexible routing configuration for each VPN (e.g.,
     single IGP area, multiple IGP areas, or multiple ASes).

     However, it may be valuable to consider how to represent a VPN in
     routing. This may simplify the solution (e.g., in terms of
     scalability). This requires further discussion.

7. Virtual Link Service Model

7.1 Overview of the Service Model

   In this service model, virtual links are established between PEs. A
   virtual link is assigned to each VPN and disclosed to the
   corresponding CEs. The routing information exchanged between the CE
   and the PE includes CE-PE TE links, customer network (i.e., remote CE
   sites), virtual links (i.e., PE-PE links) assigned to each VPN, and
   may include CE-CE (or C-C) Forwarding Adjacencies as well as control
   plane topology from the customer network (i.e., CE sites).

7.2 Applicability of Existing Solutions

   Currently, there is no solution document for this type of service
   model.

7.3 Additional Work Area(s)

   Simple modifications of [GVPN], in addition to enhancements mentioned
   in Section 6.3, may realize this type of service model. Modifications
   could be:

   - Do NOT modify the ROUTER_ID of the TE link information when
     advertising a CE-PE TE link to the CE (in the OSPF packet header as
     well as in the LSA header).



T.Takeda, et al.           Expires May 2007                   [Page 7]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   - Set up Forwarding Adjacency LSPs (FA-LSPs, GVSI-LSPs in [GVPN]
     terms) between PEs to construct virtual links, and advertise these
     FAs in VPN routing. Note these FAs (virtual links) may be assigned
     private addresses, which means customer assigned addresses (or that
     customers are allowed to configure addresses). This may require
    extensions to current IGP behavior.

   There could be other ways to construct virtual links (e.g., virtual
   links without actually setting up an FA-LSP [MRN-REQ]).

   Resource management for a dedicated data plane is a mandatory
   requirement for the Virtual Link service model. This could be
   realized by assigning pre-configured FA-LSPs to each VPN routing
   protocol instance (no protocol extensions needed) in order to
   instantiate the necessary FAs.

   Note that as in the case of the Virtual Node service model, solution
   details may differ depending on the routing representation. This
   requires further discussion.

8. Per-VPN Peer Service Model

8.1 Overview of the Service Model

   In this service model, the provider partitions TE links within the
   provider network per VPN. The routing information exchanged between
   the CE and the PE includes CE-PE TE links, customer network (i.e.,
   remote CE sites), as well as partitioned portions of the provider
   network, and may include CE-CE (or C-C) Forwarding Adjacencies and
   control plane topology from customer network (i.e., CE sites). Note
   that PEs may abstract routing information about the provider network
   and advertise it to CEs.

   Note scalability must be carefully considered for advertising
   provider network routing information to the CE [INTER-DOMAIN-FW].

8.2 Applicability of Existing Solutions

   Currently, there is no solution document for this type of service
   model.

8.3 Additional Work Area(s)

   There are two approaches for this service model.

   o Signaling and routing for support of the per-VPN Peer service
     model

     Option1: Virtual Link based approach


T.Takeda, et al.           Expires May 2007                   [Page 8]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006



       The Per-VPN Peer service model may be realized by extending the
       virtual link technique so that not only PEs but also Ps that
       contain end points of virtual links in the abstracted topology
       contain VPN routing instances. There may be no additional
       protocol extensions needed from the Virtual Link service model.

     Option2: Virtual Node based approach

       The Per-VPN Peer service model may be realized by extending the
       virtual node technique so that PEs selectively advertise
       provider internal TE links to CEs. There are several extensions
       needed for this.

   Details are for further study.

9. Discussion

   This section summarizes items for which existing solutions may need
   to be extended in order to fulfill the full set of L1VPN Enhanced
   Mode functionalities.

   For the Overlay Extension service model and the Virtual Node service
   model, the existing solutions can be applied with few extensions.

   As described in Sections 7.2 and 8.2, there are no existing solutions
   to support the Virtual Link service model and the Per-VP Peer service
   model. For the Virtual Link service model, however, minor extensions
   from existing solutions are expected to meet the requirements.

   Note that the list of additional work areas will be updated in later
   versions of this document with the development of additional or
   enhanced requirements and further understanding of the issues.

   o Routing representation
     - One building block for the Enhanced Mode
     - Further discussion required (single area, multi areas, multi
       ASes, etc.)
     - Impact: Details to be studied (routing etc.)

   o Signaling and routing for support of the Per-VPN Peer service model
     - Details for further study

10. Manageability Considerations

   Section 11 of [L1VPN-FW] describes manageability considerations for
   L1VPNs.




T.Takeda, et al.           Expires May 2007                   [Page 9]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   This document defines a following new manageability requirement
   specific for the L1VPN Enhanced Mode.

   MIB modules MUST be available for any protocol extensions for the
   L1VPN Enhanced Mode.

   A future revision of this document may cover more aspects.

11. Security Considerations

   Section 12 of [L1VPN-FW] describes security considerations for
   L1VPNs. This document defines a following new security requirements
   specific for the L1VPN Enhanced Mode.

   In the L1VPN Enhanced Mode, since there is a routing adjacency
   between a CE and a PE, care must be taken whether the provider
   network's control plane topology information is leaked to the CE. Due
   to security concerns, this is not recommended in general, and there
   must be a mechanism to prevent such operation.

   A future revision of this document may cover more aspects.

12. References

12.1 Normative References

   [RFC3668]          Bradner, S., "Intellectual Property Rights in IETF
                      Technology", BCP 79, RFC 3668, February 2004.

   [L1VPN-FW]         Takeda, T., Editor "Framework and Requirements for
                      Layer 1 Virtual Private Networks", draft-ietf-
                      l1vpn-framework, work in progress.

12.2 Informative References

   For information on the availability of this document, please see
   http://www.itu.int.

   [Y.1312]           Y.1312 - Layer 1 Virtual Private Network Generic
                      requirements and architecture elements, ITU-T
                      Recommendation, September 2003.

   For information on the availability of this document, please see
   http://www.itu.int.

   [Y.1313]           Y.1313 - Layer 1 Virtual Private Network
                      service and network architectures, ITU-T
                      Recommendation, July 2004.



T.Takeda, et al.           Expires May 2007                  [Page 10]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   [RFC3031]          Rosen, E., Viswanathan, A. and R. Callon,
                      "Multiprotocol label switching Architecture", RFC
                      3031, January 2001.

   [RFC3209]          Awduche, D., Berger, L., Gan, D., Li, T.,
                      Srinivasan, V.  and G. Swallow, "RSVP-TE:
                      Extensions to RSVP for LSP Tunnels", RFC 3209,
                      December 2001.

   [RFC3471]          Berger, L., Editor, "Generalized Multi-Protocol
                      Label Switching (GMPLS) Signaling Functional
                      Description", RFC 3471, January 2003.

   [RFC3473]          Berger, L., Editor "Generalized Multi-Protocol
                      Label Switching (GMPLS) Signaling - Resource
                      ReserVation Protocol-Traffic Engineering (RSVP-TE)
                      Extensions", RFC 3473, January 2003.

   [RFC4202]          Kompella, K., et al., "Routing Extensions in
                      Support of Generalized Multi-Protocol Label
                      Switching (GMPLS)", RFC 4202, October 2005.

   [RFC4026]          Anderssion, L., and Madsen, T., "Provider
                      Provisioned Virtual Private Network (VPN)
                      Terminology", RFC 4026, March 2005.

   [GVPN]             Ould-Brahim, H., and Rekhter, Y. Editors, "GVPN
                      Services: Generalized VPN Services using BGP and
                      GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-
                      bgpgmpls, work in progress.

   [RFC4208]          Swallow, G., et al., "Generalize Multiprotocol
                      Label Switching(GMPLS) User-Network Interface:
                      Resource ReserVation Protocol-Traffic Engineering
                      (RSVP-TE) Support for the Overlay Model," RFC4208,
                      October 2005.

   [L1VPN-BM]         Fedyk, D., and Rekhter, Y., Editors, "Layer 1
                      VPN Basic Mode," draft-fedyk-l1vpn-basic-mode,
                      work in progress.

   [L1VPN-BGP-DISC]   Ould-Brahim, H., Fedyk, D., and Rekhter, Y.,
                      "BGP-based Auto-Discovery for L1VPNs," draft-ietf-
                      l1vpn-bgp-auto-discovery, work in progress.

   [L1VPN-OSPF-DISC]  Bryskin, I., and Berger, L., "OSPF Based L1VPN
                      Auto-Discovery," draft-ietf-l1vpn-ospf-auto-
                      discovery, work in progress.



T.Takeda, et al.           Expires May 2007                  [Page 11]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   [INTER-DOMAIN-FW]  Farrel, A., et al., "A Framework for Inter-Domain
                      MPLS Traffic Engineering", draft-ietf-ccamp-inter-
                      domain-framework, work in progress.

   [BGP-TE]           Ould-Brahim, H., Fedyk, D., and Rekhter, Y.,
                      "Traffic Engineering Attribute", draft-fedyk-bgp-
                      te-attribute, work in progress.

   [MRN-REQ]          Shiomoto, K., et al., "Requirements for GMPLS-
                      based multi-region and multi-layer networks
                      (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, work
                      in progress.

13. Acknowledgments

   Authors would like to thank Marco Carugi, Ichiro Inoue, and Takumi
   Ohba for valuable comments in the early development of this document.

14. Author's Addresses

   Deborah Brungard (AT&T)
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ 07748, USA
   Phone: +1 732 4201573
   Email: dbrungard@att.com

   Adrian Farrel
   Old Dog Consulting
   Phone:  +44 (0) 1978 860944
   Email:  adrian@olddog.co.uk

   Hamid Ould-Brahim
   Nortel Networks
   P O Box 3511 Station C
   Ottawa, ON K1Y 4H7 Canada
   Phone: +1 (613) 765 3418
   Email: hbrahim@nortel.com

   Dimitri Papadimitriou (Alcatel)
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 2408491
   Email: dimitri.papadimitriou@alcatel.be

   Tomonori Takeda
   NTT Network Service Systems Laboratories, NTT Corporation
   3-9-11, Midori-Cho
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 7434


T.Takeda, et al.           Expires May 2007                  [Page 12]


draft-ietf-l1vpn-applicability-enhanced-mode-00.txt      November 2006


   Email: takeda.tomonori@lab.ntt.co.jp

15. Intellectual Property Consideration

   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 procedures with respect to
   rights in RFC 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-ipr@ietf.org.

16. Full Copyright Statement

   Copyright (C) The IETF Trust (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 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.









T.Takeda, et al.           Expires May 2007                  [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/