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

Versions: 00 01 02 03 04 05 06 07 RFC 5885

PWE3                                                      T. Nadeau, Ed.
Internet-Draft                                                        BT
Intended status: Standards Track                       C. Pignataro, Ed.
Expires: August 27, 2008                             Cisco Systems, Inc.
                                                       February 24, 2008


  Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual
                Circuit Connectivity Verification (VCCV)
                      draft-ietf-pwe3-vccv-bfd-01

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 August 27, 2008.

Abstract

   This document describes new Connectivity Verification (CV) types
   using Bidirectional Forwarding Detection (BFD) with Virtual Circuit
   Connectivity Verification (VCCV).  VCCV provides a control channel
   that is associated with a Pseudowire (PW), as well as the
   corresponding operations and management functions such as
   connectivity verification to be used over that control channel.







Nadeau & Pignataro       Expires August 27, 2008                [Page 1]


Internet-Draft                  BFD VCCV                   February 2008


Table of Contents

   1.  Specification of Requirements  . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Bidirectional Forwarding Detection Connectivity
       Verification . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  BFD CV Type Operation  . . . . . . . . . . . . . . . . . .  4
     3.2.  BFD Encapsulation  . . . . . . . . . . . . . . . . . . . .  5
     3.3.  CV Types for BFD . . . . . . . . . . . . . . . . . . . . .  6

   4.  Capability Selection . . . . . . . . . . . . . . . . . . . . .  7

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV  .  8
     5.2.  PW Associated Channel Type . . . . . . . . . . . . . . . .  9
     5.3.  L2TPv3 CV Types for the VCCV Capability AVP  . . . . . . .  9

   6.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 10

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11

   Appendix A.  Pending Items . . . . . . . . . . . . . . . . . . . . 12

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13


















Nadeau & Pignataro       Expires August 27, 2008                [Page 2]


Internet-Draft                  BFD VCCV                   February 2008


1.  Specification of Requirements

   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 [RFC2119].

   The reader is expected to be familiar with the terminology and
   abbreviations defined in [RFC5085].


2.  Introduction

   This document describes new Connectivity Verification (CV) types
   using Bidirectional Forwarding Detection (BFD) with Virtual Circuit
   Connectivity Verification (VCCV).  VCCV [RFC5085] provides a control
   channel that is associated with a Pseudowire (PW), as well as the
   corresponding operations and management functions such as
   connectivity/fault verification to be used over that control channel.

   Some BFD CV Types can additionally carry fault status between the
   endpoints of the pseudowire.  Furthermore, this information can then
   be translated into the native OAM status codes used by the native
   access technologies, such as ATM, Frame-Relay or Ethernet.  The
   specific details of such status interworking are out of the scope of
   this document, and are only noted here to illustrate the utility of
   BFD over VCCV for such purposes.  Those details can be found in
   [I-D.ietf-pwe3-oam-msg-map].

   The new BFD CV Types are PW Demultiplexer-agnostic, and hence
   applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers.  This
   document concerns itself with the BFD VCCV operation over Single-
   Segment Pseudowires (SS-PW).


3.  Bidirectional Forwarding Detection Connectivity Verification

   VCCV can support several Connectivity Verification (CV) types.  This
   section defines new CV Types for use when BFD is used as the VCCV
   payload.

   The CV Type is defined as a bitmask field used to indicate the
   specific CV Type or types (i.e., none, one or more) of VCCV packets
   that may be sent on the VCCV control channel.  The values shown below
   augment those already defined in [RFC5085].  They represent the
   numerical value corresponding to the actual bit being set in the CV
   Type bitfield.

   BFD CV Types:



Nadeau & Pignataro       Expires August 27, 2008                [Page 3]


Internet-Draft                  BFD VCCV                   February 2008


      The defined values for the different BFD CV Types for MPLS and
      L2TPv3 PWs are:

         Bit (Value)    Description
         ============   ==========================================
         Bit 2 (0x04) - BFD for PW Fault Detection Only.
         Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling.
         Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                        payload without IP/UDP headers.
         Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling, carrying BFD payload without
                        IP/UDP headers.

   It should be noted that four BFD CV Types have been defined by
   permutation of their encapsulation and functionality, see
   Section 3.3.

3.1.  BFD CV Type Operation

   When heart-beat indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides
   a means of continuous monitoring of the PW data path and, in some
   operational modes, propagation of forward and reverse defect
   indications.

   In order to use BFD, both ends of the PW connection need to agree on
   the BFD CV Type to use:

      For statically provisioned pseudowires, both ends need to be
      statically configured to use the same BFD CV Type (in addition to
      be statically configured for VCCV with the same CC Type).

      For dynamically established pseudowires, both ends of the PW must
      have signaled the existence of a control channel and the ability
      to run BFD on it (see Section 3.3 and Section 4).

   Once a node has selected a valid BFD CV Type to use (either
   statically provisioned or selected dynamically after the node has
   both signaled and received signaling from its peer of these
   capabilities), it begins sending BFD control packets.

   The BFD packets are sent on the VCCV control channel.  The use of the
   VCCV control channel provides the context required to bind and
   bootstrap the BFD session, since discriminator values are not
   exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or
   L2TPv3 Session ID) provides the context to demultiplex the first BFD
   control packet, and thus single-hop BFD initialization procedures are



Nadeau & Pignataro       Expires August 27, 2008                [Page 4]


Internet-Draft                  BFD VCCV                   February 2008


   followed (see Section 3 of [I-D.ietf-bfd-v4v6-1hop] and Section 6 of
   [I-D.ietf-bfd-generic]).  A single BFD session exists per-pseudowire.
   Both PW endpoints take the Active role sending initial BFD Control
   packets with a "Your Discriminator" field of zero, and BFD packets
   received with a "Your Discriminator" field of zero are associated to
   the BFD session bound to the PW.  BFD MUST be run in asynchronous
   mode (see [I-D.ietf-bfd-base]).

   When the downstream PE (D-PE) does not receive BFD control messages
   from its upstream peer PE (U-PE) during a certain number of
   transmission intervals (a number provisioned by the operator as
   Detect Mult), D-PE declares that the PW in its receive direction is
   down.  In other words, D-PE enters the "forward defect" state for
   this PW.  After this calculated Detection Time, D-PE declares the
   session Down, and signals this to the remote end via the State (Sta)
   with Diagnostic code 1 (Control Detection Time Expired).  In turn,
   U-PE declares the PW is down in its transmit direction setting the
   State to Down, and it using Diagnostic code 3 (Neighbor signaled
   session down) in its control messages to D-PE.  U-PE enters the
   "reverse defect" state for this PW.  If needed, how it further
   processes this error condition, and conveys this status to the
   attachment circuits is out of the scope of this specification, and is
   instead defined in [I-D.ietf-pwe3-oam-msg-map].

   The VCCV message comprises a BFD packet [I-D.ietf-bfd-base]
   encapsulated as specified by the CV Type (see Section 3.2).

3.2.  BFD Encapsulation

   There are two ways in which a BFD connectivity verification packet
   may be encapsulated over the VCCV control channel.  This document
   defines four BFD CV Types (see Section 3), which can be grouped into
   two pairs of BFD CV Types from an encapsulation point of view.
   Table 1 in Section 3.3 summarizes the BFD CV Types.

   In the first method, the VCCV encapsulation of BFD includes the IP/
   UDP headers as defined in Section 4 of [I-D.ietf-bfd-v4v6-1hop].  The
   IP Protocol Number and UDP Port numbers discriminate among the
   possible VCCV payloads (i.e., differentiate among ICMP Ping and LSP
   Ping defined in [RFC5085] and BFD).  In this case, the BFD CV Type
   used in signaling (if used) is either 0x04 or 0x08.

   In the second method, a BFD packet is encapsulated directly in the
   VCCV control channel (see Sections 6 and 8 of [I-D.ietf-bfd-generic])
   and the IP/UDP headers are omitted from the BFD encapsulation.
   Therefore, to utilize this encapsulation, a pseudowire MUST use a
   Control Word (CW) or Layer-2 Specific Sublayer (L2SS) that can take
   the PW Associated Channel Header (PW-ACH) Control Word format.  In



Nadeau & Pignataro       Expires August 27, 2008                [Page 5]


Internet-Draft                  BFD VCCV                   February 2008


   this encapsulation, a BFD packet follows directly the PW-ACH.  The PW
   Associated Channel (PW-AC) is defined in Section 5 of [RFC4385], and
   its Channel Type field is used as a payload type identifier to
   discriminate the VCCV payload types.  The usage of the PW-AC for VCCV
   is specified in Sections 5.1.1, 5.1.2 and 5.1.3 of [RFC5085].  When
   VCCV carries raw BFD, the Pseudowire CW's or L2SS' Channel Type MUST
   be set to 0x0007 to indicate "BFD Without IP/UDP Headers" (see
   Section 5.2), to allow the identification of the encased BFD payload
   when demultiplexing the VCCV control channel.  In this case, the BFD
   CV Type employed in signaling (if used) is either 0x10 or 0x20.

   In summary, for the BFD encapsulation with IP/UDP headers, if a PW
   Associated Channel Header is used, the Channel Type can indicate IPv4
   (0x0021) or IPv6 (0x0057).  For the BFD encapsulation without IP/UDP
   headers, the PW Associated Channel Header MUST be used and indicates
   BFD (0x0007).

3.3.  CV Types for BFD

   Four CV Types are defined for BFD.  Table 1 summarizes the BFD CV
   Types, grouping them by encapsulation (i.e., with and without IP/UDP
   headers) and by functionality (i.e., fault detection only, or fault
   detection and status signaling).

   +---------------------+-----------------+---------------------------+
   |                     | Fault Detection |    Fault Detection and    |
   |                     |       Only      |      Status Signaling     |
   +---------------------+-----------------+---------------------------+
   |     BFD with IP/UDP |       0x04      |            0x08           |
   |             Headers |                 |                           |
   |                     |                 |                           |
   |  BFD without IP/UDP |       0x10      |            0x20           |
   |             Headers |                 |                           |
   +---------------------+-----------------+---------------------------+

                 Table 1: Bitmask Values for BFD CV Types

   Given the bidirectional nature of BFD, before selecting a given BFD
   CV Type capability to be used in dynamically established pseudowires,
   there MUST be common CV Types in the VCCV capability advertised and
   received.  That is, only BFD CV Types that were both advertised and
   received are available to be selected.  Additionally, only one BFD CV
   Type can be used (selecting a BFD CV Type excludes all the remaining
   BFD CV Types).

   The following list enumerates rules, restrictions and clarifications
   on the usage of BFD CV Types:




Nadeau & Pignataro       Expires August 27, 2008                [Page 6]


Internet-Draft                  BFD VCCV                   February 2008


   1.  BFD CV Types used for fault detection and status signaling (i.e.,
       CV Types 0x08 and 0x20) SHOULD NOT be used when a control
       protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
       that can signal the AC/PW status to the remote endpoint of the
       PW.  More details can be found in [I-D.ietf-pwe3-oam-msg-map].

   2.  BFD CV Types used for fault detection only (i.e., CV Types 0x04
       and 0x10) can be used whether a protocol that can signal AC/PW
       status is available or not.  This includes both statically
       provisioned and dynamically signaled pseudowires.

       A.  In this case, BFD is used exclusively to detect faults on the
           PW; if it is desired to convey AC/PW fault status, some means
           other than BFD are to be used.  Examples include using LDP
           status messages when using MPLS as a transport (see Section
           5.4 of [RFC4447]), and the Circuit Status AVP in an L2TPv3
           SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]).

   3.  Pseudowires that do not use a CW or L2SS using the PW Associated
       Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
       encapsulation of BFD without IP/UDP headers).

       A.  PWs that use a PW-ACH include CC Type 1 (for both MPLS and
           L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]),
           and MPLS CC Types 2 and 3 when using a Control Word (as
           specified in Sections 5.1.2 and 5.1.3 of [RFC5085]).  This
           restriction stems from the fact that the PW-ACH contains a
           Protocol Identification (PID) field, the Channel Type.

       B.  PWs that do not use a PW-ACH can use the VCCV BFD
           encapsulation with IP/UDP headers, including its concurrent
           use along with another CV Type that uses an encapsulation
           with IP headers (e.g., ICMP Ping or LSP Ping).

   4.  Only a single BFD CV Type can be selected and used.  All BFD CV
       Types are mutually exclusive with the rest, after selecting a BFD
       CV Type, a node MUST NOT use any of the other three BFD CV Types.


4.  Capability Selection

   The precedence rules for selection of various CC and CV Types is
   clearly outlined in Section 7 of [RFC5085].  This section augments
   these rules when the BFD CV Types defined herein are supported.  The
   selection of a specific BFD CV Type to use out of the four available
   CV Types defined is tied to multiple factors, as hinted in
   Section 3.3.  Given that BFD is bidirectional in nature, only CV
   Types that are both received and sent in VCCV capability signaling



Nadeau & Pignataro       Expires August 27, 2008                [Page 7]


Internet-Draft                  BFD VCCV                   February 2008


   advertisement can be selected.

   There may be more than one CV Type available for selection after
   considering the intersection of advertised and received BFD CV Types,
   and applying the rules in Section 3.3.  For these cases were multiple
   BFD CV Types are available for selection, the following precedence
   order applies when choosing the single BFD CV Type to use.  The
   lowest numbered item (where both ends have set the indicated flag and
   such flag is allowed by the rules above) is used:

   1.  0x20 - BFD for PW Fault Detection and AC/PW Fault Status
       Signaling, carrying BFD payload without IP/UDP headers.

   2.  0x10 - BFD for PW Fault Detection Only, carrying BFD payload
       without IP/UDP headers.

   3.  0x08 - BFD for PW Fault Detection and AC/PW Fault Status
       Signaling.

   4.  0x04 - BFD for PW Fault Detection Only.

   This precedence order prioritizes superset of functionality and
   simplicity of encapsulation.


5.  IANA Considerations

5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV

   The VCCV Interface Parameters Sub-TLV codepoint is defined in
   [RFC4446], and the VCCV CV Types registry is defined in [RFC5085].
   This section lists the new BFD CV Types.

   IANA is requested to augment the "VCCV Connectivity Verification
   Types" registry in the Pseudo Wires Name Spaces, reachable from
   [IANA.pwe3-parameters].  These are bitfield values.  CV Type values
   0x04 0x08, 0x10 and 0x20 are specified in Section 3.














Nadeau & Pignataro       Expires August 27, 2008                [Page 8]


Internet-Draft                  BFD VCCV                   February 2008


      MPLS Connectivity Verification (CV) Types:

      Bit (Value)    Description
      ============   ==========================================
      Bit 2 (0x04) - BFD for PW Fault Detection Only.
      Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault Status
                     Signaling.
      Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                     payload without IP/UDP headers.
      Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault Status
                     Signaling, carrying BFD payload without IP/UDP
                     headers.

5.2.  PW Associated Channel Type

   The PW Associated Channel Types used by VCCV rely on previously
   allocated numbers from the Pseudowire Associated Channel Types
   Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
   [IANA.pwe3-parameters].  In particular, 0x21 (Internet Protocol
   version 4) is used whenever an IPv4 payload follows the Pseudowire
   Associated Channel Header, or 0x57 is used when an IPv6 payload
   follows the Pseudowire Associated Channel Header.

   In cases where raw BFD follows the Pseudowire Associated Channel as
   specified in Section 3.2 (i.e., when the IP/UDP encapsulation as
   specified in [I-D.ietf-bfd-v4v6-1hop] is be present), a new
   Pseudowire Associated Channel Types Registry [RFC4385] entry of 0x07
   is used.  IANA is requested to reserve a new Pseudowire Associated
   Channel Type value as follows:


     Value (in hex)  Protocol Name                    Reference
     --------------  -------------------------------  ---------

     0x0007          BFD Without IP/UDP Headers       [This document]

5.3.  L2TPv3 CV Types for the VCCV Capability AVP

   This section lists the new BFD CV Types to be added to the existing
   "VCCV Capability AVP" registry in the L2TP name spaces.  The Layer
   Two Tunneling Protocol "L2TP" Name Spaces are reachable from
   [IANA.l2tp-parameters].

   IANA is requested to reserve the following L2TPv3 Connectivity
   Verification (CV) Types in the VCCV Capability AVP Values registry.






Nadeau & Pignataro       Expires August 27, 2008                [Page 9]


Internet-Draft                  BFD VCCV                   February 2008


      VCCV Capability AVP (Attribute Type AVP-TBD) Values
      ---------------------------------------------------

      L2TPv3 Connectivity Verification (CV) Types:

         Bit (Value)    Description
         ============   ==========================================
         Bit 2 (0x04) - BFD for PW Fault Detection Only.
         Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling.
         Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                        payload without IP/UDP headers.
         Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling, carrying BFD payload without
                        IP/UDP headers.


6.  Congestion Considerations

   The congestion considerations that apply to [RFC5085] apply to this
   mode of operation as well.


7.  Security Considerations

   Routers that implement the additional CV Types defined herein are
   subject to the same security considerations as defined in [RFC5085],
   [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop].  This
   specification does not raise any additional security issues beyond
   these.


8.  Acknowledgements

   This work forks from a previous revision of the PWE3 WG document that
   resulted in [RFC5085], to which a number of people contributed,
   including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji
   Kumaki, Luca Martini, Monique Morrow, George Swallow, and others.

   Stewart Bryant, Luca Martini, Pankil Shah, and George Swallow
   provided useful feedback and valuable comments and suggestions on the
   newer versions of this document.


9.  References






Nadeau & Pignataro       Expires August 27, 2008               [Page 10]


Internet-Draft                  BFD VCCV                   February 2008


9.1.  Normative References

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-07 (work in progress),
              January 2008.

   [I-D.ietf-bfd-generic]
              Katz, D. and D. Ward, "Generic Application of BFD",
              draft-ietf-bfd-generic-04 (work in progress),
              January 2008.

   [I-D.ietf-bfd-v4v6-1hop]
              Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
              Hop)", draft-ietf-bfd-v4v6-1hop-07 (work in progress),
              January 2008.

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

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV): A Control Channel for
              Pseudowires", RFC 5085, December 2007.

9.2.  Informative References

   [I-D.ietf-pwe3-oam-msg-map]
              Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping",
              draft-ietf-pwe3-oam-msg-map-06 (work in progress),
              February 2008.

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", April 2007,
              <http://www.iana.org/assignments/l2tp-parameters>.

   [IANA.pwe3-parameters]
              Internet Assigned Numbers Authority, "Pseudo Wires Name
              Spaces", June 2007,
              <http://www.iana.org/assignments/pwe3-parameters>.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.




Nadeau & Pignataro       Expires August 27, 2008               [Page 11]


Internet-Draft                  BFD VCCV                   February 2008


   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.


Appendix A.  Pending Items

   BFD Echo - Need PW-ACH Channel Type for BFD Echo (and make 0x0007
   "BFD Control")?  BFD Echo is not explicitly allowed / disallowed, but
   if allowed, need PID for the sans IP/UDP encap.


Authors' Addresses

   Thomas D. Nadeau (editor)
   BT
   BT Centre
   81 Newgate Street
   London,   EC1A 7AJ
   United Kingdom

   Email: tom.nadeau@bt.com


   Carlos Pignataro (editor)
   Cisco Systems, Inc.
   7200 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com
















Nadeau & Pignataro       Expires August 27, 2008               [Page 12]


Internet-Draft                  BFD VCCV                   February 2008


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

   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.











Nadeau & Pignataro       Expires August 27, 2008               [Page 13]


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