GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7025

Internet Engineering Task Force (IETF) T. Otani Request for Comments: 7025 K. Ogaki Category: Informational KDDI ISSN: 2070-1721 D. Caviglia

                                                              Ericsson
                                                              F. Zhang
                                                   Huawei Technologies
                                                           C. Margaria
                                                      Coriant R&D GmbH
                                                        September 2013
             Requirements for GMPLS Applications of PCE

Abstract

 The initial effort of the PCE (Path Computation Element) WG focused
 mainly on MPLS.  As a next step, this document describes functional
 requirements for GMPLS applications of PCE.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7025.

Otani, et al. Informational [Page 1] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

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 Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  GMPLS Applications of PCE  . . . . . . . . . . . . . . . . . .  3
   2.1.  Path Computation in GMPLS Networks . . . . . . . . . . . .  3
   2.2.  Unnumbered Interface . . . . . . . . . . . . . . . . . . .  5
   2.3.  Asymmetric Bandwidth Path Computation  . . . . . . . . . .  5
 3.  Requirements for GMPLS Applications of PCE . . . . . . . . . .  6
   3.1.  Requirements on Path Computation Request . . . . . . . . .  6
   3.2.  Requirements on Path Computation Reply . . . . . . . . . .  7
   3.3.  GMPLS PCE Management . . . . . . . . . . . . . . . . . . .  8
 4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
 5.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .  9
 6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
   6.2.  Informative References . . . . . . . . . . . . . . . . . . 11

1. Introduction

 The initial effort of the PCE (Path Computation Element) WG focused
 mainly on solving the path computation problem within a domain or
 over different domains in MPLS networks.  As with MPLS, service
 providers (SPs) have also come up with requirements for path
 computation in GMPLS-controlled networks [RFC3945], such as those
 based on Wavelength Division Multiplexing (WDM), Time Division
 Multiplexing (TDM), or Ethernet.
 [RFC4655] and [RFC4657] discuss the framework and requirements for
 PCE on both packet MPLS networks and GMPLS-controlled networks.  This
 document complements those RFCs by providing considerations of GMPLS
 applications in the intradomain and interdomain networking
 environments and indicating a set of requirements for the extended
 definition of PCE-related protocols.

Otani, et al. Informational [Page 2] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 Note that the requirements for interlayer and inter-area traffic
 engineering (TE) described in [RFC6457] and [RFC4927] are outside of
 the scope of this document.
 Constrained Shortest Path First (CSPF) computation within a domain or
 over domains for signaling GMPLS Label Switched Paths (LSPs) is
 usually more stringent than that of MPLS TE LSPs [RFC4216], because
 the additional constraints, e.g., interface switching capability,
 link encoding, link protection capability, Shared Risk Link Group
 (SRLG) [RFC4202], and so forth, need to be considered to establish
 GMPLS LSPs.  The GMPLS signaling protocol [RFC3473] is designed
 taking into account bidirectionality, switching type, encoding type,
 and protection attributes of the TE links spanned by the path, as
 well as LSP encoding and switching type of the endpoints,
 appropriately.
 This document provides requirements for GMPLS applications of PCE in
 support of GMPLS path computation, included are requirements for both
 intradomain and interdomain environments.

2. GMPLS Applications of PCE

2.1. Path Computation in GMPLS Networks

 Figure 1 depicts a model GMPLS network, consisting of an ingress
 link, a transit link, as well as an egress link.  We will use this
 model to investigate consistent guidelines for GMPLS path
 computation.  Each link at each interface has its own switching
 capability, encoding type, and bandwidth.
           Ingress             Transit             Egress
 +-----+   link1-2   +-----+   link2-3   +-----+   link3-4   +-----+
 |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
 |     |<------------|     |<------------|     |<------------|     |
 +-----+   link2-1   +-----+   link3-2   +-----+   link4-3   +-----+
             Figure 1: Path Computation in GMPLS Networks
 For the simplicity in consideration, the following basic assumptions
 are made when the LSP is created.
 (1)  Switching capabilities of outgoing links from the ingress and
      egress nodes (link1-2 and link4-3 in Figure 1) are consistent
      with each other.
 (2)  Switching capabilities of all transit links, including incoming
      links to the ingress and egress nodes (link2-1 and link3-4) are
      consistent with switching type of an LSP to be created.

Otani, et al. Informational [Page 3] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 (3)  Encoding types of all transit links are consistent with the
      encoding type of an LSP to be created.
 GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are
 usually responsible for transmitting data for the client layer.
 These GMPLS-controlled networks can provide different types of
 connections for customer services based on different service
 bandwidth requests.
 The applications and the corresponding additional requirements for
 applying PCE to GMPLS-based TDM networks are described in this
 section.  In order to simplify the description, this document only
 discusses the scenario in Synchronous Digital Hierarchy (SDH)
 networks as an example (see Figure 2).  The scenarios in Synchronous
 Optical Network (SONET) or Optical Transport Network (OTN) are
 similar.
                      N1                    N2
     +-----+       +------+              +------+
     |     |-------|      |--------------|      |       +-------+
     +-----+       |      |---|          |      |       |       |
        A1         +------+   |          +------+       |       |
                      |       |             |           +-------+
                      |       |             |              PCE
                      |       |             |
                      |      +------+       |
                      |      |      |       |
                      |      |      |-----| |
                      |      +------+     | |
                      |         N5        | |
                      |                   | |
                   +------+              +------+
                   |      |              |      |        +-----+
                   |      |--------------|      |--------|     |
                   +------+              +------+        +-----+
                      N3                    N4              A2
                 Figure 2: A Simple TDM (SDH) Network
 Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3,
 N4, and N5 are all SDH switches; A1 and A2 are client devices (e.g.,
 Ethernet switches).  Assume that one Ethernet service with 100 Mbit/s
 bandwidth is required from A1 to A2 over this network.  The client
 Ethernet service could be provided by a Virtual Container 4 (VC-4)
 container from N1 to N4; it could also be provided by three
 concatenated VC-3s (contiguous or virtual concatenation) from N1 to
 N4.

Otani, et al. Informational [Page 4] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 In this scenario, when the ingress node (e.g., N1) receives a client
 service transmitting request, the type of containers (one VC-4 or
 three concatenated VC-3s) could be determined by the PCC (Path
 Computation Client), e.g., N1 or Network Management System (NMS).
 However, it could also be determined automatically by the PCE based
 on policy [RFC5394].  If it is determined by the PCC, then the PCC
 should be capable of specifying the ingress node and egress node,
 signal type, the type of the concatenation, and the number of the
 concatenation in a PCReq (Path Computation Request) message.  The PCE
 should consider those parameters during path computation.  The route
 information (co-routing or diverse routing) should be specified in a
 PCRep (Path Computation Reply) message if path computation is
 performed successfully.
 As described above, the PCC should be capable of specifying TE
 attributes defined in the next section, and the PCE should compute a
 path accordingly.
 Where a GMPLS network consists of interdomain (e.g., inter-AS or
 inter-area) GMPLS-controlled networks, requirements on the path
 computation follow [RFC5376] and [RFC4726].

2.2. Unnumbered Interface

 GMPLS supports unnumbered interface IDs as defined in [RFC3477]; this
 means that the endpoints of the path may be unnumbered.  It should
 also be possible to request a path consisting of the mixture of
 numbered links and unnumbered links, or a P2MP (Point-to-Multipoint)
 path with different types of endpoints.  Therefore, the PCC should be
 capable of indicating the unnumbered interface ID of the endpoints in
 the PCReq message.

2.3. Asymmetric Bandwidth Path Computation

 Per [RFC6387], GMPLS signaling can be used for setting up an
 asymmetric bandwidth bidirectional LSP.  If a PCE is responsible for
 path computation, it should be capable of computing a path for the
 bidirectional LSP with asymmetric bandwidth.  This means that the PCC
 should be able to indicate the asymmetric bandwidth requirements in
 forward and reverse directions in the PCReq message.

Otani, et al. Informational [Page 5] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

3. Requirements for GMPLS Applications of PCE

3.1. Requirements on Path Computation Request

 As for path computation in GMPLS-controlled networks as discussed in
 Section 2, the PCE should appropriately consider the GMPLS TE
 attributes listed below once a PCC or another PCE requests a path
 computation.  The path calculation request message from the PCC or
 the PCE must contain the information specifying appropriate
 attributes.  According to [RFC5440], [PCE-WSON-REQ], and RSVP
 procedures such as explicit label control (ELC), the additional
 attributes introduced are as follows:
 (1)   Switching capability/type: as defined in [RFC3471], [RFC4203],
       and all current and future values.
 (2)   Encoding type: as defined in [RFC3471], [RFC4203], and all
       current and future values.
 (3)   Signal type: as defined in [RFC4606] and all current and future
       values.
 (4)   Concatenation type: In SDH/SONET and OTN, two kinds of
       concatenation modes are defined: contiguous concatenation,
       which requires co-routing for each member signal and that all
       the interfaces along the path support this capability, and
       virtual concatenation, which allows diverse routing for member
       signals and requires that only the ingress and egress
       interfaces support this capability.  Note that for the virtual
       concatenation, it may also specify co-routing or diverse
       routing.  See [RFC4606] and [RFC4328] about concatenation
       information.
 (5)   Concatenation number: Indicates the number of signals that are
       requested to be contiguously or virtually concatenated.  Also
       see [RFC4606] and [RFC4328].
 (6)   Technology-specific label(s): as defined in [RFC4606],
       [RFC6060], [RFC6002], or [RFC6205].
 (7)   End-to-End (E2E) path protection type: as defined in [RFC4872],
       e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting,
       etc.
 (8)   Administrative group: as defined in [RFC3630].
 (9)   Link protection type: as defined in [RFC4203].

Otani, et al. Informational [Page 6] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 (10)  Support for unnumbered interfaces: as defined in [RFC3477].
 (11)  Support for asymmetric bandwidth requests: as defined in
       [RFC6387].
 (12)  Support for explicit label control during the path computation.
 (13)  Support of label restrictions in the requests/responses,
       similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude
       Route Object), as defined in [RFC3473] and [RFC4874].

3.2. Requirements on Path Computation Reply

 As described above, a PCE should compute the path that satisfies the
 constraints specified in the PCReq message.  Then, the PCE should
 send a PCRep message, including the computation result, to the PCC.
 For a Path Computation Reply message (PCRep) in GMPLS networks, there
 are some additional requirements.  The PCEP (PCE communication
 protocol) PCRep message must be extended to meet the following
 requirements.
 (1)  Path computation with concatenation
      In the case of path computation involving concatenation, when a
      PCE receives the PCReq message specifying the concatenation
      constraints described in Section 3.1, the PCE should compute a
      path accordingly.
      For path computation involving contiguous concatenation, a
      single route is required, and all the interfaces along the route
      should support contiguous concatenation capability.  Therefore,
      the PCE should compute a path based on the contiguous
      concatenation capability of each interface and only one ERO that
      should carry the route information for the response.
      For path computation involving virtual concatenation, only the
      ingress/egress interfaces need to support virtual concatenation
      capability, and there may be diverse routes for the different
      member signals.  Therefore, multiple EROs may be needed for the
      response.  Each ERO may represent the route of one or multiple
      member signals.  When one ERO represents multiple member
      signals, the number must be specified.

Otani, et al. Informational [Page 7] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 (2)  Label constraint
      In the case that a PCC does not specify the exact label(s) when
      requesting a label-restricted path and the PCE is capable of
      performing the route computation and label assignment
      computation procedure, the PCE needs to be able to specify the
      label of the path in a PCRep message.
      Wavelength restriction is a typical case of label restriction.
      More generally, label switching and selection constraints may
      apply in GMPLS-controlled networks, and a PCC may request a PCE
      to take label constraint into account and return an ERO
      containing the label or set of labels that fulfill the PCC
      request.
 (3)  Roles of the routes
      When a PCC specifies the protection type of an LSP, the PCE
      should compute the working route and the corresponding
      protection route(s).  Therefore, the PCRep should allow to
      distinguish the working (nominal) and the protection routes.
      According to these routes, the RSVP-TE procedure appropriately
      creates both the working and the protection LSPs, for example,
      with the ASSOCIATION object [RFC6689].

3.3. GMPLS PCE Management

 This document does not change any of the management or operational
 details for networks that utilize PCE.  (Please refer to [RFC4655]
 for manageability considerations for a PCE-based architecture.)
 However, this document proposes the introduction of several PCEP
 objects and data for the better integration of PCE with GMPLS
 networks.  Those protocol elements will need to be visible in any
 management tools that apply to the PCE, PCC, and PCEP.  That
 includes, but is not limited to, adding appropriate objects to
 existing PCE MIB modules that are used for modeling and monitoring
 PCEP deployments [PCEP-MIB].  Ideas for what objects are needed may
 be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB
 [RFC4802].

4. Security Considerations

 PCEP extensions to support GMPLS should be considered under the same
 security as current PCE work, and this extension will not change the
 underlying security issues.  Section 10 of [RFC5440] describes the
 list of security considerations in PCEP.  At the time [RFC5440] was
 published, TCP Authentication Option (TCP-AO) had not been fully

Otani, et al. Informational [Page 8] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 specified for securing the TCP connections that underlie PCEP
 sessions.  TCP-AO [RFC5925] has now been published, and PCEP
 implementations should fully support TCP-AO according to [RFC6952].

5. Acknowledgement

 The authors would like to express thanks to Ramon Casellas, Julien
 Meuric, Adrian Farrel, Yaron Sheffer, and Shuichi Okamoto for their
 comments.

6. References

6.1. Normative References

 [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
            (GMPLS) Signaling Functional Description", RFC 3471,
            January 2003.
 [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
            (GMPLS) Signaling Resource ReserVation Protocol-Traffic
            Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
 [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
            in Resource ReSerVation Protocol - Traffic Engineering
            (RSVP-TE)", RFC 3477, January 2003.
 [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
            (TE) Extensions to OSPF Version 2", RFC 3630,
            September 2003.
 [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
            (GMPLS) Architecture", RFC 3945, October 2004.
 [RFC4202]  Kompella, K. and Y. Rekhter, "Routing Extensions in
            Support of Generalized Multi-Protocol Label Switching
            (GMPLS)", RFC 4202, October 2005.
 [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
            of Generalized Multi-Protocol Label Switching (GMPLS)",
            RFC 4203, October 2005.
 [RFC4328]  Papadimitriou, D., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Extensions for G.709 Optical
            Transport Networks Control", RFC 4328, January 2006.

Otani, et al. Informational [Page 9] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

 [RFC4606]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
            Protocol Label Switching (GMPLS) Extensions for
            Synchronous Optical Network (SONET) and Synchronous
            Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
 [RFC4802]  Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
            Switching (GMPLS) Traffic Engineering Management
            Information Base", RFC 4802, February 2007.
 [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
            Extensions in Support of End-to-End Generalized Multi-
            Protocol Label Switching (GMPLS) Recovery", RFC 4872,
            May 2007.
 [RFC4927]  Le Roux, J., "Path Computation Element Communication
            Protocol (PCECP) Specific Requirements for Inter-Area MPLS
            and GMPLS Traffic Engineering", RFC 4927, June 2007.
 [RFC5376]  Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
            Requirements for the Path Computation Element
            Communication Protocol (PCECP)", RFC 5376, November 2008.
 [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
            (PCE) Communication Protocol (PCEP)", RFC 5440,
            March 2009.
 [RFC6002]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
            Channel Switching Capable (DCSC) and Channel Set Label
            Extensions", RFC 6002, October 2010.
 [RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
            "Generalized Multiprotocol Label Switching (GMPLS) Control
            of Ethernet Provider Backbone Traffic Engineering
            (PBB-TE)", RFC 6060, March 2011.
 [RFC6205]  Otani, T. and D. Li, "Generalized Labels for Lambda-
            Switch-Capable (LSC) Label Switching Routers", RFC 6205,
            March 2011.
 [RFC6387]  Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
            Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
            Switched Paths (LSPs)", RFC 6387, September 2011.
 [RFC6689]  Berger, L., "Usage of the RSVP ASSOCIATION Object",
            RFC 6689, July 2012.

Otani, et al. Informational [Page 10] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

6.2. Informative References

 [PCE-WSON-REQ]
            Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
            Tsuritani, T., and O. Dios, "PCEP Requirements for WSON
            Routing and Wavelength Assignment", Work in Progress,
            June 2013.
 [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
            Hardwick, "PCE communication protocol (PCEP) Management
            Information Base", Work in Progress, July 2013.
 [RFC4216]  Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
            (AS) Traffic Engineering (TE) Requirements", RFC 4216,
            November 2005.
 [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
            Element (PCE)-Based Architecture", RFC 4655, August 2006.
 [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
            Communication Protocol Generic Requirements", RFC 4657,
            September 2006.
 [RFC4726]  Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
            Inter-Domain Multiprotocol Label Switching Traffic
            Engineering", RFC 4726, November 2006.
 [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
            Extension to Resource ReserVation Protocol-Traffic
            Engineering (RSVP-TE)", RFC 4874, April 2007.
 [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
            "Policy-Enabled Path Computation Framework", RFC 5394,
            December 2008.
 [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
            Authentication Option", RFC 5925, June 2010.
 [RFC6457]  Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
            Discovery Requirements for Inter-Layer Traffic
            Engineering", RFC 6457, December 2011.
 [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
            BGP, LDP, PCEP, and MSDP Issues According to the Keying
            and Authentication for Routing Protocols (KARP) Design
            Guide", RFC 6952, May 2013.

Otani, et al. Informational [Page 11] RFC 7025 Reqs for GMPLS Apps of PCE September 2013

Authors' Addresses

 Tomohiro Otani
 KDDI Corporation
 2-3-2 Nishi-shinjuku
 Shinjuku-ku, Tokyo
 Japan
 Phone: +81-(3) 3347-6006
 EMail: tm-otani@kddi.com
 Kenichi Ogaki
 KDDI Corporation
 3-10-10 Iidabashi
 Chiyoda-ku, Tokyo
 Japan
 Phone: +81-(3) 6678-0284
 EMail: ke-oogaki@kddi.com
 Diego Caviglia
 Ericsson
 16153 Genova Cornigliano
 Italy
 Phone: +390106003736
 EMail: diego.caviglia@ericsson.com
 Fatai Zhang
 Huawei Technologies Co., Ltd.
 F3-5-B R&D Center, Huawei Base
 Bantian, Longgang District, Shenzhen 518129
 P.R. China
 Phone: +86-755-28972912
 EMail: zhangfatai@huawei.com
 Cyril Margaria
 Coriant R&D GmbH
 St Martin Strasse 76
 Munich  81541
 Germany
 Phone: +49 89 5159 16934
 EMail: cyril.margaria@coriant.com

Otani, et al. Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7025.txt · Last modified: 2013/09/18 02:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki