Networking Working Group                                JP. Vasseur (Editor) Vasseur, Ed.
Internet-Draft                                        Cisco Systems, Inc
Expires: August 9, 2006
Intended status: Standards Track                         JL. Leroux (Editor) Leroux, Ed.
Expires: March 4, 2007                                    France Telecom
                                                             S. Yasukawa
                                                                     NTT
                                                              S. Previdi
                                                               P. Psenak
                                                      Cisco Systems, Inc
                                                               P. Mabbey
                                                                 Comcast
                                                        February 5,
                                                         August 31, 2006

 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch
         Router (LSR) Traffic Engineering (TE) mesh membership

                    draft-ietf-ccamp-automesh-01.txt
                    draft-ietf-ccamp-automesh-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

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

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

   This Internet-Draft will expire on August 9, 2006. March 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
   Traffic Engineering (TE) Label Switched Path Paths (LSP) among a set of
   Label Switch Routers (LSR) is common deployment scenario of MPLS
   Traffic Engineering either for bandwidth optimization, bandwidth
   guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
   may require the configuration of potentially a large number of TE
   LSPs (on the order of the square of the number LSRs).  This document
   specifies IGP routing extensions for ISIS and OSPF so as to provide
   an automatic discovery of the set of LSRs members of a mesh in order
   to automate the creation of such mesh.

Requirements Language

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

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  TE Mesh-Group  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Description  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Required Information . . . . . . . . . . . . . . . . . . .  5
   4.  TE-MESH-GROUP TLV formats  . . . . . . . . . . . . . . . . . .  5
     4.1.  OSPF TE-MESH-GROUP TLV format  . . . . . . . . . . . . . .  5
     4.2.  IS-IS TE-MESH-GROUP TLV sub-TLV format . . . . . . . . . . . . . .  8
   5.  Elements of procedure  . . . . . . . . . . . . . . . . . . . . 10
     5.1.  OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Backward compatibility . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 16 15

1.  Terminology

   Terminology used in this document

   LSR: Label Switch Router.

   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 IS-IS level.

2.  Introduction

   There are two well-known approaches in deploying MPLS Traffic
   Engineering:

   (1) The so-called "strategic" approach that consists of setting up a
   full mesh of TE LSPs between a set of LSRs,

   (2) The so-called "tactical" approach where a set of TE LSPs are
   provisioned on well identified "hot spots" in order to alleviate a
   congestion resulting for instance from an unexpected traffic growth
   in some parts of the network.

   The set up of a full mesh of TE LSPs among a set of LSRs is a common
   deployment scenario of MPLS Traffic Engineering either for bandwidth
   optimization, bandwidth guarantees or fast rerouting with MPLS Fast
   Reroute.  Setting up a full mesh of TE LSPs between N LSRs requires
   the configuration of a potentially large number of TE LSPs (O(N^2)).
   Furthermore, the addition of any new LSR in the mesh requires the
   configuration of N additional TE LSPs on the new LSR and one new TE
   LSP on every LSR of the existing mesh destined to this new LSR, which
   gives a total of 2*N TE LSPs to be configured.  Such operation is not
   only time consuming but also a risky operation (prone to
   misconfiguration) for Service Providers.  Hence, an automatic
   mechanism for setting up TE LSPs meshes is desirable and requires the
   ability to automatically discover the LSRs that belong to the mesh.
   This document specifies routing extensions so as to automatically
   discover the members of a mesh, also referred to as a "TE mesh-
   group".  Note that the mechanism(s) needed for the dynamic creation
   of TE LSPs is implementation specific and outside the scope of this
   document.

   Routing extensions have been defined in [I-D.ietf-ospf-cap] and
   [I-D.ietf-isis-caps] in order to advertise router capabilities.  This
   document specifies IGP (OSPF and IS-IS) TE Mesh Group TLVs allowing
   for the automatic discovery of a TE LSP mesh members, to be carried
   in the OSPF Router Information LSA [I-D.ietf-ospf-cap] and ISIS
   Router Capability TLV [I-D.ietf-isis-caps].  The routing extensions
   specified in this document provide the ability to signal multiple TE
   mesh groups.  An LSR may belong to one or more than one TE mesh-group(s). mesh-group.

3.  TE Mesh-Group

3.1.  Description

   A TE mesh-group is defined as a group of LSRs that are connected by a
   full mesh of TE LSPs.  Routing extensions are specified in this
   document allowing for dynamic discovery of the TE mesh-group members.
   Procedures are also specified for a member to join and leave a TE
   mesh-group.

3.2.  Required Information

   This document specifies a TE-MESH-GROUP TLV that indicates the set of
   TE mesh-group(s) an LSR belongs to.  For each TE mesh-group
   membership announced by an LSR, the TE-MESH-GROUP TLV advertises the
   following information:

   - A mesh-group number identifying the TE mesh-group the LSR belongs
   to.

   - A Tail-end address (used as the TE LSP tail-end address by other
   LSRs belonging to the same mesh-group).

   - A Tail-end name: string used to ease the TE-LSP naming.

4.  TE-MESH-GROUP TLV formats

4.1.  OSPF TE-MESH-GROUP TLV format
   the OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information
   LSA defined in [I-D.ietf-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                            //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1 - OSPF TE-MESH-GROUP TLV format
   Where
      Type: identifies the TLV type
      Length: length of the value field in octets

   The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV
   format used by the Traffic Engineering Extensions to OSPF
   (see[RFC3630]).  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.

   The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to
   join/leave a given TE mesh-
   group. mesh-group.  No sub-TLV is currently defined
   for the TE-mesh-group TLV.

   The TE-MESH-GROUP TLV has the following format:
   TYPE: To be assigned by IANA (Suggested Value: 3)
   LENGTH: Variable

      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 IPv4 address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Name length  |               Tail-end name  (NULL padded display string)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                               //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)

   TYPE: To be assigned by IANA (Suggested Value: 4)
   LENGTH: Variable

      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 IPv6 address                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Name length  |               Tail-end name  (NULL padded display string)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                               //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address)

   For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV
   comprises:

   - A mesh-group-number that identifies the mesh-group number

   - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
   tail-end TE LSP address by other LSRs belonging to the same mesh-
   group

   - A Tail-end name: a variable length field used to facilitate the TE
   LSP identification.  The Name length field indicates the length of
   the display string before padding, in bytes.

4.2.  IS-IS TE-MESH-GROUP TLV sub-TLV format

   The IS-IS TE-MESH-GROUP TLV sub-TLV (advertised in the IS-IS CAPABILITY
   TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the
   type, 1 octet specifying the TLV length and a value field.  The
   format of the TE-MESH-GROUP TLV sub-TLV is identical to the TLV format
   used by the Traffic Engineering Extensions for IS-IS [RFC3784].  The TE-
   MESH-GROUP TLV
   TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR to join/
   leave
   join/leave a given TE mesh-group.  No sub-TLV is currently defined
   for the TE-MESH-GROUP TLV. sub-TLV.

   The ISIS TE-MESH-GROUP TLV sub-TLV has the following format:
   TYPE: To be assigned by IANA (Suggested value: 3).
   LENGTH: Variable

      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 IPv4 address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Name length  |             Tail-end name  (NULL padded display string)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                               //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 4 - ISIS TE-MESH-GROUP TLV sub-TLV format (IPv4 Address)

   TYPE: To be assigned by IANA (Suggested Value: 4)
   LENGTH: Variable

      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 IPv6 address                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Name length  |              Tail-end name  (NULL padded display string)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                               //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 5 - ISIS TE-MESH-GROUP TLV sub-TLV format (IPv6 Address)

   For

   The OSPF TE-MESH-GROUP TLV and the ISIS TE-MESH-GROUP sub-TLV may
   contain one or more mesh-group entries where each entry correspond to
   a TE mesh-group announced by the LSR, and is made of the TE-MESH-GROUP TLV
   comprises: following fields:

   - A mesh-group-number that identifies the mesh-group number number,

   - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
   tail-end TE LSP address by other LSRs belonging to the same mesh-
   group
   group,
   - A Tail-end name: a variable length field used to facilitate the TE
   LSP identification.  The Name length field indicates the length of
   the display string before padding, in bytes.

5.  Elements of procedure

   The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing
   Information LSA or and the TE-MESH-GROUP sub-TLV is caried within the
   ISIS Router capability TLV.  As such, elements of procedure are
   inherited from those defined in [I-D.ietf-ospf-cap] and
   [I-D.ietf-isis-caps] for OSPF and ISIS respectively.  Specifically, a
   router MUST originate a new LSA/LSP whenever the content of this
   information changes, or whenever required by regular routing
   procedure (e.g. refresh).  The TE-MESH-GROUP TLV is OPTIONAL and must MUST
   at most appear once in a OSPF Router Information LSA or ISIS Router
   Capability TLV.  If the OSPF TE-MESH-GROUP TLV occurs more than once
   within the OSPF Router Information LSA, only the first instance is
   processed, subsequent TLV(s) will be silently ignored.  Similarly, If
   the ISIS TE-MESH-GROUP sub-TLV occurs more than once within the ISIS
   Router capability TLV, only the first instance is processed,
   subsequent TLV(s) will be silently ignored.

5.1.  OSPF

   The TE-MESH-GROUP TLV is advertised within an OSPF Router Information
   opaque LSA (opaque type of 4, opaque ID of 0) as defined in
   [I-D.ietf-ospf-cap].

   A router MUST originate a new OSPF router information LSA whenever
   the content of the any of the advertised TLV changes or whenever
   required by the regular OSPF procedure (LSA refresh (every
   LSRefreshTime)).  If an LSR desires to join or leave a particular TE
   mesh group, it MUST originate a new OSPF Router Information LSA
   comprising the updated TE-MESH-GROUP TLV.  In the case of a join, a
   new entry will be added to the TE-MESH-GROUP TLV; conversely, if the
   LSR leaves a mesh-group the corresponding entry will be removed from
   the TE-MESH-GROUP TLV.  Note that both operations can be performed in
   the context of a single refresh.  An implementation SHOULD be able to
   detect any change to a previously received TE-MESH-GROUP TLV from a
   specific LSR.

   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.  The TE-MESH-GROUP TLV may be advertised 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 of the mesh-group are contained within a single 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.

   It is expected that the number of mesh-groups and consequently the
   number of TE-MESH-GROUP TLVs advertised within a Routing Information
   LSA will be very limited (to at
   most 10 or so).  Moreover, TE mesh-
   group mesh-group membership is fairly static
   and should not change frequently.

5.2.  ISIS

   The TE-MESH-GROUP TLV sub-TLV is advertised within the IS-IS Router
   CAPABILITY TLV defined in [I-D.ietf-isis-caps].  An IS-IS router MUST
   originate a new IS-IS LSP whenever the content of the any of the
   advertised sub-TLV changes or whenever required by regular IS-IS
   procedure (LSP refresh).  If an LSR desires to join or leave a
   particular TE mesh group, it MUST originate a new LSP comprising the
   refreshed ISIS Router capability TLV comprising the updated TE-MESH-
   GROUP TLV. sub-TLV.  In the case of a join, a new entry will be added to
   the TE-MESH-GROUP TLV; sub-TLV; conversely, if the LSR leaves a mesh-group
   the corresponding entry will be deleted to from the TE-MESH-GROUP sub-
   TLV.  Note that both operations can be performed in the context of a
   single refresh.  An implementation SHOULD be able to detect any
   change to a previously received TE-MESH-GROUP TLV sub-TLV from a specific
   LSR.

   If the flooding scope of an MPLS Traffic Engineering capability is
   limited to an IS-IS level/area, the TLV sub-TLV MUST not be leaked across
   level/area and the S flag of the Router CAPABILITY TLV MUST be
   cleared.  Conversely, if the flooding scope of an MPLS Traffic
   Engineering capability is the entire routing domain, the TLV MUST be
   leaked across IS-IS levels/areas, and the S flag of the Router
   CAPABILITY TLV MUST be set.  In both cases the flooding rules
   specified in [I-D.ietf-isis-caps] apply.

   As specified in [I-D.ietf-isis-caps], a router may generate multiple
   IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different
   flooding scopes.

   It is expected that the number of mesh groups and consequently the
   number of TE-MESH-GROUP TLV advertised within an ISIS Router
   Capability TLV TE mesh-groups will be very limited
   (to at most 10 or so).  Moreover, TE mesh-group membership is fairly
   static and should not change frequently.

6.  Backward compatibility

   The TE-MESH-GROUP TLVs defined in this document do not introduce any
   interoperability issue.  For OSPF, a router not supporting the TE-
   MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in
   [RFC2370].  For IS-IS a router not supporting the TE-MESH-GROUP sub-
   TLV SHOULD just silently ignore the TLV. sub-TLV.

7.  IANA Considerations

   OSPF

   IANA will assign new OSPF TLV code-point for the newly defined TE-
   MESH-GROUP TLVs carried within the Router Information LSA.

   TE-MESH-GROUP TLV (IPv4) (suggested value=3)

   TE-MESH-GROUP TLV (IPv6) (suggested value=4)

   ISIS

   IANA will assign new ISIS TLV code-point for the newly defined TE-
   MESH-GROUP TLVs sub-TLVs carried within the ISIS Router Capability TLV.

   TE-MESH-GROUP TLV (IPv4) (suggested value=3)

   TE-MESH-GROUP TLV (IPv6) (suggested value=4)

8.  Security Considerations

   No new security issues are raised in this document.

9.  Acknowledgements

   We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec
   and Louedec,
   Dave Ward Ward, Les Ginsberg and Stephen Nadas for their useful comments.

10.  References

10.1.  Normative References

   [I-D.ietf-isis-caps]
              Vasseur, J., "IS-IS Extensions for Advertising Router
              Information", draft-ietf-isis-caps-06 (work in progress),
              January 2006.

   [I-D.ietf-ospf-cap]
              Lindem, A., "Extensions to OSPF for Advertising Optional
              Router Capabilities", draft-ietf-ospf-cap-08 (work in
              progress), December 2005.

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

   [RFC2370]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
              July 1998.

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

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.

10.2.  Informative References

   [OSPF-TE]  Katz, et al., RFC 3630, "Traffic Engineering (TE)
              Extensions to OSPF Version 2", September 2003.

   [PCE-DISCO]
              J.L Le Roux, JP Vasseur et al,
              draft-ietf-pce-disco-proto-igp (work in progress)., "IGP
              protocol extensions for Path Computation Element (PCE)
              Discovery", May .

Authors' Addresses

   JP Vasseur (Editor) (editor)
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Email: jpv@cisco.com
   JL Le Roux (Editor) (editor)
   France Telecom
   2, Avenue Pierre-Marzin
   Lanion,   22307
   FRANCE

   Email: jeanlouis.leroux@francetelecom.com

   Seisho Yasukawa
   NTT
   9-11, Midori-Cho 3-Chome
   Tokyo,   180-8585
   JAPAN

   Email: yasukawa.seisho@lab.ntt.co.jp

   Stefano Previdi
   Cisco Systems, Inc
   Via Del Serafico 200
   Roma,   00142
   Italy

   Email: sprevidi@cisco.com

   Peter Psenak
   Cisco Systems, Inc
   Pegasus Park DE Kleetlaan 6A
   Diegmen,   1831
   BELGIUM

   Email: ppsenak@cisco.com

   Paul Mabbey
   Comcast
   USA

   Email:

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).