Network working Working Group                               W. Imajuku (ed.) Imajuku, Ed., NTT
Internet-Draft                             T. Otani (ed.)                                          Otani, Ed., KDDI R&D Labs.
Category:
Intended status: Informational                    N. Bitar (ed.) Bitar, Ed., Verizon
Expires December 2008
Expires: June 11 13, 2009
                                                       December 10, 2008

     Service Provider Requirements for Ethernet control with GMPLS
            draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt
          draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.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.

   This Internet-Draft will expire on December 10, 2008. June 13, 2009.

Abstract

   Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
   Ethernet switches supporting Provider Backbone Bridge Traffic
   Engineering (PBB-TE) networks.  The GMPLS controlled Ethernet label
   switch network not only automates creation of Ethernet Label Switched
   Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
   Mechanisms such as protection and restoration of an Eth-LSP.  This
   document describes the requirements for the set of solutions of GMPLS
   controlled Ethernet label switch networks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2 .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3  4
   3.  Reference model  . . . . . . . . . . . . . . . . . . . . . . .  3  5
     3.1.  Single-layer network  Single Layer . . . . . . . . . . . . . . . . . . .  3 . . . .  5
     3.2.  Multi-layer network  Multi Layer  . . . . . . . . . . . . . . . . . . .  4 . . . .  5
   4.  Requirements for Ethernet layer control . . . . . . . . . . .  5 . . . . . . . . . . . . . .  7
     4.1.  Control plane architecture and functionality . . . . . .  5 .  7
       4.1.1.  In-band control plane channel  . . . . . . . . . . . . . .  5
     4.1.2 .  7
       4.1.2.  Neighbor discovery mechanism . . . . . . . . . . . . .  7
       4.1.3.  Addressing .  5 . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Ethernet LSP control . . . . . . . . . . . . . . . . . .  5 .  7
       4.2.1.  Prevention of Loops  . . . . . . . . . . . . . . . . . . .  5  7
       4.2.2.  Service Control . . control  . . . . . . . . . . . . . . . . . . .  6
     4.2.3  7
       4.2.3.  P2MP and MP2MP LSP requirements  . . . . . . . . . . . . .  8
       4.2.4.  Asymmetric bandwidth . . . . . .  6 . . . . . . . . . . .  8
       4.2.5.  QoS control  . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  OA&M related functionality . . . . . . . . . . . . . . .  6 .  8
     4.4.  Protection and restoration Related functionalities Restoration related functionality . . .  6 . .  8
     4.5.  Link Aggregation Group (LAG) related functionalities  . functionality . . . .  6
     4.5.1  9
       4.5.1.  Failure or deletion of LAG member link . . . . . . . . .  7
     4.5.2  9
       4.5.2.  Recovery or addition of LAG member link  . . . . . . . . .  7  9
     4.6.  Inter-domain Ethernet LSP  . . . . . . . . . . . . . . . .  7  9
     4.7.  Multi-layer network  . . . . . . . . . . . . . . . . . . .  7 10
       4.7.1.  Dynamic formation of LAG . . . . . . . . . . . . . . . .  7 10
       4.7.2.  Other requirements . . . . . . . . . . . . . . . . . . .  7
     4.8 10
     4.8.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  8 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8 13
   7.  References  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . .  8
     7.1.  Normative references . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative references . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . .  9
   9. . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 11
   Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . . 11 19

1.  Introduction

   Scalability and manageability of Ethernet switch networks has
   continuously improved, and the deployment of Ethernet switches
   supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the
   solutions for service providers to provide enterprise WAN/LAN
   services.  IEEE standardization activities of Provider Backbone
   Bridge(PBB)
   [IEEE 802.1ah] [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE)
   [IEEE802.1Qay] provide an opportunity not only for enhancing the
   scalability, manageability, and controllability of the Ethernet
   service networks, but also for more efficiently deploying access/metro access/
   metro access networks.

   Generalized Multi-Protocol Label Switching (GMPLS) provides the
   framework for handling and controlling various types of switching
   technologies, namely packet switching with various label formats TDM
   switching, and wavelength switching [RFC3945].  Therefore, the
   combined use of GMPLS and PBB-TE is a fairly suitable "use case" that
   contributes to enhancing the flexibility of Ethernet Label Switched
   Path (Eth-LSP) over Ethernet switch networks without defining
   additional connection layers.

   This document describes requirements for GMPLS protocols to control
   Ethernet label switch networks and comprises mainly two parts.  The
   first one is the requirements for GMPLS extension for controlling
   Ethernet layer.  The second one includes the requirements for GMPLS
   extensions to support multi-layer operation.  Although a large
   portion of requirements in the second scope coincides with the
   description in [Interwk-fwk] [RFC5145] and [Interwk-req], [RFC5146], some of important
   requirements are also described in this document.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Reference model

3.1

3.1.  Single Layer

   This document describes requirements based on the reference model
   depicted in Fig. 1. Fig.1.  The first reference model is an intra-domain and
   single layer GMPLS controlled Ethernet label switching network in
   which Eth-LSPs traverse over between Back Bone Core Bridges (BCBs) or
   Back Bone Edge Bridges (BEBs).

                                           --------
                                           |  LSR3  |__ P-based IF
                  --------      ----- _____|(IB-BEB)|__ S-tagged IF
   P-based IF    |  LSR1  |____|LSR2 |     |        |__ I-tagged IF
   S-tagged IF   |(IB-BEB)|    |(BCB)|      --------
   I-tagged IF   |        |    |     |_____ --------
                  --------      -----      |  LSR4  |
                                           | (B-BEB)|
                                           |        |__ I-tagged IF
                                            --------
                          |  GMPLS Eth-LSP |
                          |   (BVID/BMAC)  |
                          |<---------------|

   Figure 1 Single layer GMPLS controlled PBB-TE network

   The BEBs provide mainly three types of service interfaces, namely
   Port based service interface (P-based IF), S-tagged service interface
   (S-tagged IF), and I-tagged service Interface (I-tagged IF)
   [IEEE802.1ah].  The "P-based IF" and "S-tagged IF" are connected to
   the I-component of a BEB (I-BEB), while the I-tagged IF is connected
   to the B-component of a BEB (B-BEB).  "S-tagged IF" can perform
   various types of mapping between Service VLAN ID (S-VID) and Backbone
   instance Service Identifier (I-SID).  Here, S-VID is assigned within
   customer network domain or Provider Bridge (PB) domain.  On the other
   hand, I-SID is defined between I-components of BEBs.

3.2 Multi-layer

3.2.  Multi Layer

   The second reference model is Ethernet and L1 (such as TDM, OTN, etc)
   multi-layer network.  Each Ethernet switch node behaves as a border
   node between the Ethernet layer and optical Layers.  Each BCB or BEB
   terminates Optical Label Switched Path (O-LSPs) with Ethernet
   encoding type and some O-LSPs dynamically form LAG.  Thus, some Eth-LSPs Eth-
   LSPs traverse over multiple O-LSPs, while other Eth-LSPs traverse
   over single O-LSPs.

   Also, it is technically possible to form multiple layer Ethernet
   switch networks.  Namely, the reference model is defined as the case
   that Ethernet switch network substitutes L1 network in Fig.2, and
   realizes MAC in MAC Ethernet transport.  The routing information of
   optical layer may be isolated (overlay model), shuffled (peer model),
   or virtualized with FA-LSPs (augmented model) for Ethernet switch
   layer.

                  --------       ------       --------
   P-based IF  __|  LSR1  |     | LSR2 |     |  LSR3  |__ P-based IF
   S-tagged IF __|(IB-BEB)|     | (BCB)|     |(IB-BEB)|__ S-tagged IF
   I-tagged IF __|        |     |      |     |        |__ I-tagged IF
                  --------       ------       --------
                     |           |  ||LAG    LAG||
......................|...........|..||..........||...................
   ..................|...........|..||..........||...................
                     |           |  ||          ||
                  ---+----       ------        ------
                 | LSR A  |_____|LSR B |_____|LSR C |
                 |  (LSC) |     |(LSC) | WDM |(LSC) |
                  --------       ------       ------
                     | GMPLS Eth-LSP (BVID/BMAC)|
                     |<------------------------>|
                     |   O-LSP   |   |  O-LSP   |
                     |<--------->|   |<-------->|

   Figure 2 Multi-layer GMPLS controlled Ethernet label switched network

4.  Requirements

   Section 4.1 to 4.6 describe requirements for single layer Ethernet
   label swicth network based on the reference model from Fig.1.
   In addition, section 4.7 describes requirements for multiple
   layer network with Ethernet layer and circuit switch layer (such as
   wavelength switched layer and so on). Finally, section 4.8 describes
   generic requirements applicable to single and multiple layer
   networks.

4.1 Control plane architecture and functionality

4.1.1 In-band control plane channel

   The solution should be able

4.1.  Control plane architecture and functionality

4.1.1.  In-band control channel

   The solution should be able to establish in-band control channel,
   while preserving the solution of out-band control channel.  The
   solution should include negotiation mechanism to specify bandwidth
   and priority of control-channel between peer Ethernet switches.

4.1.2

4.1.2.  Neighbor discovery mechanism

   The solution MUST be able to realize automatic neighbor discovery discover as
   realized in current PB or PBB networks.  Namely, the solution MUST
   support an automatic negotiation mechanism to exchange information of
   Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and
   IP address of the control channel.  On the other hand, the extension
   should be minimized by making use of [IEEE 802.1AB].

4.2 [IEEE802.1AB].

4.1.3.  Addressing

   TBD

4.2.  Ethernet LSP control

4.2.1

4.2.1.  Prevention of Loops

   The solution should have reliability to prevent creating loops of
   Eth-LSPs.  Specifically if the solution supports numbered TE-Link
   addressing, the solution should define a methodology and protocol
   extensions if needed to detect or prevent loops.

4.2.2

4.2.2.  Service control

   The solution should control various types of service interfaces
   defined in [IEEE802.1ah].  The service types of Egress port

   1) Port based service interface

   2) S-tagged service interface

   a) one-to-one mapping of S-VIDs to I-SIDs

   b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to-one, all-to-
   one, transparent mapping
	3) I-tagged service interface
   should be controllable in addition to assignment of Egress port
   itself.

   Also, the solution should be flexible to following operational
   scenarios,

   1) Any change of mapping of S-VIDs to I-SIDs

   2) Flexibility to nest or stitch higher layer Eth-LSPs.

   3) Any change of bandwidth of Eth-LSPs.  Here, the solution of
   bandwidth modification scenario may include bundling of multiple Eth-LSPs.

4.2.3 Eth-
   LSPs.

4.2.3.  P2MP and MP2MP requirements

   Detail requirements will

   To provide the service such as a content distribution, the creation
   of uni-directional P2MP Eth-LSPs should be described supported.  Also, to
   provide E-tree type services with multicast traffic, the creation of
   bi-directional P2MP/MP2P Eth-LSPs should be supported.  The MP2MP
   requirement is under discussion.

4.2.4.  Asymmetric bandwidth

   To provide the service which has asymmetric traffic pattern such as a
   kind of E-tree type services, the creation of asymmetric bandwidth
   bi-directional Eth-LSPs should be supported.  The bandwidth
   modification of Eth-LSPs in future version.

4.3 operation should be also supported.

4.2.5.  QoS control

   The routing and signaling extensions to control QoS based on Ethernet
   traffic parameters defined in [MEF10.1] should be supported.  Unused
   bandwidth per CoS should be exhanged by routing extensions like
   [RFC4124] and the CoS and bandwidth profile such as CIR, CBS, EIR and
   EBS for a requested LSP should be carried by signaling extensions for
   bandwidth accounting and traffic control at a local level.

4.3.  OA&M related functionality

   OAM mechanisms must be defined for GMPLS controlled E-LSPs.  Since
   the data plane is still Ethernet based, the mechanisms should
   capitalize on existing IEEE802.1ad [IEEE802.1ag] and Y.1731 [Y.1731] mechanisms.

   Also, the solution should provide admin status control mechanism to
   coordinate with Connectivity Fault Management (CFM) functionality
   [IEEE802.1ag].

4.4

4.4.  Protection and Restoration related functionality

   Detail requirements will

   1:1 protection, Shared protection and dynamic restoration should be described in future version.

4.5
   supported.  Protection and Restoration may be triggered by Ethernet
   OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731].

4.5.  Link Aggregation Group (LAG) related functionality

   Link Aggregation is beneficial functionality to realize reliable
   Ethernet label switched networks.  The availability of connection
   between peer Ethernet switches can be enhanced in the case of single
   link failure, if member links of the LAG are diversely routed.  In
   this operational scenario, LAG provides for link protection
   functionality.

   The solution should include methodology to explicitly assign the
   links forming LAG a desired link type (which is similar sense to
   assign link protection type described in [RFC3471]).

4.5.1

4.5.1.  Failure or deletion of LAG member link

   The solution should include functionality to prioritize Eth-LSPs,
   specifically when total bandwidth of Eth-LSPs exceeds total bandwidth
   of healthy LAG members after the failure of one or more LAG member
   links.

   The solution should provide for rerouting an Eth-LSP setup over a
   failed member link in a LAG to another member link in the LAG.

4.5.2

4.5.2.  Recovery or addition of LAG member link

   The solution should include functionality to re-optimize Eth-LSP
   paths after the addition of a LAG member link, i.e. reversion of
   failed Eth-LSPs after the failure of the LAG member link, or
   reallocation of other Eth-LSPs traversing congested Links after the
   addition of LAG member link.

4.6

4.6.  Inter-domain Ethernet LSP

   The solution should take into account possible future extension to
   control inter-domain Eth-LSPs.  Here, the possible extensions are
   Eth-LSPs traverse over

   1) I-tagged service interfaces

   2) S-tagged service interfaces, and

   3) C-tagged service interfaces.

4.7

4.7.  Multi-layer network

4.7.1

4.7.1.  Dynamic formation of LAG

   The solution should include dynamic formation of a LAG after the
   creation or deletion of optical LSPs which interconnect ports of
   Ethernet switches.

4.7.2

4.7.2.  Other requirements

   The architecture and requirements for MPLS-GMPLS inter-working are
   described in [Interwk-fwk] [RFC5145] and [Interwk-req]. [RFC5146].  Some of the requirements
   described in [Interwk-req] [RFC5146] are valid even for the case of GMPLS-GMPLS
   interworking between Ethernet label switched network and L1 network.
   In other words,

   1) End-to-End signaling of Eth-LSPs

   2) Triggered establishment of L1 LSPs

   3) Avoiding complexity and risks.

   should be satisfied even for GMPLS control plane for Ethernet.  For
   more details, see [Interwk-req] and MPLS-TE client network written in
   the document should be understood as Ethernet client network.

   Regarding to routing issue,

   1) Advertisement of Ethernet label switch network information via L1
   GMPLS networks

   2) Selective Advertisement of Ethernet label switched network
   information via a Border node

   should be satisfied even in the case of GMPLS-GMPLS inter-working.
   Note that there is significant difference between MPLS-TE and GMPLS
   controlled Ethernet from the view point of methodology to create
   control channel.

4.8

4.8.  Scalability

   The solution MUST be designed to scale according to following
   metrics.

   - Number of nodes

   - Number of TE-Links
   - Number of LSPs

   - Number of service ports

   - Number of bundled S-VLANs mapped to I-SID and Eth-LSPs.

5.  Security considerations

   TBD Considerations

   The extension for GMPLS controlled Ethernet label switching should be
   considered under the same security as current work.  This extension
   will not change the underlying security issues.

6.  IANA considerations

   TBD Considerations

   This document has no actions for IANA.

7.  Acknowledgements

   The authors would like to thank Mr. Allan McGuire, Mr. Jullien
   Meuric, Mr. Lou Berger and Mr. Don Fedyk for their valuable comments.

8.  References

7.1

8.1.  Normative References

   [IEEE802.1AB]
              IEEE Standard for Local and Metropolitan Area Networks,
              Station and Media Access Control Connectivity
              Discovery

   [IEEE802.1Qay]
              "IEEE standard for Provider Backbone Bridges Traffic
              Engineering", work in progress.

   [IEEE802.1ad]
              IEEE Computer Society, "Virtual Bridged Local Area
              Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,
              Draft, Work in Progress Progress.

   [IEEE802.1ag]
              IEEE Computer Society, "Virtual Bridged Local Area
              Networks - Amendment 5 : Connectivity Fault Management",
              P802.1ag/D5.2, Draft, Work in Progress.

   [IEEE802.1ah]
              "IEEE standard for Provider Backbone Bridges", work in
              progress.

   [IEEE802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic
              Engineering", work in progress.

   [RFC3945]  E. Mannie (Editor), "Generalized Multi-Protocol Label
              Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area
              Networks, Station and Media Access Control Connectivity
              Discovery".

   [IEEE802.3]
              IEEE Computer Society, "Amendment to Carrier Sense
              Multiple Access with Collision Detection (CAMS/CD) Access
              Method and Physical Layer Specifications ?
              Aggregation of Multiple Link Segements, " P802.3ad,
              March 2000.

   [IEEE802.1ag] IEEE Computer Society, "Virtual Bridged Local Area
              Networks - Amendment 5 : Connectivity Fault Management",
              P802.1ag/D5.2, Draft, Work Specifications.

   [MEF10.1]  MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http
              ://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf,
              Nov. 2006.

   [RFC2119]  Bradner, S., "Key words for use in Progress RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

7.2

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [Y.1731]   "ITU-T Y.1731".

8.2.  Informative References

   [Interwk-frw]    Shiomoto, K., Papadimitriou, D.,

   [RFC4124]  Le Roux, J.L.,
             Brungard, D., Kumaki, Faucheur, F., "Protocol Extensions for Support of
              Diffserv-aware MPLS Traffic Engineering", RFC 4124,
              June 2005.

   [RFC5145]  Shiomoto, K., Ali, Z., Oki, E., Inoue, I.,
             Otani, T., "Framework for MPLS-TE to GMPLS migration",
             draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in
             progress.

   [Interwk-req] Migration",
              RFC 5145, March 2008.

   [RFC5146]  Kumaki, K., Otani, T., Okamoto, S., Fujihara,
             K., Ikejiri, Y., "Interworking Requirements to Support
             operation
              Operation of MPLS-TE over GMPLS Networks", draft-ietf-
             ccamp-gmpls-mln-reqs, work in progress.

8. Acknowledgments

   The authors would like to thank Mr. Allan McGuire, Mr. Jullien
   Meuric, Mr. Lou Berger and Mr. Don Fedyk for their valuable
   comments.

9. RFC 5146,
              March 2008.

Authors' Addresses

   Wataru Imajuku (ed.) (editor)
   NTT Network Innovation Labs
   1-1 Hikari-no-oka, Hikari-no-oka
   Yokosuka, Kanagawa
   Japan

   Phone: +81-(46) 859-4315
   Email: imajuku.wataru@lab.ntt.co.jp

   Yoshiaki Sone
   NTT Network Innovation Labs
   1-1 Hikari-no-oka, Hikari-no-oka
   Yokosuka, Kanagawa
   Japan

   Phone: +81-(46) 859-2456
   Email: sone.yoshiaki@lab.ntt.co.jp

   Muneyoshi Suzuki
   NTT Access Service System Labs
   1-6 Nakase, Nakase
   Mihama-ku, Chiba
   Japan

   Phone: +81-(43) (43) 211-8282
   Email: suzuki.muneyoshi@lab.ntt.co.jp

   Kazuhiro Matsuda
   NTT Network Innovation Labs
   1-1 Hikari-no-oka, Hikari-no-oka
   Yokosuka, Kanagawa
   Japan

   Phone: +81-(46) (46) 859-3177
   Email: matsuda.kazuhiro@lab.ntt.co.jp

   Nabil Bitar (ed.)
   Verizon
   40 Sylvan Road
   Waltham, MA 02451
   Tomohiro Otani (editor)
   KDDI Corporation
   2-3-2 Nishi-shinjukuOhara
   Shinjuku-ku, Tokyo  163-8003
   Japan

   Phone: +81-(3) 3347-6006
   Email: nabil.n.bitar@verizon.com tm-otani@kddi.com

   Kenichi Ogaki
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino-shi
   Saitama,
   Kamifukuoka, Saitama  356-8502
   Japan

   Phone: +81-49-278-7897 +81-(49) 278-7897
   Email: ogaki@kddilabs.jp

   Tomohiro Otani (ed.)
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino-shi
   Saitama, 356-8502 Japan

   Phone: +81-49-278-7357

   Nabil Bitar (editor)
   Verizon
   40 Sylvan Road
   Waltham, MA  02451
   USA

   Email: otani@kddilabs.jp nabil.n.bitar@verizon.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

Intellectual Property Statement

   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.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.