OSPF Working Group                                           JP Vasseur
      Internet Draft                                             Peter Psenak
                                                             Cisco System Inc.
                                                              Seisho Yasukawa
                                                                           NTT
                                                           Jean-Louis Le Roux
                                                                France Telecom
      
      
      
      Category: Standard Track
      Expires: January 2005                                          July 2004
      
      
                    OSPF MPLS Traffic Engineering capabilities
      
                     draft-vasseur-ospf-te-caps-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 specifies OSPF traffic engineering capability TLVs
         related to various MPLS Traffic Engineering capabilities. These OSPF
         TE capability TLVs are carried within the OSPF router information LSA
         (opaque type of 4, opaque ID of 0).
      
      
      Vasseur et al.                                                  [Page 1]


      Internet Draft      draft-vasseur-ospf-te-caps-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. Terminology.....................................................2
         2. Introduction....................................................3
         3. TE Node Capability Descriptor TLV format........................4
         3.1. The DATA-PLANE-CAPABILITY sub-TLV.............................4
         3.2. The CONTROL-PLANE-CAPABILITY sub-TLV..........................5
         4. PCED TLV format.................................................5
         4.1. PCE-ADDRESS sub-TLV...........................................6
         4.2. PCE-CAPABILITY sub-TLV........................................6
         4.3. AS-DOMAIN sub-TLV.............................................8
         5. TE-Mesh-Group TLV format........................................8
         6. Element of procedure............................................9
         6.1. TE-NODE-CAP TLV...............................................9
         6.2. PCED TLV.....................................................10
         6.3. TE-MESH-GROUP TLV............................................12
         7. Interoperability with routers non supporting this capability...12
         8. Security considerations........................................12
         9. Intellectual Property Statement................................12
         9.1. IPR Disclosure Acknowledgement...............................13
         10. References....................................................13
         11. Authors' Address:.............................................14
      
      
      1. 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.
      
            Intra-area TE LSP: TE LSP whose path does not transit across
            areas.
      
      Vasseur et al.                                                [Page 2]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
      
            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).
      
      
      2. Introduction
      
         This document defines OSPF protocol extensions and procedures for
         the advertisement TE node capabilities. A functional description of
         these extensions can be found in [TE-INFO], and is not repeated here.
      
         This document describes the usage of three OSPF TE capabilities TLVs:
         the PCED (PCE Discovery), the TE-MESH-GROUP and the TE-NODE-CAP
         TLVs. These OSPF TE capability TLVs are carried within the OSPF
         router information LSA (opaque type of 4, opaque ID of 0) specified
         in [OSPF-CAP].
      
         Each TE TLV defined in this document (carried in an OSPF router
         information LSA as defined in [OSPF-CAP]) has the following format:
      
           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |              Type             |             length            |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           //                            Value                            //
           |                                                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
         Where
            Type: identifies the TLV type
            Length: length of the value field in octets
      
         The format of the TLV is the same as the TLV format used by the
         Traffic Engineering Extensions to OSPF [OSPF-TE]. The TLV is padded
         to four-octet alignment; padding is not included in the length field
         (so a three octet value would have a length of three, but the total
         size of the TLV would be eight octets).  Nested TLVs are also 32-bit
         aligned.  Unrecognized types are ignored.  All types between 32768
         and 65535 are reserved for vendor-specific extensions.  All other
         undefined type codes are reserved for future assignment by IANA.
      
         Note that a sub-TLV is similar to a TLV: TLV are carried within an
         LSA as sub-TLVs are carried within TLVs. Each sub-TLV describes a
         particular MPLS Traffic Engineering capability. In the rest of this
         document both terms will be used interchangeably.
      
      
      
      
      Vasseur et al.                                                [Page 3]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         The TE-NODE-CAP TLV is used for the advertisement of both control
         plane and data plane TE node capabilities. The TE-NODE-CAP sub-TLV is
         made of a set of non-ordered sub-TLVs each having the format as
         described above.
      
         The PCED TLV is used for the advertisement of Path Computation
         Element Capabilities. The PCED sub-TLV is made of a set
         of non-ordered sub-TLVs each having the format as described above.
      
         The TE-MESH-GROUP TLV is used to advertise the desire to
         join/leave a given MPLS-TE mesh group. The TE-MESH-GROUP sub-TLV does
         not have any sub-TLV currently defined.
      
      
      3. TE Node Capability Descriptor TLV format
      
         This section specifies the sub-TLVs carried within the TE-NODE-CAP
         TLV payload which defines the TE node capabilities.
      
         The TE-NODE-CAP TLV type is 1.
      
         The TE-NODE-CAP TLV is made of various non ordered sub-TLVs.
         Currently two sub-TLVs are defined.
      
            TLV type  Length               Name
               1      variable     DATA-PLANE-CAPABILITY sub-TLV
               2      variable     CONTROL-PLANE-CAPABILITY sub-TLV
      
         Any non recognized sub-TLV MUST be silently ignored.
      
         More sub-TLV could be added in the future to handle new capabilities
      
      
         3.1. The DATA-PLANE-CAPABILITY sub-TLV
      
         The DATA-PLANE-CAPABILITY is a series of bit flags and has a variable
         length.
      
            CODE: 1
            LENGTH: Variable (N*8)
      
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |B|E|                                                           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           //                                                               //
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                                    TE-NODE-CAP sub-TLV format
      
      
         Two bits are currently defined:
      
      Vasseur et al.                                                [Page 4]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
      
         -B bit: When set this indicates that the LSR can act as a branch node
         on a P2MP LSP.
      
         -E bit: When set, this indicates that the LSR can act as a bud LSR on
         a P2MP LSP, i.e. and LSR that is both transit and egress.
      
         See [P2MP-REQ]) and [RSVP-P2MP] for more detail on the usage of these
         bits.
      
         Note that more flags may be defined in the future.
      
      
         3.2. The CONTROL-PLANE-CAPABILITY sub-TLV
      
         The CONTROL-PLANE-CAPABILITY is a series of bit flags and has a
         variable length.
      
             CODE: 2
            LENGTH: Variable (N*8)
      
      
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |M|G|P|                                                          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           //                                                               //
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                                    TE-NODE-CAP sub-TLV format
      
         Currently three flags are defined:
      
         -M bit: If set this indicates that the LSR supports MPLS-TE
         signalling ([RSVP-TE]).
      
         -G bit: If set this indicates that the LSR supports GMPLS signalling
         ([RSVP-G]).
      
         -P bit: If set this indicates that the LSR supports P2MP MPLS-TE
         signalling ([RSVP-P2MP]).
      
         Note that more flags may be defined in the future.
      
      4. PCED TLV format
      
         This section specifies the sub-TLVs carried within the PCED TLV
         payload which define the PCE capabilities.
      
         The PCED TLV type is 2
      
         The PCED TLV is made of various non ordered sub-TLVs defined
      
      Vasseur et al.                                                [Page 5]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         bellow:
      
            TLV type  Length               Name
               1      variable     PCE-ADDRESS sub-TLV
               2        8          PCE-CAPABILITY sub-TLV
               3        8          AS-DOMAIN sub-TLV
      
            Any non recognized sub-TLV MUST be silently ignored.
      
      
         4.1. PCE-ADDRESS sub-TLV
      
         The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach
         the PCE described by this PCED sub-TLV. This address will typically
         be a loop-back address that is always reachable, provided the router
         is not isolated. The PCE-ADDRESS sub-TLV is mandatory.
      
         The PCE-ADDRESS sub-TLV type is 1, length is 4 octets for an IPv4
         address and 20 octets for an IPv6 address, and the value is the PCE
         IPv4 or IPv6 address.
      
            CODE: 1
            LENGTH: Variable (4 or 20)
      
      
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |     address-type              |          Reserved             |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                                               |
             //                       PCE IP address                        //
             |                                                               |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                                  PCE-ADDRESS sub-TLV format
      
            Address-type:
               1   IPv4
               2   IPv6
      
         The PCE-ADDRESS sub-TLV MUST appear exactly once in the PCED sub-TLV
         originated by a router. The only exception is when the PCE has both
         an IPv4 and IPv6 address; in this case, two Path Computation Element
         address sub-TLVs might be inserted: one for the IPv4 address, one for
         the IPv6 address, in this order.
      
         4.2. PCE-CAPABILITY sub-TLV
      
         The PCE-CAPABILITY sub-TLV is used by the PCE to signal its Path
         Computation Element capabilities. This could then be used by an LSR
         to select the appropriate PCE among a list of PCE candidates. This
         sub-TLV is optional.
      
      Vasseur et al.                                                [Page 6]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
      
         The PCE-CAPABILITY sub-TLV type is 2 and the length is 8 octets.
      
            CODE: 2
            LENGTH: 8
      
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                       Reserved                    |D|M|P|A|I|L|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
      
                                 PCE-CAPABILITY sub-TLV format
      
      
         The first 3 bits L, I and A defines the PCE scope for which the
         Path Computation Element 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 ISIS CAPABILITY 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:
         Multi-domain scope. When set, the PCE can perform path computation
         for inter-AS TE LSPs. In this case, the PCED sub-TLV MUST contain one
         or more AS-DOMAIN sub-TLV(s), each describing the domain for which
         the PCE can compute TE LSPs paths having their destination address in
         the respective AS.
      
         Note that those flags are not exclusive (a PCE may set one or more
         flags).
      
         P bit:
         The notion of request priority allows a PCC to specify how urgent the
         request is, by setting a flag in the REQUEST_ID object of the Path
         computation request message. See [PATH-COMP] for more details.
      
         P=1: the PCE takes into account the ¬¬request priority¬¬ in its
         scheduling of the various requests.
         P=0: the PCE does not take the request priority into account.
      
         M bit
         M=1: the PCE is capable of computing more than one path obeying a set
         of specified constraints (in a single pass), provided that they
         exist.
         M=0: the PCE cannot compute more than one path in a single pass
      
      Vasseur et al.                                                [Page 7]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         obeying a set of specified constraints.
      
         D bit
         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. S
         D=1: the PCE is capable of computing diversely (link, node, SRLG)
               routed paths.
         D=0: the PCE is not capable of computing diversely routed paths.
         The D bit is relevant if and only if the M bit has been set to 1. It
         MUST be set to 0 if the M bit is set to 0.
      
         Note that for future capabilities, it may be desirable to introduce
         new flags or may be new sub-TLV to be carried in the PCED capability
         sub-TLV if the capability needs more than just a single flag to be
         described.
      
         4.3. AS-DOMAIN sub-TLV
      
         When the PCE can perform path computation for an inter-AS TE LSP, the
         A bit of the PCE-CAPABILITY sub-TLV MUST be set. Moreover, one or
         more sub-TLVs MUST be included within the PCED sub-TLV, each sub-TLV
         identifying an AS number. Each AS-DOMAIN sub-TLV has the following
         form:
      
            CODE: 3
            LENGTH: 4
      
      
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                           AS Number                           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                                    AS-DOMAIN sub-TLV format
      
         The AS-DOMAIN sub-TLV type is 3, length is 4 octets, and the value is
         the AS number identifying the AS for which the PCE can compute inter-
         AS TE LSP paths (TE LSP having their destination address in this AS).
         When coded on four bytes, the AS Number field MUST have its
         left two bytes set to 0.
      
         The set of AS-DOMAIN sub-TLVs specifies a list of ASes (AS1,à,
         ASn). This means that the PCE can compute TE LSP path such that the
         destination address of the TE LSP belongs to this set of ASes.
      
      
      5. TE-Mesh-Group TLV format
      
         The TE-MESH-GROUP TLV has the following format:
      
      
      
      Vasseur et al.                                                [Page 8]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
            CODE: 3
            LENGTH: Variable (N*8 octets)
      
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                        mesh-group-number                      |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                        Tail-end address                       |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                        Tail-end name                          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           //                                                               //
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                                    TE-MESH-GROUP sub-TLV format
      
            N is the number of mesh-groups.
      
            For each Mesh-group announced by the LSR, the TLV contains:
            - A mesh-group-number: identifies the mesh-group number,
            - A Tail-end address: user configurable IP address to be used as a
            tail-end address by other LSRs belonging to the same mesh-group.
            - A Tail-end name: 32-bits string which facilitates the TE LSP
            identification which can be very useful in inter-area/AS MPLS TE
            environments.
      
      6. Element of procedure
      
         The TLVs defined in this document are carried within an OSPF router
         information opaque LSA (opaque type of 4, opaque ID of 0) as defined
         in [OSPF-CAP].
      
         A router MUST originate a new OSPF router information LSA whenever
         the content of the any of the carried TLV changes or whenever
         required by the regular OSPF procedure (LSA refresh (every
         LSRefreshTime)).
      
         As defined in RFC2370, an opaque LSA has a flooding scope determined
         by its LSA type:
               - link-local (type 9),
               - area-local (type 10)
               - entire OSPF routing domain (type 11). In this case, the
               flooding scope is equivalent to the Type 5 LSA flooding scope.
      
         A router may generate multiple OSPF router information LSAs with
         different flooding scopes.
      
         6.1. TE-NODE-CAP TLV
      
         The TE-NODE-CAP may be carried within a type 10 or 11 router
         information LSA depending on the MPLS Traffic Engineering capability.
         The flooding scope is defined on a per capability basis. Capabilities
      
      Vasseur et al.                                                [Page 9]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         with a identical flooding scope MUST be flooded within the same TE-
         NODE-CAP TLV carried within a router information LSA.
      
         6.2. PCED TLV
      
         The PCED TLV may be carried within a type 10 or 11 router information
         LSA depending on the Path Computation Element scope.
      
            - If the PCE can compute an intra-area TE LSP, the L bit of the
              PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED TLV
              MUST be generated within a Type 10 router information LSA,
      
            - If the PCE can compute an inter-area TE LSP, the I bit of the
              PCE-CAPABILITY TLV of the PCED TLV MUST be set. The PCED TLV
              MUST be generated:
                  - within a Type 10 router information LSA if the PCE can
                    compute an inter-area TE LSP path for the LSRs in the
                    area it is attached to (for instance the PCE is an ABR
                    computing an inter-area TE LSP path for its attached
                    areas)
                   - within a Type 11 router information LSA if the PCE can
                    compute an inter-area TE LSP path for the whole domain.
      
            - If the PCE can compute an inter-AS TE LSP path, the A bit of
              the PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED
              TLV MUST be generated within a Type 11 router information LSA,
      
         Note: if the PCE can compute both intra and inter-area TE LSP
         paths, both the L and I bits of the PCE-CAPABILITY TLV MUST be set.
         The flags are not exclusive. This only applies to the PCED TLV
         carried within the type 10 router information LSA.
      
         If a PCE can compute an intra-area TE LSP and an inter-area or inter-
         AS TE LSP path, it MUST originate:
               - a type 10 OSPF router information LSA with a PCED TLV having
                 the L, I and A flags of its PCE-CAPABILITY TLV set as
                 described above.
               - a type 11 OSPF router information LSA with a PCED TLV having
                 L=0 and the I and A flags of its PCE-CAPABILITY TLV set as
                 described above.
      
            Example
      
            <-----------------AS1----------------->
      
            <---area 1--><----area 0-----><-area 2->
      
         R1---------ABR1*------------ABR3*-----|                 ------------
          |           |                |       |                 |          |
          |     S1    |      S2        |     ASBR1*--eBGP--ASBR2-|    AS2   |
          |           |                |       |                 |          |
         R2---------ABR2*------------ABR4------|                 ------------
      
      Vasseur et al.                                               [Page 10]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
      
      
         The areas contents are not detailed.
      
         Assumptions:
         - area 1 and area 2 are regular areas
         - the * indicates a Path Computation Element capability
         - ABR1 is a PCE for area 1 only
         - ABR2 is a PCE for intra and inter-area TE LSP path computation in
         area 0 and 1
         - ABR3 is a PCE for only inter-area TE LSP path computation for the
         whole domain,
         - S1 is a PCE for area 1 only
         - S2 is a PCE for the whole domain,
         - ASBR1 is a PCE for inter-AS TE LSPs whose destination resides in
         AS2 (not for intra or inter-area area TE LSPs).
      
         In the example above:
         - S1 originates a type 10 router information LSA with a PCED TLV such
         that:
              o The L bit of the PCE-CAPABILITY TLV is set,
              o The I and A bits of the PCE-CAPABILITY TLV are cleared.
      
         - ABR1 originates in area 1 a type 10 router information LSA with a
         PCED TLV such that:
              o The L bit of the PCE-CAPABILITY TLV is set,
              o The I and A bits of the PCE-CAPABILITY sub-TLV are cleared,
      
         - ABR2 originates in both area 0 and 1 a type 10 router information
         LSA with a PCED TLV such that:
              o The L and I bits of the PCE-CAPABILITY TLV are set,
              o The A bit of the PCE-CAPABILITY TLV  is cleared
      
         - ABR3 originates a type 11 router information LSA with a PCED TLV
          such that:
              o The L bit of the PCE-CAPABILITY TLV is cleared,
              o The I bit of the PCE-CAPABILITY TLV is set,
              o The A bit of the PCE-CAPABILITY TLV is cleared,
      
         - S2 originates:
               - in area 0 a type 10 router information LSA with a PCED TLV
                 such that:
                     o The L and I bits of the PCE-CAPABILITY sub-TLV are
                       set,
                     o The A bit of the PCE-CAPABILITY TLV  is cleared,
               - a type 11 router information LSA with a PCED TLV such that:
                      o The L bit of the PCE-CAPABILITY TLV is cleared,
                      o The I bit of the PCE-CAPABILITY TLV is set,
                      o The A bit of the PCE-CAPABILITY TLV is cleared,
      
         - ASBR1 originates a type 11 router information LSA with a PCED TLV
         such that:
      
      Vasseur et al.                                               [Page 11]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
              o The L bit and the I bit of the PCE-CAPABILITY TLV are cleared,
              o The A bit of the PCE-CAPABILITY TLV set,
              o One AS-DOMAIN TLV within the PCED TLV with AS number = AS2
      
         The receipt of a new router information LSA carrying a PCED TLV never
         triggers an SPF calculation.
      
         When an LSR or a Path Computation Element is newly configured as a
         PCE, the corresponding router information LSA MUST be immediately
         flooded.
      
         When a PCE capability changes, the corresponding router information
         LSA MUST be immediately flooded.
      
         When a PCE looses its Path Computation Element capability, the
         corresponding router information LSA MUST be immediately flooded with
         LS age = MaxAge.
      
         6.3. TE-MESH-GROUP TLV
      
         The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router
         information LSA depending on the MPLS TE mesh-group profile:
      
             - If the MPLS TE mesh-group is contained within a single area
               (all the LSRs have their head-end and tail-end LSR within the
               same OSPF area), the TE-MESH-GROUP TLV MUST be generated
               within a Type 10 router information LSA,
             - If the MPLS TE mesh-group spans multiple OSPF areas, the TE-
               MESH-GROUP TLV MUST be generated within a Type 11 router
               information LSA,
      
      7. Interoperability with routers non supporting this capability
      
         There is no interoperability issue as a router not supporting the TE-
         NODE-CAP, PCED or TE-MESH-GROUP TLVs SHOULD just silently discard
         those TLVs as specified in RFC2370.
      
      8. Security considerations
      
       No new security issues are raised in this document.
      
      9. 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.
      
      
      Vasseur et al.                                               [Page 12]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         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..
      
         9.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.
      
      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.
      
         [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
         Extensions to OSPF Version 2", RFC 3630, September 2003.
      
         [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-02.txt, work in progress.
      
         [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions
         for discovery of TE router information", draft-vasseur-ccamp-te-
         router-info-00.txt, work in progress.
      
         Informative References
      
         [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.
      
      
      Vasseur et al.                                               [Page 13]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         [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.
      
         [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. Authors' Address:
      
         Jean-Philippe Vasseur (Editor)
         Cisco Systems, Inc.
         300 Beaver Brook Road
         Boxborough , MA - 01719
         USA
         Email: jpv@cisco.com
      
         Peter Psenak
         CISCO Systems, Inc.
         Pegasus Parc
         De Kleetlaan 6A
         1831, Diegem
         BELGIUM
         Email: ppsenak@cisco.com
      
         Seisho Yasukawa
         NTT Network Service Systems Laboratories, NTT Corporation
         9-11, Midori-Cho 3-Chome
         Musashino-Shi, Tokyo 180-8585 Japan
         Phone: + 81 422 59 4769
         Email: yasukawa.seisho@lab.ntt.co.jp
      
         Jean-Louis Le Roux
      
      Vasseur et al.                                               [Page 14]


      Internet Draft      draft-vasseur-ospf-te-caps-00           July 2004
      
      
      
         France Telecom
         2, avenue Pierre-Marzin
         22307 Lannion Cedex
         FRANCE
         Email: jeanlouis.leroux@francetelecom.com
      
      
      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 et al.                                               [Page 15]