Internet DRAFT - draft-li-pce-hierarchical-pce-p2mp-path

draft-li-pce-hierarchical-pce-p2mp-path






Internet Engineering Task Force                                    K. Li
Internet-Draft                                                     X. Tu
Intended status: Standards Track                                   Z. Fu
Expires: July 3, 2012                                    ZTE Corporation
                                                       December 31, 2011


  Hierachical PCE Extensions for Inter-Domain Point-to-Multipoint Path
                              Computation
               draft-li-pce-hierarchical-pce-p2mp-path-00

Abstract

   The hierachical Path Computation Element (PCE) architecture defined
   in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be
   selected, and the optimum end-to-end path to be derived through the
   use of a hierarchical relationship between domains.

   This document defines the hierachical PCE (H-PCE) extensions for the
   purpose of implementing inter-domain P2MP Path Computation.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Li, et al.                Expires July 3, 2012                  [Page 1]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



































Li, et al.                Expires July 3, 2012                  [Page 2]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Architectural Protocol Overview  . . . . . . . . . . . . . . .  6
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Child PCE Responsibility . . . . . . . . . . . . . . . . .  7
     3.3.  Parent PCE Responsibility  . . . . . . . . . . . . . . . .  7
     3.4.  Multi-layer H-PCE  . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Inter-domain TE Link . . . . . . . . . . . . . . . . . . .  9
   4.  Messages Format  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  PCReq Message  . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  PCRep Message  . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.  PCNtf Message  . . . . . . . . . . . . . . . . . . . . . . 12
     4.4.  PCErr Message  . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Object Format  . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Inter-domain Capability Advertisement  . . . . . . . . . . 15
     5.2.  Preserving Topology Confidentiality  . . . . . . . . . . . 15
     5.3.  Extensions to END-POINTS Object  . . . . . . . . . . . . . 15
     5.4.  PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 17
     5.5.  Extensions to Unreach-Destination Object . . . . . . . . . 17
     5.6.  OPEN Object  . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 20
     6.2.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22






















Li, et al.                Expires July 3, 2012                  [Page 3]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


1.  Introduction

   [RFC4655] describes the motivations and architecture for a Path
   Computation Element (PCE) based model for the computation of
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Traffic Engineering Label Switched Paths (TE LSPs).
   [PCE-HIERARCHY-FWK] defined a hierachical Path Computation Element
   (H-PCE) architecture allows the optimum sequence of domains to be
   selected, and the optimum end-to-end inter-domain path to be derived
   through the use of a hierarchical relationship between domains.

   This document specifies the inter-domain P2MP path computation
   methods.  Inter-domain P2MP is comprised of multiple source-to-leaf
   sub-LSPs.  These S2L sub-LSPS are set up between the ingress and
   egress LSRs, and may located in different domain or autonomous
   system.



































Li, et al.                Expires July 3, 2012                  [Page 4]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


2.  Terminology

   AS: Autonomous System, A collection of connected routing prefixes
   under the control of one or more network operators that presents a
   common, clearly defined routing policy to the Internet.

   ASBR: Autonomous System Border Router.  Routers used to connect
   together ASes of the same or different service providers via one or
   more inter-AS links.

   BN: Boundary Node, A boundary node is either an ABR in the context of
   inter-area Traffic Engineering or an ASBR in the context of inter-AS
   Traffic Engineering.

   Child PCE: A PCE responsible for computing the path across one or
   more specific (child) domains.  A child PCE maintains a relationship
   with at least one parent PCE.

   Parent PCE: A PCE responsible for selecting a path across a parent
   domain and any number of child domains by coordinating with child
   PCEs and examining a topology map that shows domain inter-
   connectivity.

   PCC: Path Computation Client.  Any client application requesting a
   path computation to be performed by a Path Computation Element.

   PCE: Path Computation Element.  An entity that is capable of
   computing a network path or route based on a network graph and
   applying computational constraints.

   H-PCE: Hierarchical PCE.  A parent PCE maintains a domain topology
   map that contains the child domains and their interconnections (links
   in the topology).

   Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a
   path.

   Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a
   path.












Li, et al.                Expires July 3, 2012                  [Page 5]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


3.  Architectural Protocol Overview

3.1.  Overview

   This docment provids a method which uses H-PCE to compute an optimal
   P2MP path.  The parent PCE floods path computation requests from the
   ingress domain which contains the ingress node to adjacent domains,
   child PCE which serves the domain receives the path computation
   requests, finishes the computation and replys the results to the
   parent PCE.  After computation of all domains, the parent PCE
   completes the path computation of the whole P2MP tree.  Procedure is
   as follows:

   1.  PCC sends P2MP path computation request to child PCE.  The
       request message must contain information of leaf nodes, type and
       other attributes of the P2MP tree.

   2.  Child PCE find that the message is a inter-domain P2MP path
       computation request, and transmits it to its parent PCE.

   3.  The parent PCE treats the ingress domain which contains the
       ingress node of the inter-domain P2MP tree as currently
       processing domain, and treats the ingress node as root node, the
       BNs of this domain and leaf nodes in this domain as leaf nodes,
       then the parent PCE sents a path computation request to a child
       PCE which serves the domain.

   4.  The child PCE which receives the path computation request from
       the parent PCE will select a optimal path computation request to
       compute path to every leaf nodes and finally reply optimized
       computation results to the parent PCE.

   5.  The parent PCE receives path segments computation results,
       combines these results into a P2MP path tree, this P2MP tree's
       root is ingress node and leaf nodes are BNs of the domain and
       leaf nodes of this trees that have been computed.  Then the
       parent PCE decides next domains need to be flooded and sends path
       computation requests to them.

   6.  The corresponding child PCEs that receive the path computation
       requests from the parent PCE process as step 4.

   7.  If the path segments computation results is null, or if there
       isn't any next domain need to be flooded, then current path
       computation is completed, the parent PCE should repond the
       completed inter-domain P2MP path to its child PCE.  Otherwise,
       the parent PCE should send path computation requests to child
       PCEs in next domains, just as process in step 5.



Li, et al.                Expires July 3, 2012                  [Page 6]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   8.  Child PCEs reply the ultimately path computation result to PCC.

3.2.  Child PCE Responsibility

   Each child PCE is responsible for one domain, computing path segment
   in the domain and replying computation result to its parent PCE.
   Child PCE's main work is detailed as follows.

   Child PCE should receive path computation request which is sent by
   PCC, and decide the path computation request, if the path is inter-
   domain type, then child PCE should transmit the path computation
   request to its parent PCE.  Child PCE then receive path segment
   computation request, according to content of the request message,
   compute path segment in the domain, and reply optimal result to its
   parent PCE.  Child PCE should receive path computation result from
   its parent PCE, and transmit it to PCC.

   In the actual network application scenario, the connection among
   domains may be very complex, especially when the connection among
   domains is full mesh.  So child PCE may receive more than one path
   computation requests.  When child PCE receives more than one
   requests, it should process those requests according to following
   rules.

   If child PCE receives more than one path computation requests for a
   number of different root nodes in the same flooding process, the
   child PCE should compute path for each request, then decide all the
   computation results and give an optimal sub-S2L LSP for each leaf
   node, reply those results to its parent PCE.  If child PCE receives
   more than one path computation requests for a number of different
   root nodes in different flooding processes, the child PCE only need
   to process latest request and reply computation result to its parent
   PCE.  If child PCE receives more than one path computation requests
   for the same root node in the same flooding process, the child PCE
   only need to process the request which has the smallest cost to root
   node, and reply computation result to its parent PCE.  If child PCE
   receives more than one path computation requests for the same root
   node in different flooding processes, the child PCE should decide
   cost to root node in the later received path computation request is
   smaller; if yes, the child PCE should re-compute path to each leaf
   node and reply computation result to its parent PCE.

3.3.  Parent PCE Responsibility

   Parent PCE is mainly responsible for flooding path computation
   requests to neighbor domains, summarizing path computation results
   from its child PCEs, and deciding the whole computation process.
   First, parent PCE receives inter-domain path computation request



Li, et al.                Expires July 3, 2012                  [Page 7]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   which is sent by its child PCE, finds the domain that has ingress
   node of the P2MP tree that to be computed, finds ingress nodes(BNs)
   and leaf nodes of this domain, then sends path segment computation
   request to this child PCE.  After sending the computation request,
   parent PCE should wait for computation result from child PCE, and
   decide next neighbor domains that should be flooded, find ingress
   nodes and leaf nodes of those domains, send path segment computation
   requests to them.

   If parent PCE decides the path computation is complete, it should end
   the computation process and send result to the child PCE which
   request inter-domain path computation.

   In complex scenario, parent PCE maybe receive different computation
   results from the same child PCE, then parent PCE should process those
   results according to following rules.

   For each BN, parent PCE should decide if the cost to the BN in the
   later received computation result is better than cost value exists in
   parent PCE; if so, parent PCE should flood the BN's neighgor domains
   in next flooding process; otherwise, parent PCE should desert the
   later received computation result without any further process.  In
   each flooding process to next domains, parent PCE should first
   estimate the entry BN of next domains haven't been flooded; if so,
   parent PCE continue to send computation requests to next domains;
   otherwise, parent PCE shouldn't send any request to next domains, and
   parent PCE only need to update corresponed cost values in parent PCE.
   After that, parent PCE should decide again that if is there need to
   send computation requests to the next domain's next domains.

   If every possible path of each domains has been computed, or if there
   isn't better result given by child PCE, parent CPE can decide the
   path computation is complete.

3.4.  Multi-layer H-PCE

   H-PCE may have more than two layers in actual scenario, it could nest
   more layers, neighbor layers are parent and child, such as Figure 1.













Li, et al.                Expires July 3, 2012                  [Page 8]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


                                                      +----+
                                                    --|PCE3|
                                                   /  +----+
                                          +----+  /
                                       -- |PCE2|--
                                      /   +----+
                             +----+  /
                          -- |PCE1|--
                        /    +----+
                +---+  /
                |PCC|--
                +---+


                    Figure 1: Multi-Layer H-PCE Example

   In Figure 1, there are three layers.  For one PCE layer, it treats
   its up PCE as parent PCE and treats its down layer as PCC. it only
   has communication with its up layer.  For PCE1 in Figure 1, PCE2 is
   parent PCE, when PCE1 receives path computation request from PCC, it
   will transmit the request to parent PCE(i.e.  PCE2).  For PCE2 in
   Figure 1, it treats PCE1 as PCC, and treats PCE3 as parent PCE, when
   it receives path computation request from PCE1, it will transmit the
   request to parent PCE(i.e.  PCE3).If PCE3 receives path computation
   request, it will send intra-domain path computation request to
   PCE2(PCE3's child PCE), and PCE2 will break down the request and send
   new request to PCE1(PCE2's child PCE).  Then, PCE1 will compute path
   and reply to PCE2.

3.5.  Inter-domain TE Link

   BNs of different domains are connected through TE link, such as:


                        --------- Transit ---------
                        |Domain1|---------|Domain2|
                        ---------  Link   ---------


                         Figure 2: TE Link Example

   When PCE computes path of a P2MP tree, parent PCE should consider
   attributes of TE link as constraints.








Li, et al.                Expires July 3, 2012                  [Page 9]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


4.  Messages Format

4.1.  PCReq Message

   The PCEP Path Computation Request message (PCReq Message) is a PCEP
   message sent by a PCC or PCE to request a path computation.  A PCReq
   message may carry more than one path computation request.  As in
   inter-domain scene, the overlap of addressing space should be
   considered, and it should use the newly defined END-POINTS object as
   in section 5.3.

   Also, the request message must contain the cost which the ingress
   node(or what we called root node of the P2MP path) associated, so
   there is a METRIC-LIST object followed each END-POINTS object.

   PCReq Message format defined as follows:


       <PCReq Message>::= <Common Header>
                   [<SVEC-list>]
                   <request-list>
       where:
       <svec-list>::=<SVEC>[<svec-list>]
       <request-list>::=<request>[<request-list>]

       For supporting of PATH-KEY, <request> defined as follows:
       <request>::= <RP>
                   <segment-computation> | <path-key-expansion>

       <segment-computation>::= <end-point-rro-pair-list>
                   [<OF>]
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<IRO>]
                   [<LOAD-BALANCING>]

       <path-key-expansion>::= <PATH-KEY>

       where:
       <end-point-rro-pair-list>::= <END-POINTS>
                   <metirc-list>
                   [<RRO-List>][<BANDWIDTH>]
                   [<end-point-rro-pair-list>]

       <RRO-List> ::= <RRO>[<BANDWIDTH>][<RRO-List>]
       <metric-list> ::= <METRIC>[<metric-list>]




Li, et al.                Expires July 3, 2012                 [Page 10]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   Extension to [PCE-HIERARCHY-FWK], PCReq Message can be send by PCC to
   child PCE to initialize a inter-domain p2mp path computation, and can
   be transfered by child PCE to parent PCE, and parent PCE can also
   send PCReq message to child PCE for the inner domain sub path result.

   For supporting of preserving topology confidentiality between each
   domain, request object is extended to support Path-Key mechanism.
   The usage is specified in [RFC5520]

4.2.  PCRep Message

   The PCEP Path Computation Reply message (PCRep Message) is a PCEP
   message in response to a previously received PCReq message.  A PCRep
   message may contain a set of computed paths corresponding to either a
   single path computation request or multiple path computation
   requests, each computed path must followed by a METRIC object to
   indicate the path's cost.

   Because of it should preserving topology information leak into other
   domain, when child PCE reply P2MP path segment to parent PCE, the
   PATH object should use loose hops, or Path-Key described in [RFC5520]

   The PCRep message format defined as follows:




























Li, et al.                Expires July 3, 2012                 [Page 11]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


       <PCRep Message>::= <Common Header>
                   <response-list>
       where:
       <response-list>::= <response>[<response-list>]
       <response>::=<RP>
                   [<NO-PATH>]
                   [<attribute-list>]
                   [<end-point-path-pair-list>]

       where:
       <end-point-path-pair-list>::= [<END-POINTS>]
                   <path> | <path-key-expansion>
                   [<end-point-path-pair-list>]

       <path>::= (<ERO>|<SERO>)
                   <metric>
                   [<path>]

       <path-key-expansion> ::= <PATH-KEY>
                   <metric>
                   [<path-key-expansion>]

       <attribute-list>::=[<OF>]
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<IRO>]


   Note that we add Metric object after each ERO/SERO and PATH-KEY
   object.  At least one instance of Metric MUST BE present in each path
   or path-key-expansion.

4.3.  PCNtf Message

   The PCNtf Message is send by a PCC or a PCE to notify of a specific
   event.  The PCNtf Message MUST carry at least one NOTIFICATION
   object.

   The format of NOTIFICATION object is as follows:











Li, et al.                Expires July 3, 2012                 [Page 12]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Reserved    |     Flags     |      NT       |     NV        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      Optional TLVs                          //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 3: NOTIFICATION Object Body Format

   We need to add new notification types in inter-domain scene, which
   defined as follows:

   Notification-type=3, Notification-value=1: Parent PCE update request
   metric to child PCE.  It indicates that parent PCE wants to inform a
   child PCE that the path computation request before should update the
   metric contains in the message.  Such an event could be triggered
   when the parent PCE request child PCE to computate a P2MP path
   segment, but have not return the result yet, parent PCE can use this
   NOTIFICATION object to renew the child PCE's metric, when child PCE
   reply the last result, it can do the path computation according to
   newest metric.

4.4.  PCErr Message

   The PCErr message is sent by a PCC or a PCE in response to a request
   or in an unsolicited manner.  A PCErr message MUST contain a PCEP-
   ERROR object specifying the PCEP error condition.  The PCEP-ERROR
   object is defined as follows (defined in [RFC5440]):


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Reserved    |      Flags    |   Error-Type  |  Error-value  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                     Optional TLVs                           //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 4: PCEP-ERROR Object Body Format

   For each PCEP error, an Error-Type and an Error-value are defined.



Li, et al.                Expires July 3, 2012                 [Page 13]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   We need to add new error type as follows:

   When Error-Type=5, Error-value=3, reception of messages where K bit
   in RP object is setted, but not supported

   When Error-Type=6, Error-value=3, reception of messages with no
   metric object












































Li, et al.                Expires July 3, 2012                 [Page 14]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


5.  Object Format

5.1.  Inter-domain Capability Advertisement

   [RFC6006] use the OSPF PCE capability Flags in PCE Discovery TLV to
   indicate the capability of P2MP computation.  This document will use
   the same method, defines a new flag in the OSPF PCE Capability Flags
   to indicate the capability of inter-domain P2MP computation.

   PCEs wishing to advertise that they support inter-domain path
   computation will set this bit, as to inter-domain P2MP ,PCEs would
   set this bit and the bit 10 ([RFC6006]) accordingly.  PCCs that do
   not understand those bit will ignore it.  PCEs that do not support
   inter-domain will leave the bit clear (per the default behavior
   defined in [RFC5088] and [RFC5089]).

5.2.  Preserving Topology Confidentiality

   A important element of inter-domain is that topology information is
   not shared between domains for scalability and confidentiality
   reasons.  So the cooperating PCEs cann!_t exchange the actual path
   segments between each other in PCRep Messages.  We can use loose hops
   described in [RFC3209]] to satisfy this requirement, or we can use
   PATH-KEY described in [RFC6006].

   If loose hops are used, the TE LSPs are signaled as normal
   ([RFC3209]), and when a loose hop is encountered in the explicit
   route, it is resolved by performing a secondary path computation to
   reach the resource or set of resources identified by the loose hop.

   A Path-Key is a token that replaces a path segment in an explicit
   route.  The Path-Key is encoded as a Path-Key Subobject (PKS)
   returned in the PCEP Path Computation Reply message (PCRep)
   ([RFC5440]). when a PATH-KEY is encountered in the signaling process,
   corresponding PCE will return the actural path segment continuing to
   set up the LSP, thus avoid the secondary path computation.

   After parent PCE computated the finally path and reply PCRep Message,
   the ERO and RRO contain in messge will only represented in loose hops
   or PATH-KEY format.

5.3.  Extensions to END-POINTS Object

   P2MP END-POINT object is mainly used in PCReq Messages to specify
   path!_s source and destination.  When using in inter-domain scene,
   there may be overlap in address space, so END-POINT object should
   expand to inter-domain mode, the object type should be newly defined.




Li, et al.                Expires July 3, 2012                 [Page 15]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


   END-POINTS Object-Class is 4.

   P2MP END-POINTS Object-Type is 3 for IPv4 and 4 for IPv6.  And it
   should add type code for inter-domain IPV4 and inter-domain IPV6.  We
   assume that 5 for inter-domain IPV4, and 6 for inter-domain IPV6.

   The format of the new inter-domian END-POINTS object body for IPv4
   (Object-Type 5) is as follows:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Leaf type                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Source domain                          |
       |                     Source IPv4 address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination domain                        |
       |                  Destination IPv4 address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           ...                                 ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination domain                        |
       |                  Destination IPv4 address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Figure 5: Inter-domain P2MP END-POINTS Object Body Format for IPv4

   The format of the new inter-domian END-POINTS object body for IPv6
   (Object-Type 6) is as follows:


















Li, et al.                Expires July 3, 2012                 [Page 16]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Leaf type                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Source domain                          |
       |                                                               |
       |                Source IPv6 address (16 bytes)                 |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination domian                        |
       |                                                               |
       |              Destination IPv6 address (16 bytes)              |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ~                              ...                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination domain                        |
       |                                                               |
       |              Destination IPv6 address (16 bytes)              |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Figure 6: Inter-domain P2MP END-POINTS Object Body Format for IPv6

5.4.  PCEP NO-PATH Indicator

   [RFC6006] defined No-Path Object used in PCRep Messages to
   communicate the reasons for not being able to find P2MP path, we need
   to defined one new bit in the NO-PATH-VECTOR TLV carried in it:

   Bit 25GBPo when set, the PCE indicateds that there is a reachability
   problem with subset of the inter-domain P2MP destinations.
   Optionally, the PCE can specify the destination or list of
   destinations that are not reachable using the UNREACH-DESTINATION
   object.

5.5.  Extensions to Unreach-Destination Object

   [RFC6006] defined UNREACH-DESTINATION object to specify the list of
   unreachable destinations or has no-better path destinations.  This
   object can present in PCRep messages, and the Object-Class is 28,
   Object-Type for IPV4 is 1, for IPV6 is2.

   We need to add Object-Type for inter-domain options, the type added
   list below:



Li, et al.                Expires July 3, 2012                 [Page 17]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


      UNREACH-DESTINATION Object-Class is 28.

      UNREACH-DESTINATION Object-Type for inter-domain IPv4 is 3.

      UNREACH-DESTINATION Object-Type for inter-domain IPv6 is 4.

   The format of the UNREACH-DESTIONATION object body for inter-domain
   IPV4 is as follows:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination domain                        |
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ...                                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination domain                        |
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 7: UNREACH-DESTINATION Object Body for IPv4

   The format of the UNREACH-DESTINATION object body for inter-domain
   IPV6 is as follows:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Destination domain (4 bytes)                    |
      |                                                               |
      |            Destination IPv6 address (16 bytes)                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          ...                                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Destination domain (4 bytes)                    |
      |                                                               |
      |            Destination IPv6 address (16 bytes)                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Li, et al.                Expires July 3, 2012                 [Page 18]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


            Figure 8: UNREACH-DESTINATION Object Body for IPv6

5.6.  OPEN Object

   When a PCE does not advertise its inter-domain P2MP capability during
   discovery, it should be done during the Open Message exchange when
   the PCEP session is established.  To satisfy this requirement, we
   need to extend the PCEP OPEN object by add a new optional TLV to
   indicate the PCE!_s capability to perform inter-domain P2MP path
   computations.

   OPEN object format defined as follows:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Ver |   Flags |   Keepalive   |  DeadTimer    |      SID      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                       Optional TLVs                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 9: OPEN Object Body Format

   In optional TLVs, we add a new TLV type 0x07, to indicate the inter-
   domain P2MP path computation.






















Li, et al.                Expires July 3, 2012                 [Page 19]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


6.  IANA Considerations

6.1.  OSPF PCE Capability Flag

   As discussed in Section 5.1, a new OSPF Capability Flag is defined to
   indicate inter-domain path computation capability.  IANA is requested
   to make the following allocation form the OSPF Parameters "Path
   Computation Element (PCE) Capability Flags" registry:


       Bit    Description                      Reference
       11     inter-domain path computation    This I-D


6.2.  PCEP TLV Type Indicators

   As discussed in Section 5.5, a new inter-domain P2MP capability TLV
   allows the PCE to advertise its inter-domain P2MP path computation
   capability.  IANA is requested to make the following allocation from
   the "PCEP TLV Type Indicators" sub-registry:


       Value  Description                      Reference
       7      inter-domain P2MP capable        This I-D



























Li, et al.                Expires July 3, 2012                 [Page 20]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


7.  References

7.1.  Normative References

   [PCE-HIERARCHY-FWK]
              King, D. and A. Farrel, "The Application of the Path
              Computation Element Architecture to the Determination of a
              Sequence of Domains in MPLS and GMPLS", October 2011.

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

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

   [RFC5520]  Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
              Topology Confidentiality in Inter-Domain Path Computation
              Using a Path-Key-Based Mechanism", RFC 5520, April 2009.

   [RFC6006]  Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
              and J. Meuric, "Extensions to the Path Computation Element
              Communication Protocol (PCEP) for Point-to-Multipoint
              Traffic Engineering Label Switched Paths", RFC 6006,
              September 2010.

7.2.  Informative References

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC6037]  Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
              Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
              October 2010.



Li, et al.                Expires July 3, 2012                 [Page 21]

Internet-Draft       H-PCE Extensions for P2MP Path        December 2011


Authors' Addresses

   KeJun Li
   ZTE Corporation
   6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road
   Nanshan District, Shenzhen 518055
   P.R.China

   Phone: +86 755 26773611
   Email: li.kejun@zte.com.cn


   XiaoPing Tu
   ZTE Corporation
   6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road
   Nanshan District, Shenzhen 518055
   P.R.China

   Phone: +86 755 26773624
   Email: tu.xiaoping@zte.com.cn


   ZhenTao Fu
   ZTE Corporation
   No.50, RuanJian Avenue
   Yuhuatai District, Nanjing, Jiangsu
   P.R.China

   Phone: +86 25 88014227
   Email: fu.zhentao@zte.com.cn





















Li, et al.                Expires July 3, 2012                 [Page 22]