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

Versions: 00 01 02 03 draft-ietf-pce-remote-initiated-gmpls-lsp

     PCE Working Group                                         Zafar Ali
     Internet Draft                                       Siva Sivabalan
     Intended status: Standard Track                   Clarence Filsfils
     Expires: April 20, 2014                               Cisco Systems
                                                            Robert Varga
                                                   Pantheon Technologies
                                                            Victor Lopez
                                                  Oscar Gonzalez de Dios
                                                          Telefonica I+D
                                                              Xian Zhang
                                                                  Huawei
     
                                                        October 21, 2013
     
     
             Path Computation Element Communication Protocol (PCEP)
                Extensions for remote-initiated GMPLS LSP Setup
                draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
     
     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 April 20, 2014.
     
     Copyright Notice
     
     Copyright (c) 2013 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 to this document.  Code Components extracted from this
     
     
     
     Expires January 2014                                      [Page 1]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
     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.
     
     Abstract
     
     Draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies
     procedures that can be used for creation and deletion of PCE-
     initiated LSPs in the active stateful PCE model. However, this
     specification focuses on MPLS networks, and does not cover remote
     instantiation of paths in GMPLS-controlled networks. This document
     complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by addressing
     the requirements for remote-initiated GMPLS LSPs.
     
     
     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
     [RFC2119].
     
     Table of Contents
     
        1. Introduction.................................................. 3
        2. Use Cases .....................................................3
          2.1. Single-layer provisioning from active stateful PCE ........3
          2.2. Multi-layer networks ......................................4
              2.2.1. Higher-layer signaling trigger ......................4
          2.3. NMS-VNTM cooperation model (separated flavor) .............6
        3. Requirements for Remote-Initiated GMPLS LSPs ..................7
        4. PCEP Extensions for Remote-Initiated GMPLS LSPs ...............7
          4.1. Generalized Endpoint in LSP Initiate Message ..............8
          4.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message ......8
          4.3. Protection Attributes in LSP Initiate Message .............9
          4.4. ERO in LSP Initiate Object ................................9
              4.4.1. ERO with explicit label control .....................9
              4.4.2. ERO with Path Keys ..................................9
              4.4.3. Switch Layer Object ................................10
          4.5. LSP delegation and cleanup ...............................10
                          Expires January 2014                 [Page 2]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        5. Security Considerations ......................................10
        6. IANA Considerations ..........................................11
          6.1. PCEP-Error Object ........................................11
        7. Acknowledgments ..............................................11
        8. References ...................................................11
          8.1. Normative References .....................................11
          8.2. Informative References ...................................11
     
     1. Introduction
     
        The Path Computation Element communication Protocol (PCEP)
        provides mechanisms for Path Computation Elements (PCEs) to
        perform route computations in response to Path Computation
        Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP
        Setup in a Stateful PCE Model draft [I-D. draft-ietf-pce-
        stateful-pce] describes a set of extensions to PCEP to enable
        active control of MPLS-TE and GMPLS network.
     
        [I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup
        and teardown of PCE-initiated LSPs under the active stateful PCE
        model, without the need for local configuration on the PCC. This
        enables realization of a dynamic network that is centrally
        controlled and deployed. However, this specification is focused
        on MPLS networks, and does not cover the GMPLS networks (e.g.,
        WSON, OTN, SONET/ SDH, etc. technologies). This document
        complements [I-D. draft-crabbe-pce-pce-initiated-lsp] by
        addressing the requirements for remote-initiated GMPLS LSPs.
        These requirements are covered in Section 3 of this draft. The
        PCEP extensions for remote initiated GMPLS LSPs are specified in
        Section 4.
     
     2. Use Cases
     
     2.1. Single-layer provisioning from active stateful PCE
     
        Figure 1 shows a single-layer topology with optical nodes with a
        GMPLS control plane. In this scenario, the active PCE can
        dynamically instantiate or delete L0 services between client
        interfaces. This process can be triggered by the deployment of a
        new network configuration or a re-optimization process. This
        operation can be human-driven (e.g. through an NMS) or an
        automatic process.
     
     
     
     
     
     
                          Expires January 2014                 [Page 3]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
                [See PDF version of the document for Figures]
     
     Figure 1. Single-layer provisioning from active stateful PCE.
     
        L0 PCE obtains resources information via control plane
        collecting LSAs messages. The PCE computes the path and sends a
        message to the optical equipment with Explicate Route Object
        (ERO) information.
     
     2.2. Multi-layer networks
     
        This use case assumes there is a multi-layer network composed by
        routers and optical equipment. According to [RFC5623], there are
        four inter-layer path control models: (1) PCE-VNTM cooperation,
        (2) Higher-layer signaling trigger, (3) NMS-VNTM cooperation
        model (integrated flavor) and (4) NMS-VNTM cooperation model
        (separated flavor). In the following we have selected two use
        cases to explain the requirements considered in this draft, but
        the document is applicable to all four options.
     
     2.2.1. Higher-layer signaling trigger
     
        Figure 2 depicts a multi-layer network scenario similar to the
        one presented in section 4.2.2. [RFC5623], with the difference
        that PCE is an active stateful PCE [I-D. draft-ietf-pce-
        stateful-pce].
     
        In this example, O1, O2 and O3 are optical nodes that are
        connected with router nodes R1, R2 and R3, respectively. The
        network is designed such that the interface between R1-O1, R2-O2
        and R3-O3 are setup to provide bandwidth-on-demand via the
        optical network.
     
                          Expires January 2014                 [Page 4]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
     
     
     
                [See PDF version of the document for Figures]
     
      Figure 2. Use case higher-layer signaling trigger
     
        The example assumes that an active stateful PCE is used for
        setting and tearing down bandwidth-on-demand connectivity.
        Although the simple use-case assumes a single PCE server (PCE1),
        the proposed technique is generalized to cover multiple co-
        operating PCE case. Similarly, although the use case assumes
        PCE1 only has knowledge of the L3 topology, the proposed
        technique is generalized to cover multi-layer PCE case.
     
        The PCE server (PCE1) is assumed to be receiving L3 topology
        data. It is also assumed that PCE learns L0 (optical) addresses
        associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and
        R3-O3. These addresses are referred by OTE-IP-R1 (optical TE
        link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2
        address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at
        R3), respectively. How PCE learns the optical addresses
        associated with the bandwidth-on-demand interfaces is beyond the
        scope of this document.
     
        How knowledge of the bandwidth-on-demand interfaces is utilized
        by the PCE is exemplified in the following. Suppose an
        application requests 8 Gbps from R1 to R2 (recall all interfaces
        in Figure 1 are assumed to be 10G). PCE1 satisfies this by
        establishing a tunnel using R1-R4-R2 path. Remote initiated LSP
        using techniques specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp] can be used to establish a PSC tunnel using the
        R1-R4-R2 path. Now assume another application requests 7 Gbps
        service between R1 and R2. This request cannot be satisfied
        without establishing a GMPLS tunnel via optical network using
        bandwidth-on-demand interfaces. In this case, PCE1 initiates a
     
                          Expires January 2014                 [Page 5]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS
        tunnel1 in the following). The remote initiated LSP using
        techniques specified in document is used for this purpose.
     
     2.3. NMS-VNTM cooperation model (separated flavor)
     
        Figure 3 depicts NMS-VNTM cooperation model. This is the
        separated flavor, because NMS and VNTM are not in the same
        location.
     
     
     
     
     
                [See PDF version of the document for Figures]
     
     
        Figure 3. Use case NMS-VNTM cooperation model
     
        A new L3 path is requested from NMS (e.g., via an automated
        process in the NMS or after human intervention). NMS does not
        have information about all network information, so it consults
        L3 PCE. For shake of simplicity L3-PCE is used, but any other
        multi-layer cooperating PCE model is applicable. In case that
        there are enough resources in the L3 layer, L3-PCE returns a L3
        only path. On the other hand, if there is a lack of resources at
        the L3 layer, L3 PCE does not return a Path. Consequently, NMS
        sends a message to the VNTM to initiate a GMPLS LSP in the lower
        layer. When the VNTM receives this message, based on the local
        policies, accepts the suggestion and sends a similar message to
        the router, which can initiate the lower layer LSP via UNI
        signaling in the routers. Similarly, VNTM may talk with L0-PCE
        to set-up the path in the optical domain.
     
                          Expires January 2014                 [Page 6]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        Requirements for the remote initiated GMPLS LSP from VNTM to the
        router are the same as discussed in the previous use case. The
        remote initiated LSP using techniques specified in document is
        used for this purpose.
     
     3. Requirements for Remote-Initiated GMPLS LSPs
     
        [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures
        that can be used for creation and deletion of PCE-initiated LSPs
        under the active stateful PCE model. However, this specification
        does not address GMPLS requirements outlined in the following:
     
        -  GMPLS support multiple switching capabilities on per TE link
          basis. GMPLS LSP creation requires knowledge of LSP switching
          capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used
          [RFC3471], [RFC3473].
     
        -  GMPLS LSP creation requires knowledge of the encoding type
          (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.)
          to be used by the LSP [RFC3471], [RFC3473].
     
        -  GMPLS LSP creation requires information of the generalized
          payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473].
     
        -  GMPLS LSP creation requires specification of data flow
          specific traffic parameters (also known as Tspec), which are
          technology specific.
     
        -  GMPLS also specifics support for asymmetric bandwidth
          requests [RFC6387].
     
        -  GMPLS extends the addressing to include unnumbered interface
          identifiers, as defined in [RFC3477].
     
        -  In some technologies path calculation is tightly coupled with
          label selection along the route. For example, path calculation
          in a WDM network may include lambda continuity and/ or lambda
          feasibility constraints and hence a path computed by the PCE
          is associated with a specific lambda (label). Hence, in such
          networks, the label information needs to be provided to a PCC
          in order for a PCE to initiate GMPLS LSPs under the active
          stateful PCE model. I.e., explicit label control may be
          required.
     
        -  GMPLS specifics protection context for the LSP, as defined in
          [RFC4872] and [RFC4873].
     
     4. PCEP Extensions for Remote-Initiated GMPLS LSPs
     
        LSP initiate (PCInitiate) message defined in [I-D. draft-crabbe-
        pce-pce-initiated-lsp] needs to be extended to include GMPLS
        specific PCEP objects as follows:
                          Expires January 2014                 [Page 7]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
     4.1. Generalized Endpoint in LSP Initiate Message
     
        This document does not modify the usage of END-POINTS object for
        PCE initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage as specified below.
     
        END-POINTS object has been extended by [I-D. draft-ietf-pcep-
        gmpls-ext] to include a new object type called "Generalized
        Endpoint". PCInitiate message sent by a PCE to a PCC to trigger
        a GMPLS LSP instantiation SHOULD include the END-POINTS with
        Generalized Endpoint object type. Furthermore, the END-POINTS
        object MUST contain "label request" TLV. The label request TLV
        is used to specify the switching type, encoding type and GPID of
        the LSP being instantiated by the PCE.
     
        As mentioned earlier, the PCE server is assumed to be receiving
        topology data. In the use case of higher-layer signaling
        trigger, the addresses associated with bandwidth-on-demand
        interfaces are included, e.g., OTE-IP-R1, OTE-IP-R2 and OTE-IP-
        R3, in the use case example. These addresses and R1, R2 and R3
        router IDs are used to derive source and destination address of
        the END-POINT object. As previously mentioned, in the case of
        NMS-VNMT cooperation model with L3 PCE, VNTM must receive such
        inter-layer interface association to configure the whole path.
     
        The unnumbered endpoint TLV can be used to specify unnumbered
        endpoint addresses for the LSP being instantiated by the PCE.
        The END-POINTS MAY contain other TLVs defined in [I-D. draft-
        ietf-pcep-gmpls-ext].
     
        If the END-POINTS Object of type Generalized Endpoint is missing
        the label request TLV, the PCC MUST send a PCErr message with
        Error-type=6 (Mandatory Object missing) and Error-value= TBA
        (LSP request TLV missing).
     
        If the PCC does not support the END-POINTS Object of type
        Generalized Endpoint, the PCC MUST send a PCErr message with
        Error-type = 3 (Unknown Object), Error-value = 2(unknown object
        type).
     
     4.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message
     
           LSP initiate message defined in [I-D. draft-crabbe-pce-pce-
        initiated-lsp] can optionally include the BANDWIDTH object.
        However, the following possibilities cannot be represented in
        the BANDWIDTH object:
     
           - Asymmetric bandwidth (different bandwidth in forward and
        reverse direction), as described in [RFC6387].
     
           - Technology specific GMPLS parameters (e.g., Tspec for
        SDH/SONET, G.709, ATM, MEF, etc.) are not supported.
                          Expires January 2014                 [Page 8]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        GENERALIZED-BANDWIDTH object has been defined in [I-D. draft-
        ietf-pcep-gmpls-ext] to address the above-mentioned limitation
        of the BANDWIDTH object.
     
        This document specifies the use of GENERALIZED-BANDWIDTH object
        in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH
        object MAY be included in the PCInitiate message. The
        GENERALIZED-BANDWIDTH object in PCInitiate message is used to
        specify technology specific Tspec and asymmetrical bandwidth
        values for the LSP being instantiated by the PCE.
     
     4.3. Protection Attributes in LSP Initiate Message
     
        This document does not modify the usage of LSPA object for PCE
        initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage of LSPA object in LSP
        Initiate Message to carry the end-to-end protection context this
        also includes the protection state information.
     
        The LSP Protection Information TLV of LSPA in the PCInitiate
        message can be used to specify protection attributes of the LSP
        being instantiated by the PCE.
     
     4.4. ERO in LSP Initiate Object
     
        This document does not modify the usage of ERO object for PCE
        initiated LSPs as specified in [I-D. draft-crabbe-pce-pce-
        initiated-lsp]. It augments the usage as specified in the
        following sections.
     
     4.4.1. ERO with explicit label control
     
        As mentioned earlier, there are technologies and scenarios where
        active stateful PCE requires explicit label control in order to
        instantiate an LSP.
     
        Explicit label control (ELC) is a procedure supported by RSVP-
        TE, where the outgoing label(s) is (are) encoded in the ERO. [I-
        D. draft-ietf-pcep-gmpls-ext] extends the <ERO> object of PCEP
        to include explicit label control. The ELC procedure enables the
        PCE to provide such label(s) directly in the path ERO.
     
        The extended ERO object in PCInitiate message can be used to
        specify label along with ERO to PCC for the LSP being
        instantiated by the active stateful PCE.
     
     4.4.2. ERO with Path Keys
     
        There are many scenarios in packet and optical networks where
        the route information of an LSP may not be provided to the PCC
        for confidentiality reasons.  A multi-domain or multi-layer
        network is an example of such networks. Similarly, a GMPLS User-
                          Expires January 2014                 [Page 9]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        Network Interface (UNI) [RFC4208] is also an example of such
        networks.
     
        In such scenarios, ERO containing the entire route cannot be
        provided to PCC (by PCE). Instead, PCE provides an ERO with Path
        Keys to the PCC. For example, in the case UNI interface between
        the router and the optical nodes, the ERO in the LSP Initiate
        Message may be constructed as follows:
     
       - The first hop is a strict hop that provides the egress
          interface information at PCC. This interface information is
          used to get to a network node that can extend the rest of the
          ERO. (Please note that in the cases where the network node is
          not directly connected with the PCC, this part of ERO may
          consist of multiple hops and may be loose).
       - The following(s) hop in the ERO may provide the network node
          with the path key [RFC5520] that can be resolved to get the
          contents of the route towards the destination.
       - There may be further hops but these hops may also be encoded
          with the path keys (if needed).
     
       This document does not change encoding or processing roles for
       the path keys, which are defined in [RFC5520].
     
     4.4.3. Switch Layer Object
     
        [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER
        object which defines and specifies the switching layer (or
        layers) in which a path MUST or MUST NOT be established. A
        switching layer is expressed as a switching type and encoding
        type. [I-D. draft-ietf-pcep-gmpls-ext], which defines the GMPLS
        extensions for PCEP, suggests using the SWITCH-LAYER object.
        Thus, SWITCH-LAYER object can be used in the PCInitiate message
        to specify the switching layer (or layers) of the LSP being
        remotely initiated.
     
     4.5. LSP delegation and cleanup
     
        LSP delegation and cleanup procedure specified in [I-D. draft-
        ietf-pcep-gmpls-ext] are equally applicable to GMPLS LSPs and
        this document does not modify the associated usage.
     
     5. Security Considerations
     
        To be added in future revision of this document.
     
     
     
                          Expires January 2014                 [Page 10]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
     6. IANA Considerations
     
     6.1. PCEP-Error Object
     
        This document defines the following new Error-Value:
     
        Error-Type  Error Value
     
        6           Error-value=TBA:  LSP Request TLV missing
     
     7. Acknowledgments
     
        The authors would like to thank George Swallow and Jan Medved
        for their comments.
     
     8. References
     
     
     8.1. Normative References
     
         [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.
     
         [I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei,
                  I., Sivabalan, S., Varga, R., "PCEP Extensions for
                  PCE-initiated LSP Setup in a Stateful PCE Model",
                  draft-crabbe-pce-pce-initiated-lsp, work in progress.
     
         [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
                  Computation Element (PCE) Communication Protocol
                  (PCEP)", RFC 5440, March 2009.
     
         [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
                  "Framework for PCE-Based Inter-Layer MPLS and GMPLS
                  Traffic Engineering", RFC 5623, September 2009.
     
        [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures
                  for Dynamically Signaled Hierarchical Label Switched
                  Paths", RFC 6107, February 2011.
     
     8.2. Informative References
     
         [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Functional Description",
                  RFC 3471, January 2003.
     
        [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
                  RFC 3473, January 2003.
     
                          Expires January 2014                 [Page 11]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                  Links in Resource ReSerVation Protocol - Traffic
                  Engineering (RSVP-TE)", RFC 3477, January 2003.
     
     
        [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
                  Ed., "RSVP-TE Extensions in Support of End-to-End
                  Generalized Multi-Protocol Label Switching (GMPLS)
                  Recovery", RFC 4872, May 2007.
     
        [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
                  Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
     
        [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
                  "Generalized Multiprotocol Label Switching (GMPLS)
                  User-Network Interface (UNI): Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Support for the
                  Overlay Model", RFC 4208, October 2005.
     
        [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
                  "Preserving Topology Confidentiality in Inter-Domain
                  Path Computation Using a Path-Key-Based Mechanism",
                  RFC 5520, April 2009.
     
     Author's Addresses
     
     
        Zafar Ali
        Cisco Systems
        Email: zali@cisco.com
     
        Siva Sivabalan
        Cisco Systems
        Email: msiva@cisco.com
     
        Clarence Filsfils
        Cisco Systems
        Email: cfilsfil@cisco.com
     
     
        Robert Varga
        Pantheon Technologies
     
        Victor Lopez
        Telefonica I+D
        Email: vlopez@tid.es
     
        Oscar Gonzalez de Dios
        Telefonica I+D
        Email: ogondio@tid.es
     
                          Expires January 2014                 [Page 12]


     Internet-Draft    draft-ali-pce-remote-initiated-gmpls-lsp-02.txt
     
        Xian Zhang
        Huawei Technologies
        Email: zhang.xian@huawei.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
                          Expires January 2014                 [Page 13]
     

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