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

Versions: 00

     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 LSP Usage
                draft-ali-pce-remote-initiated-lsp-usage-00.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
     document must include Simplified BSD License text as described in
     
     
     
     Expires January 2014                                      [Page 1]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
     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
     
     When active stateful PCE is used for managing PCE-initiated LSP,
     PCC may not be aware of the intended usage of the LSP (e.g., in a
     multi-layer network). PCEP Extensions for PCE-initiated MPLS and
     GMPLS LSP Setup specifications do not address this requirement.
     This draft addresses the requirement to specify on how PCC should
     use the remote initiated 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. Bandwidth-on-demand .......................................3
        3. Remote Initiated LSP Usage Requirement ........................5
        4. PCEP extension for PCEP Initiated LSP Usage Specification .....5
          4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message ....5
          4.2. Communicating LSP usage to Egress node ....................7
        5. Security Considerations .......................................7
        6. IANA Considerations ...........................................7
          6.1. END-POINT Object ..........................................7
        7. Acknowledgments ...............................................7
        8. References ....................................................7
          8.1. Normative References ......................................8
          8.2. Informative References ....................................8
     
     
     
     
     
                          Expires January 2014                  [Page 2]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
     1. Introduction
     
        [I-D. draft-crabbe-pce-pce-initiated-lsp] and [I-D. draft-ali-
        pce-remote-initiated-gmpls-lsp] describe the setup and teardown
        of PCE-initiated MPLS and GMPLS LSPs under the active stateful
        PCE model, without the need for local configuration on the PCC,
        thus allowing for a dynamic network that is centrally controlled
        and deployed. However, when an active stateful PCE is used for
        managing remote-initiated MPLS or GMPLS LSP, the PCC may not be
        aware of the intended usage of the remote-initiated LSP. For
        example, the PCC may not know the target IGP instance in which
        the remote-initiated LSP is to be used. These requirements are
        outlined in Section 3.
     
        This draft addresses the requirement to specify on how PCC
        should use the PCEP initiated LSPs. This is achieved by using
        LSP_TUNNEL_INTERFACE_ID Object defined in [RFC6107] in PCEP, as
        detailed in Section 4. PCEP extensions specified in this
        document are equally applicable to PCEP initiated MPLS as well
        as GMPLS LSPs.
     
     2. Use Cases
     
     2.1. Bandwidth-on-demand
     
        This use case assumes there is a multi-layer network composed by
        routers and optical equipment. In this scenario, there is an
        entity, which decides it needs extra bandwidth between two
        routers. This certain moment a GMPLS LSP connecting both routers
        via the optical network can be established on-the-fly. This
        entity can be a router, an active stateful PCE or even the NMS
        (with or without human intervention).
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
                          Expires January 2014                  [Page 3]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
     
     
     
     
     
     
     
     
     
     
     
     
                     [See PDF version of the document for Figures]
     
         Figure 1. Bandwidth on demand use case
     
        It is important to note that the bandwidth-on-demand interfaces
        and spare bandwidth in the optical network could be shared to
        cover many under capacity scenarios in the L3 network. For
        example, in this use-case, if we assume all interfaces are 10G
        and there is 10G of spare bandwidth available in the optical
        network, the spare bandwidth in the optical network can be used
        to connect any router, depending on bandwidth demand of the
        router network. For example, if there are three routers, it is
        not known a priori if the demand will make bandwidth-on-demand
        interface at R1 to be connected to bandwidth-on-demand interface
        at R2 or R3. For this reason, bandwidth-on-demand interfaces
        cannot be pre-provisioned with the IP services that are expected
        to carry. Furthermore, in this example, as active stateful PCE
        is used for managing PCE-initiated LSP, PCC may not be aware of
        the intended usage of the PCE-initiated LSP. Specifically, when
        the PCE1 initiated GMPLS tunnel1, PCC does not know the IGP
        instance whose demand leads to establishment of the GMPLS
        tunnel1 and hence does not know the IGP instance in which the
        GMPLS tunnel1 needs to be advertised. Similarly, the PCC does
        not know IP address that should be assigned to the GMPLS
        tunnel1. In the above example, this IP address is labeled as
        TUN-IP-R1 (tunnel IP address at R1). The PCC also does not know
        if the tunnel needs to be advertised as forwarding and/ or
        routing adjacency and/or to be locally used by the target IGP
        instance. Similarly, egress node for GMPLS signaling (R2 node in
        this example) may not know the intended usage of the tunnel
        (tunnel1 in this example). For example, the R2 node does not
        know IP address that should be assigned to the GMPLS tunnel1. In
        the above example, this IP address is labeled as TUN-IP-R2
     
                          Expires January 2014                  [Page 4]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
        (tunnel IP address at R2). Section 4 of this draft addresses the
        requirement to specify on how PCC and egress node for signaling
        should use the remote initiated LSPs.
     
     3. Remote Initiated LSP Usage Requirement
     
        The requirement to specify usage of the LSP to the PCC includes
        but not limited to specification of the following information.
     
        -  The target IGP instance for the Remote-initiated LSP needs to
          be specified.
     
        -  In the target IGP instance, should the PCE-initiated LSP be
          advertised as a forwarding adjacency and/ or routing adjacency
          and/ or to be used locally by the PCC?
     
        -  Should the as Remote-initiated LSP be advertised an IPv4 FA/
          RA, IPv6 FA/ RA or as unnumbered FA/ RA.
     
        -  If Remote-initiated LSP is to be advertised an IPv4 FA/ RA,
          IPv6 FA/ RA, what is the local and remote IP address is to be
          used for the advertisement.
     
     4. PCEP extension for PCEP Initiated LSP Usage Specification
     
        The requirement to specify on how PCC should use the PCEP
        initiated LSPs in outlined in Section 2. This subsection
        specifies PCEP extension used to satisfy this requirement.
     
     4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message
     
        [RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for
        communicating usage of the forwarding or routing adjacency from
        the ingress node to the egress node. This document extends the
        LSP Initiate (PCInitiate) Message to include
        LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object
        class and type for the LSP_TUNNEL_INTERFACE_ID object are as
        follows:
     
        Object Name: LSP_TUNNEL_INTERFACE_ID
     
        Object-Class Value: TBA by Iana (suggested value: 40)
     
        Object-type: 1
     
        The contents of this object are identical in encoding to the
        contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined
        in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE
        LSP_TUNNEL_INTERFACE_ID object are acceptable in this object.
        The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond
        to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please
     
                          Expires January 2014                  [Page 5]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
        note that use of TLV type 1 defined in [RFC3477] is not
        specified by this document.
     
        TLV   TLV
        Type  Description                                     Reference
        --  ------------------------------------------------- ----------
        2  IPv4 interface identifier with target IGP instance [RFC6107]
     
        3  IPv6 interface identifier with target IGP instance [RFC6107]
     
        4  Unnumbered interface with target IGP instance      [RFC6107]
     
        The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID
        object are identical to those defined for the RSVP-TE
        LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the
        fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV
        are identical to those defined for the corresponding RSVP-TE
        LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have
        slightly different usage.
     
       -  IPv4 Interface Address field in IPv4 interface identifier
          with target IGP instance TLV: This field indicates the local
          IPv4 address to be assigned to the tunnel at the PCC (ingress
          node for RSVP-TE signaling). In the example use case of
          Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is
          carried in this field (if TUN-IP-R1 is a v4 address).
     
       -  IPv6 Interface Address field in IPv4 interface identifier
          with target IGP instance TLV: This field indicates the local
          IPv6 address to be assigned to the tunnel at the PCC (ingress
          node for RSVP-TE signaling).
     
       -  LSR's Router ID field in Unnumbered interface with target IGP
          instance: The PCC SHOULD use the LSR's Router ID in Unnumbered
          interface with target IGP instance in advertising the LSP
          being initiated by the PCE.
     
       -  Interface ID (32 bits) field in unnumbered interface with
          target IGP instance: All bits of this field MUST be set to 0
          by the PCE server and MUST be ignored by PCC. PCC SHOULD
          allocate an Interface ID that fulfills Interface ID
          requirements specified in [RFC3477].
     
        When the Ingress PCC receives an LPS Request Message with
        LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained
        in the TLV to drive the IGP instance, treatment of the LSP being
        initiated in the target IGP instance (e.g., FA, RA or local
        usage), the local IPv4 or IPv6 address or router-id for
        unnumbered case to be used for advertisement of the LSP being
        instantiated.
     
     
                          Expires January 2014                  [Page 6]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
     4.2. Communicating LSP usage to Egress node
     
        PCE does not need to send LSP Initiate message to egress node to
        communicate LSP usage information. Instead PCC (Ingres signaling
        node) uses RSVP-TE signaling mechanism specified in [RFC6107] to
        send the LSP usage to Egress node. Specifically, when the
        Ingress PCC receives an LPS Request Message with
        LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD add
        LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For this
        purpose, it is RECOMMENDED that the ingress PCC use content of
        the LSP_TUNNEL_INTERFACE_ID TLV in LSP Initiate Message in PCEP
        to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This
        document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object
        in RSVP-TE signaling as specified in [RFC6107].
     
        The egress node uses information contained in the
        LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive
        the IGP instance, treatment of the LSP being initiated in the
        target IGP instance (e.g., FA, RA or local usage), the local
        IPv4 or IPv6 address or router-id for unnumbered case to be used
        for advertisement of the LSP being instantiated.
     
     5. Security Considerations
     
        To be added in future revision of this document.
     
     6. IANA Considerations
     
     6.1. END-POINT Object
     
        This document extends the LSP Initiate Message to include
        LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object
        class and type for the LSP_TUNNEL_INTERFACE_ID object are as
        follows:
     
        Name                       Class value                      Type
        ----                       -----------                      ----
        LSP_TUNNEL_INTERFACE_ID    TBA by Iana (Suggested:40)        1
     
     7. Acknowledgments
     
        The authors would like to thank George Swallow and Jan Medved
        for their comments.
     
     8. References
     
     
     
     
     
     
                          Expires January 2014                  [Page 7]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
     8.1. Normative References
     
         [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures
                  for Dynamically Signaled Hierarchical Label Switched
                  Paths", RFC 6107, February 2011.
     
        [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                  Links in Resource ReSerVation Protocol - Traffic
                  Engineering (RSVP-TE)", RFC 3477, January 2003.
     
        [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.
     
        [I-D. draft-ali-pce-remote-initiated-gmpls-lsp] Z. Ali, S.
                  Sivabalan, C. Filsfils, R. Varga, V. Lopez, O. Dios,
                  X. Zhang, " Path Computation Element Communication
                  Protocol (PCEP) Extensions for remote-initiated GMPLS
                  LSP Setup", draft-ali-pce-remote-initiated-gmpls-lsp,
                  work in progress.
     
     8.2. Informative References
     
        [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.
     
     Authors' 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
                          Expires January 2014                  [Page 8]


     Internet-Draft    draft-ali-pce-remote-initiated-lsp-usage-00.txt
     
        Telefonica I+D
        Email: ogondio@tid.es
     
        Xian Zhang
        Huawei Technologies
        Email: zhang.xian@huawei.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
                          Expires January 2014                  [Page 9]
     

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