[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

      CCAMP Working Group                                    JP Vasseur (Ed.)
                                                             Cisco System Inc.
      Internet Draft                                         JL Le Roux (Ed.)
                                                                France Telecom
      
      
      
      
      Category: Standard Track
      Expires: January 2005                                          July 2004
      
      
             Routing extensions for discovery of TE router information
      
                     draft-vasseur-ccamp-te-router-info-00.txt
      
      
      Status of this Memo
      
         By submitting this Internet-Draft, I certify that any applicable
         patent or IPR claims of which I am aware have been disclosed, and any
         of which I become aware will be disclosed, in accordance with RFC
         3668.
      
         This document is an Internet-Draft and is in full conformance with
         all provisions of Section 10 of RFC2026. 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 describes extensions to MPLS Traffic Engineering
         routing for the advertisement of Traffic Engineering Router
         Information and capabilities. This document specifies a functional
         description of these extensions whereas protocol specific formats and
         mechanisms are described in separate documents.
      
      
      
      Vasseur, Le Roux et al.                                         [Page 1]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      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.
      
      Table of Contents
      
         1. Contributors....................................................2
         2. Terminology.....................................................3
         3. Introduction....................................................3
         4. TE Node Capability Descriptor TLV...............................4
         4.1. Description...................................................4
         4.2. Required Information..........................................5
         4.3. Procedure.....................................................5
         5. PCE Discovery Information.......................................5
         5.1. Description...................................................5
         5.2. Required Information..........................................6
         5.3. Procedure.....................................................7
         6. TE Mesh Group Information.......................................8
         6.1. Description...................................................8
         6.2. Required Information..........................................8
         6.3. Procedure.....................................................8
         7. Security Considerations.........................................9
         8. Intellectual Property Statement.................................9
         8.1. IPR Disclosure Acknowledgement................................9
         9. Acknowledgment..................................................9
         10. References....................................................10
         11. Editors' Address:.............................................11
      
      1. Contributors
      
         This document was the collective work of several. The text and
         content of this document was contributed by the editors and the
         co-authors listed below (the contact information for the editors
         appears in section 14, and is not repeated below):
      
         Paul Mabey                 Seisho Yasukawa
         Qwest Communications       NTT
         950 17th street            9-11, Midori-Cho 3-Chome
         Denver, CO 80202           Musashino-Shi, Tokyo 180-8585
         USA                        JAPAN
         Email: pmabey@qwest.com    Email: yasukawa.seisho@lab.ntt.co.jp
      
         Stefano Previdi              Peter Psenak
         Cisco System, Inc.           Cisco System, Inc.
         Via del Serafico 200         Pegasus Park
         00142 Roma                   DE Kleetlaan 6A
         ITALY                        1831, Diegmen
         Email: sprevidi@cisco.com    BELGIUM
                                      Email: ppsenak@cisco.com
      
      
      Vasseur, Le Roux et al.                                       [Page 2]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      2. Terminology
      
         Terminology used in this document
      
            LSR: Label Switch Router.
      
            PCE: Path Computation Element whose function is to compute the
                 path of a TE LSP it is not the head-end for. The PCE may be
                 an LSR or an offline tool not forwarding packet.
      
            PCC: Path Computation Client (any head-end LSR) requesting a TE
                 LSP path computation to the Path Computation Element.
      
            TE LSP: Traffic Engineering Label Switched Path.
      
            TE LSP head-end: head/source of the TE LSP.
      
            TE LSP tail-end: tail/destination of the TE LSP.
      
            IGP Area: OSPF Area or ISIS level
      
            Link State Advertisement: An OSPF LSA or ISIS LSP
      
            Intra-area TE LSP: TE LSP whose path does not transit across
            areas.
      
            Inter-area TE LSP: A TE LSP whose path transits across at least
            two different IGP areas.
      
            Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least
            two different ASes or sub-ASes (BGP confederations).
      
      
      3. Introduction
      
         MPLS Traffic Engineering (MPLS-TE) routing ([ISIS-TE], [OSPF-TE])
         relies on extensions to link state IGP routing protocols ([OSPF],
         [ISIS]) in order to carry Traffic Engineering link information used
         for constraint based routing. Further Generalized MPLS (GMPLS)
         related extensions are defined in [ISIS-G] and [OSPF-G].
      
         The current MPLS-TE/GMPLS routing focuses on TE link information. In
         return TE router information are limited to the TE router id.
         However, it would be highly useful to advertise more TE router
         information for various purposes such as:
      
             - A Path Computation Elements (PCE) can compute paths for TE-LSPs
             it is not the head-end for. This can be an LSR or an offline
             tool not forwarding packets. PCE are useful in various MPLS-TE
             and GMPLS situations such as, for instance, inter-domain path
             computation (see [INT-DOMAIN-FRWK]) or backup path computation
             (see [FACILTY-BACKUP]). It would be highly useful that a node
      
      Vasseur, Le Roux et al.                                       [Page 3]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
             advertise its PCE capabilities so as for the LSRs in the network
             to automatically discover PCEs in addition to their capabilities,
             and thus would reduce the LSR configuration overhead. This would
             also allow for the dynamic discovery of a new PCE or that a PCE
             is not longer alive.
      
             - A TE mesh group is a group of LSRs that are connected by a full
             mesh of TE-LSPs. It is useful to advertise the desire of a node
             to join/leave a particular TE mesh group. This allows for an
             automatic provisioning of a full mesh of TE LSP, and thus
             drastically reduces the configuration overhead.
      
             - Data plane capabilities related to the node itself and not to
             its links, such as the capability to be a branch node or a bud
             LSR of a P2MP LSP tunnel (see [P2MP-REQ]). These node
             capabilities should be advertised by the IGP for path selection.
             It would also be highly useful to advertise control plane node
             Capabilities; for instance, the capability to support GMPLS
             signaling for a packet LSR, or the capability to support P2MP
             signaling. This would ease backward compatibility. For instance
             this would allow selecting a path that would avoid nodes that do
             not support a given signaling feature, or automatically
             triggering a mechanism that would handle these nodes on the path.
      
         This document specifies routing extensions in support of carrying
         Traffic Engineering router information for MPLS Traffic Engineering
         (MPLS-TE) and Generalized MPLS (GMPLS). Such Traffic Engineering
         router information will be carried into Link State Advertisements.
      
         This document specifies a functional description of the extensions
         required to advertise TE router information and capabilities. Generic
         routing protocol formats, procedure and definitions are provided in
         this document whereas protocol specific formats and procedures are
         defined in [OSPF-CAP], [OSPF-TE-CAP] for OSPF, and in [ISIS-CAP] and
         [ISIS-TE-CAP] for ISIS.
      
         The TE Router Information and capabilities defined in this document
         consists of three pieces of information:
              -The TE Node Capability Descriptor TLV used to advertise
               data and control plane TE capabilities of an LSR,
              -The PCE Discovery Information TLV used to advertise PCE
               capabilities.
              -The TE Mesh Group Information TLV used to advertise the desire
              of an LSR to join/leave one or more TE mesh groups.
      
      4. TE Node Capability Descriptor TLV
      
         4.1. Description
      
         LSRs in a network may have distinct control plane and data plane
         Traffic Engineering capabilities. The TE Node capability Descriptor
         TLV describes data and control plane capabilities of an LSR. Such
      
      Vasseur, Le Roux et al.                                       [Page 4]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
         information can be used for instance for path computation algorithm
         so as to avoid nodes that do not support a given TE feature either in
         the control or data plane or to trigger procedure to handle these
         nodes. In some case, this may also be useful for backward
         compatibility.
      
         4.2. Required Information
      
         The TE Node Capability Descriptor TLV contains two variable length
         sets of bit flags: the Control Plane Capability flags and the Data
         Plane Capability flags. Each flag corresponds to a given capability.
      
         Two flags are currently defined in the Data Plane Capability Flags:
      
         B bit: when set, this flag indicates that the LSR can act as a branch
         node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]).
      
         E bit: when set, this flag indicates that the LSR can act as a bud
         LSR on a P2MP LSP, i.e. and LSR that is both transit and egress.
      
      
         Three flags are currently defined in the Control Plane Capability
         Flags:
      
         M bit: when set, this flag indicates that the LSR supports MPLS-TE
         signalling ([RSVP-TE]).
      
         G bit: when set this flag indicates that the LSR supports GMPLS
         signalling ([RSVP-G]).
      
         P bit: when set, this flag indicates that the LSR supports P2MP MPLS-
         TE signalling ([RSVP-P2MP]).
      
         Note that new flags may be added if required.
      
         4.3. Procedure
      
         The TE Node Capability Descriptor TLV is carried in Link State
         Advertisements. A router MUST originate a new Link State
         Advertisement whenever the content of this information changes, or
         whenever required by regular routing procedure (e.g. refresh).
      
         TE Node Capability Descriptor TLVs are optional. When a Link State
         Advertisement does not contain any TE Node capability Descriptor TLV,
         this means that the TE Capabilities of that LSR are unknown.
      
      5. PCE Discovery Information
      
         5.1. Description
      
         The PCE Discovery Information allows for the auto-discovery of one or
         more Path Computation Element(s). In various MPLS and GMPLS
      
      Vasseur, Le Roux et al.                                       [Page 5]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
         situations, such as inter-domain TE or backup path computation, an
         LSR may require to send a request to a Path Computation Element (PCE)
         to compute one or more TE LSPs paths obeying a set of specified
         constraints. Note that a PCE can be an LSR or an offline tool without
         any forwarding capability.
      
         The PCE Discovery Information allows a PCE to announce its capability
         to be a Path Computation Element within an area or an AS. This allows
         every LSR in the network to automatically discover the PCEs and
         recognize their capabilities, which substantially simplifies head-end
         LSR configuration. Moreover, this also allows for:
              - The dynamic detection of any new PCE,
              - To determine that PCE is no longer active,
              - To perform some load sharing among a set of potential PCE
                candidates.
      
         5.2. Required Information
      
         The PCE Discovery Information carries the IP address to be used to
         reach the PCE. This address will typically be a loop-back address
         that is always reachable, provided the router is not isolated. The
         PCE IP address is mandatory, and MUST appear only once, except when
         the PCE has both an IPv4 and an IPv6 address.
      
         The PCE Discovery Information TLV also carries an optional set of
         capability flag bits that is used by the PCE to signal its PCE
         capabilities. This could then be used by an LSR to select the
         appropriate PCE among a list of PCE candidates.
      
         Six capability flags are currently defined. The first three bits
         define the scope for which the PCE is capable of performing the TE
         LSP Path Computation.
      
         L bit:
         Local scope. When set, this flag indicates that the PCE can compute
         paths for the area/level the PCE Discovery Information TLV is flooded
         into (the PCE can compute TE LSP paths for intra-area TE LSPs).
      
         I bit:
         Inter-area scope. When set, the PCE can perform TE LSP path
         computation for inter-area TE LSPs but within the same AS.
      
         A bit:
         Inter-AS scope. When set, the PCE can perform path computation
         for inter-AS TE LSPs.
      
         Note that those flags are not exclusive (a PCE may set one or more
         flags).
      
         P bit:
         Request Priority. The notion of request priority allows a PCC to
         specify the degree of urgency of a particular request. When set, this
      
      Vasseur, Le Roux et al.                                       [Page 6]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
         flag indicates that the PCE takes into account the 'request priority'
         in its scheduling of the various requests.
      
         M bit:
         Multiple Path Computation. When set, this flag indicates that the PCE
         is capable of computing more than one path obeying a set of specified
         constraints (in a single pass), provided that they exist.
      
         D bit:
         Diversity. When set, this flag indicates that the PCE is capable of
         computing diversely routed paths (link, node, SRLG). The PCC may
         request the PCE to compute N diversely routed paths obeying a set of
         specified constraints. Such N paths may not exist of course depending
         on the current state of the network.
      
         Note that new flags may be defined in the future to announce
         additional PCE capabilities.
      
         If the PCE is capable of computing inter-AS TE LSP path, the PCE
         Discovery Information TLV MAY also contain the list of AS numbers
         identifying the AS for which the PCE can compute inter-AS TE LSP
         paths (TE-LSPs having their destination address in this AS). This set
         is optional and should be included only when the A bit is set.
      
         5.3. Procedure
      
         The PCE Discovery Information TLV is carried in Link State
         Advertisements. A router MUST originate a new Link State
         Advertisement whenever the content of this information changes, or
         whenever required by regular routing procedure (e.g. refresh)
      
         The PCE Discovery Information TLV is optional.
      
         If the PCE can compute an intra-area TE LSP path, the L bit
         MUST be set. If it can compute an intra-area TE LSP path only for the
         LSRs in the area it resides in, then the PCE Discovery Information
         must be contained within an area. Otherwise, if the PCE can compute
         intra-area TE LSP paths for the whole AS, then the PCE Discovery
         Information TLV must be flooded across the whole AS.
      
         If the PCE can compute an inter-area TE LSP path, the I bit MUST be
         set. If it can compute an inter-area TE LSP path only for the LSRs in
         the area(s) it resides in (for instance the PCE is an ABR computing
         an inter-area TE LSP path for its area), then the PCE Discovery
         Information must be contained within this or these area(s). Else, if
         it can compute an inter-area TE LSP path for the whole AS, then the
         PCE Discovery Information must be flooded across the whole AS.
      
         If the PCE can compute an inter-AS TE LSP path, the A bit MUST be
         set, and the PCE Discovery Information must be flooded across the
         whole AS.
      
      
      Vasseur, Le Roux et al.                                       [Page 7]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      6. TE Mesh Group Information
      
         6.1. Description
      
         As of today, there are different approaches in deploying MPLS Traffic
         Engineering:
      
                 (1) The 'systematic' approach consisting of setting up a full
                     mesh of TE LSPs between a set of LSRs,
      
                 (2) The 'by exception' approach where a set of TE LSPs are
                     set up on hot spots to alleviate a congestion resulting
                     for instance in an unexpected traffic growth in some part
                     of the network.
      
         Setting up a full mesh of TE LSPs between a set of LSRs requires the
         configuration of a large number of TE LSPs on every head-end LSR. A
         full TE mesh of n LSRs requires to set up O(n^2) TE LSPs.
         Furthermore, the addition of any new LSR in the mesh implies to
         configure n TE LSPs on the new LSR and to add a new TE LSP on every
         LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This
         is not only time consuming but also a risky operation for
         Service Providers. Hence, a more automatic way of setting up a full
         mesh of TE LSPs is desirable.
      
         A TE-mesh group is defined as a group of LSRs fully meshed by a set
         of LSPs having common TE attributes. An LSR MUST setup a TE-LSP
         towards each LSR belonging to its TE mesh-group(s).
      
         The TE Mesh-Group Information allows an LSR to advertise its desire
         to join/leave one or more TE mesh-groups.
      
      
         6.2. Required Information
      
         The TE Mesh Group Information TLV allows an LSR to advertise the set
         of TE mesh-groups it belongs to. For each mesh group announced by the
         LSR, the TE Mesh Group Information TLV carries the following set of
         information:
              -A Mesh-Group number identifying the TE mesh-group,
              -A Tail-end address (address used as a tail end address by other
              LSRs belonging to the same mesh-group),
              -A Tail-end name: string used to ease the TE-LSP naming (e.g.
              'head-name->tail-name').
      
         6.3. Procedure
      
         The TE Mesh-Group Information TLV is carried in Link State
         Advertisements. A router MUST originate a new Link State
         Advertisement whenever the content of this information changes, or
         whenever required by regular routing procedure (e.g. refresh)
      
      
      Vasseur, Le Roux et al.                                       [Page 8]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
         The TE Mesh-Group Information is optional.
      
         If the TE Mesh Group is contained within a single area, the TE Mesh
         Group Information TLV must be advertised with an area scope for OSPF
         and MUST not be leaked across levels for IS-IS.
      
         Conversely, if the TE Mesh Group spans multiple IGP areas, the TE
         Mesh Group Information TLV must be advertisement with a routing
         domain scope for OSPF and MUST be leaked across levels for IS-IS.
      
      7. Security Considerations
      
         No new security issues are raised in this document.
      
      8. 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..
      
         8.1. IPR Disclosure Acknowledgement
      
         By submitting this Internet-Draft, I certify that any applicable
         patent or other IPR claims of which I am aware have been disclosed,
         and any of which I become aware will be disclosed, in accordance with
         RFC 3668.
      
      9. Acknowledgment
      
         We would like to thank Yannick Le Louedec, for its useful comments.
      
      
      
      
      
      
      Vasseur, Le Roux et al.                                       [Page 9]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      10. References
      
         Normative references
      
         [RFC] Bradner, S., "Key words for use in RFCs to indicate
         requirements levels", RFC 2119, March 1997.
      
         [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
         RFC 3667, February 2004.
      
         [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
         Technology", BCP 79, RFC 3668, February 2004.
      
         [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
      
         [ISIS] "Intermediate System to Intermediate System Intra-Domain
         Routing Exchange Protocol " ISO 10589.
      
         [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
         dual environments", RFC 1195, December 1990.
      
         [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
         Extensions to OSPF Version 2", RFC 3630, September 2003.
      
         [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
         Engineering", RFC 3784, June 2004.
      
         Informative References
      
         [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support
         of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-
         gmpls-routing-09.txt (work in progress)
      
         [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of
         Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf-
         gmpls-extensions-12.txt, work in progress.
      
         [ISIS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of
         Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls-
         extensions-19.txt, work in progress.
      
         [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
         J.P., "Extensions to OSPF for advertising Optional Router
         Capabilities", draft-ietf-ospf-cap-03.txt, work in progress.
      
         [OSPF-TE-CAP] Vasseur, J.P., Psenak, P., Yasukawa, S., "OSPF MPLS
         Traffic Engineering Capabilities", draft-vasseur-ospf-te-caps-00.txt,
         work in progress.
      
         [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N., "IS-IS extensions
         for advertising router information", draft-vasseur-isis-caps-02.txt,
         work in progress.
      
      Vasseur, Le Roux et al.                                      [Page 10]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      
         [ISIS-TE-CAP] Vasseur, J.P, Previdi, S., Mabey, P., Le Roux, J.L.,
         "IS-IS MPLS Traffic Engineering Capabilities", draft-vasseur-isis-te-
         caps-00.txt, work in progress.
      
         [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements
         for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea-
         mpls-te-req-02.txt, work in progress.
      
         [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
         Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-
         07.txt, work in progress.
      
         [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A
         Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel-
         ccamp-inter-domain-framework-01.txt, work in progress.
      
         [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for
         PCE based MPLS Facility Backup Path Computation", draft-leroux-pce-
         backup-comp-frwk-00.txt, work in progress
      
         [P2MP-Req] Yasukawa, S., et. al., "Requirements for point-to-
         multipoint extension to RSVP-TE", draft-ietf-mpls-p2mp-requirement-
         02.txt, work in progress.
      
         [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
         tunnels", RFC 3209, December 2001.
      
         [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions",
         RFC 3473, January 2003.
      
         [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to
         RSVP-TE for point-to-multipoint TE LSPs", draft-dry-mpls-rsvp-te-
         p2mp-00.txt, work in progress.
      
      
      11. Editors' Address:
      
         Jean-Philippe Vasseur
         Cisco Systems, Inc.
         300 Beaver Brook Road
         Boxborough , MA - 01719
         USA
         Email: jpv@cisco.com
      
         Jean-Louis Le Roux
         France Telecom
         2, avenue Pierre-Marzin
         22307 Lannion Cedex
         FRANCE
         Email: jeanlouis.leroux@francetelecom.com
      
      
      Vasseur, Le Roux et al.                                      [Page 11]


      Internet Draft   draft-vasseur-ccamp-te-router-info-00       July 2004
      
      
      
      Full Copyright Statement
      
      Copyright (C) The Internet Society (2004).  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 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.
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Vasseur, Le Roux et al.                                      [Page 12]
      

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