One document matched: draft-ietf-pce-gmpls-aps-req-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3471 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml'>
<!ENTITY rfc3473 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml'>
<!ENTITY rfc3477 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml'>
<!ENTITY rfc3630 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml'>
<!ENTITY rfc3945 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml'>
<!ENTITY rfc4202 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml'>
<!ENTITY rfc4203 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml'>
<!ENTITY rfc4216 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4216.xml'>
<!ENTITY rfc4328 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4328.xml'>
<!ENTITY rfc4606 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4606.xml'>
<!ENTITY rfc4655 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml'>
<!ENTITY rfc4657 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.xml'>
<!ENTITY rfc4726 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4726.xml'>
<!ENTITY rfc4802 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4802.xml'>
<!ENTITY rfc4872 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872.xml'>
<!ENTITY rfc4874 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4874.xml'>
<!ENTITY rfc4927 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4927.xml'>
<!ENTITY rfc5376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5376.xml'>
<!ENTITY rfc5394 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5394.xml'>
<!ENTITY rfc5440 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml'>
<!ENTITY rfc5925 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml'>
<!ENTITY rfc6002 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6002.xml'>
<!ENTITY rfc6060 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6060.xml'>
<!ENTITY rfc6205 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6205.xml'>
<!ENTITY rfc6387 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6387.xml'>
<!ENTITY rfc6457 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6457.xml'>
<!ENTITY rfc6689 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6689.xml'>
<!ENTITY rfc6952 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6952.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-ietf-pce-gmpls-aps-req-09.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<front>
<title abbrev='Reqs for GMPLS apps of PCE'>Requirements for GMPLS applications of PCE</title>
<author initials='T.' surname="Otani" fullname='Tomohiro Otani'>
<organization abbrev='KDDI'>KDDI Corporation</organization>
<address>
<postal>
<street>2-3-2 Nishi-shinjuku</street>
<city>Shinjuku-ku</city> <region>Tokyo</region>
<country>Japan</country>
</postal>
<phone>+81-(3) 3347-6006</phone>
<email>tm-otani@kddi.com</email>
</address>
</author>
<author initials='K.' surname="Ogaki" fullname='Kenichi Ogaki'>
<organization abbrev='KDDI'>KDDI Corporation</organization>
<address>
<postal>
<street>3-10-10 Iidabashi</street>
<city>Chiyoda-ku</city> <region>Tokyo</region>
<country>Japan</country>
</postal>
<phone>+81-(3) 6678-0284</phone>
<email>ke-oogaki@kddi.com</email>
</address>
</author>
<author initials='D.' surname="Caviglia" fullname='Diego Caviglia'>
<organization>Ericsson</organization>
<address>
<postal>
<street>16153 Genova Cornigliano</street>
<country>Italy</country>
</postal>
<phone>+390106003736</phone>
<email>diego.caviglia@ericsson.com</email>
</address>
</author>
<author initials='F.' surname="Zhang" fullname='Fatai Zhang'>
<organization abbrev='Huawei Technologies'>Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>F3-5-B R&D Center, Huawei Base</street>
<city>Bantian, Longgang District</city> <region>Shenzhen 518129</region>
<country>P.R.China</country>
</postal>
<phone>+86-755-28972912</phone>
<email>zhangfatai@huawei.com</email>
</address>
</author>
<author initials='C.' surname="Margaria" fullname='Cyril Margaria'>
<organization>Coriant R&D GmbH</organization>
<address>
<postal>
<street>St Martin Strasse 76</street>
<city>Munich</city> <region>81541</region>
<country>Germany</country>
</postal>
<phone>+49 89 5159 16934</phone>
<email>cyril.margaria@coriant.com </email>
</address>
</author>
<date/>
<abstract><t>The initial effort of the PCE (Path computation element) WG was mainly focused on MPLS. As a next step, this draft describes functional requirements for GMPLS application of PCE.</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>The initial effort of the PCE (Path computation element) WG was mainly focused on solving the path computation problem within a domain or over different domains in MPLS networks. As the same case with MPLS, service providers (SPs) have also come up with requirements for path computation in GMPLS-controlled networks <xref target="RFC3945"/> such as wavelength, TDM-based or Ethernet-based networks as well.</t>
<t><xref target="RFC4655"/> and <xref target="RFC4657"/> discuss the framework and requirements for PCE on both packet MPLS networks and GMPLS-controlled networks. This document complements these RFCs by providing some considerations of GMPLS applications in the intra-domain and inter-domain networking environments and indicating a set of requirements for the extended definition of PCE-related protocols.</t>
<t>Note that the requirements for inter-layer and inter-area traffic engineering described in <xref target="RFC6457"/> and <xref target="RFC4927"/> are outside of the scope of this document.</t>
<t>Constraint-based 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 <xref target="RFC4216"/>, because the additional constraints, e.g., interface switching capability, link encoding, link protection capability, SRLG (Shared risk link group) <xref target="RFC4202"/> and so forth need to be considered to establish GMPLS LSPs. GMPLS signaling protocol <xref target="RFC3473"/> is designed taking into account bi-directionality, 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 end points, appropriately.</t>
<t>This document provides requirements for GMPLS applications of PCE in support of GMPLS path computation, included are requirements for both intra-domain and inter-domain environments. </t>
</section>
<section title="GMPLS applications of PCE">
<section title="Path computation in GMPLS network">
<t>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.</t>
<figure>
<artwork>
Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
</artwork>
<postamble> Figure 1: Path computation in GMPLS networks</postamble>
</figure>
<t>For the simplicity in consideration, the below basic assumptions are made when the LSP is created.</t>
<t>(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.</t>
<t>(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 a LSP to be created.</t>
<t>(3) Encoding-types of all transit links are consistent with encoding type of a LSP to be created.</t>
<t>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.</t>
<t>The applications and the corresponding additional requirements for applying PCE to, for example, GMPLS-based TDM networks, are described in Figure 2. In order to simplify the description, this document just discusses the scenario in SDH networks as an example. The scenarios in SONET or OTN are similar to this scenario.</t>
<figure>
<artwork>
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
</artwork>
<postamble> Figure 2: A simple TDM (SDH) network</postamble>
</figure>
<t>Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, N4 and N5 are all SDH switches. Assume that one Ethernet service with 100M bandwidth is required from A1 to A2 over this network. The client Ethernet service could be provided by a VC4 container from N1 to N4, and it could also be provided by three concatenated VC3 containers (Contiguous or Virtual concatenation) from N1 to N4.</t>
<t>In this scenario, when the ingress node (e.g., N1) receives a client service transmitting request, the type of containers (one VC4 or three concatenated VC3) could be determined by PCC (Path computation client) (e.g., N1 or NMS), but could also be determined by PCE automatically based on policy <xref target="RFC5394"/>. If it is determined by PCC, 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. PCE should consider those parameters during path computation. The route information (co-route or separated-route) should be specified in a PCRep (Path computation reply) message if path computation is performed successfully.</t>
<t>As described above, PCC should be capable of specifying TE attributes defined in the next section and PCE should compute a path accordingly.</t>
<t>Where a GMPLS network is consisting of inter-domain (e.g., inter-AS or inter-area) GMPLS-controlled networks, requirements on the path computation follows <xref target="RFC5376"/> and <xref target="RFC4726"/>.</t>
</section>
<section title="Unnumbered Interface">
<t>GMPLS supports unnumbered interface ID that is defined in <xref target="RFC3477"/>, which 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.</t>
</section>
<section title="Asymmetric Bandwidth Path Computation">
<t>As per <xref target="RFC6387"/>, GMPLS signaling can be used for setting up an asymmetric bandwidth bidirectional LSP. If a PCE is responsible for the path computation, the PCE should be capable of computing a path for the bidirectional LSP with asymmetric bandwidth. It means that the PCC should be able to indicate the asymmetric bandwidth requirements in forward and reverse directions in the PCReq message.</t>
</section>
</section>
<section title="Requirements for GMPLS application of PCE">
<section title="Requirements on Path Computation Request">
<t>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 <xref target="RFC5440"/>, <xref target="PCE-WSON-REQ"/> and to RSVP procedures like explicit label control(ELC),the additional attributes introduced are as follows:</t>
<t>(1) Switching capability/type: as defined in <xref target="RFC3471"/>, <xref target="RFC4203"/> and, all current and future values.</t>
<t>(2) Encoding type: as defined in <xref target="RFC3471"/>, <xref target="RFC4203"/> and, all current and future values.</t>
<t>(3) Signal Type: as defined in <xref target="RFC4606"/> and, all current and future values.</t>
<t>(4) Concatenation Type: In SDH/SONET and OTN, two
kinds of concatenation modes are defined: contiguous concatenation
which requires co-route for each member signal and requires all the
interfaces along the path to support this capability, and virtual
concatenation which allows diverse routes for the member signals and
only requires the ingress and egress interfaces to support this
capability. Note that for the virtual concatenation, it also may
specify co-routed or separated-routed. See <xref target="RFC4606"/> and <xref target="RFC4328"/> about concatenation information.</t>
<t>(5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see <xref target="RFC4606"/> and <xref target="RFC4328"/>.</t>
<t>(6) Technology-specific label(s) such as defined in <xref target="RFC4606"/>, <xref target="RFC6060"/>, <xref target="RFC6002"/> or <xref target="RFC6205"/>.</t>
<t>(7) e2e Path protection type: as defined in <xref target="RFC4872"/>, e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc.</t>
<t>(8) Administrative group: as defined in <xref target="RFC3630"/></t>
<t>(9) Link Protection type: as defined in <xref target="RFC4203"/></t>
<t>(10)Support for unnumbered interfaces: as defined in <xref target="RFC3477"/></t>
<t>(11)Support for asymmetric bandwidth request: as defined in <xref target="RFC6387"/></t>
<t>(12)Support for explicit label control during the path computation.</t>
<t>(13)Support of label restrictions in the requests/responses, similarly to RSVP-TE ERO (Explicit route object) and XRO (Exclude route object) as defined in <xref target="RFC3473"/> and <xref target="RFC4874"/>.</t>
</section>
<section title="Requirements on Path Computation Reply">
<t>As described above, a PCE should compute the path that satisfies the constraints which are specified in the PCReq message. Then the PCE should send a PCRep message including the computation result to the PCC. For 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.</t>
<t>(1) Path computation with concatenation</t>
<t>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.</t>
<t>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 which should carry the route information for the response.</t>
<t>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. In the case where one ERO represents several member signals among the total member signals, the number of member signals along the route of the ERO must be specified.</t>
<t>(2) Label constraint</t>
<t>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.</t>
<t>Wavelength restriction is a typical case of label restriction. More generally in GMPLS-controlled networks label switching and selection constraints may apply and a PCC may request a PCE to take label constraint into account and return an ERO containing the label or set of label that fulfil the PCC request.</t>
<t>(3) Roles of the routes</t>
<t>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, RSVP-TE procedure appropriately creates both the working and the protection LSPs for example with ASSOCIATION object <xref target="RFC6689"/>.</t>
</section>
<section title="GMPLS PCE Management">
<t>This document does not change any of the management or operational details for networks that utilise PCE. Please refer to <xref target="RFC4655"/> for an overview of this
scenery. 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 modelling and monitoring
PCEP deployments <xref target="PCEP-MIB"/>. Ideas for what objects are needed may
be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB <xref target="RFC4802"/>."
</t>
</section>
</section>
<section title="Security Considerations">
<t>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. Sec. 10 of <xref target="RFC5440"/> describes the list of security considerations in PCEP. At the time <xref target="RFC5440"/> was published, TCP Authentication Option (TCP-AO) had not been fully specified for securing the TCP connections that underlie PCEP sessions. TCP-AO <xref target="RFC5925"/> has now been published and PCEP implementations should fully support TCP-AO according to <xref target="RFC6952"/>.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Acknowledgement">
<t>The author would like to express the thanks to Ramon Casellas, Julien Meuric, Adrian Farrel, Yaron Sheffer and Shuichi Okamoto for their comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3471;
&rfc3473;
&rfc3477;
&rfc3630;
&rfc3945;
&rfc4202;
&rfc4203;
&rfc4328;
&rfc4606;
&rfc4802;
&rfc4872;
&rfc4927;
&rfc5376;
&rfc5440;
&rfc6002;
&rfc6060;
&rfc6205;
&rfc6387;
&rfc6689;
</references>
<references title="Informative References">
<reference anchor='PCE-WSON-REQ'>
<front>
<title>PCEP Requirements for WSON Routing and Wavelength Assignment</title>
<author initials='Y.' surname="Lee" fullname='Young Lee'>
<organization />
</author>
<author initials='G.' surname="Bernstein" fullname='Greg Bernstein'>
<organization />
</author>
<author initials='J.' surname="Martensson" fullname='Jonas Martensson'>
<organization />
</author>
<author initials='T.' surname="Takeda" fullname='Tomonori Takeda'>
<organization />
</author>
<author initials='T.' surname="Tsuritani" fullname='Takehiro Tsuritani'>
<organization />
</author>
<author initials='O.' surname="de Dios" fullname='O.G. de Dios'>
<organization />
</author>
<date month='June' year='2013' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-wson-routing-wavelength-09"/>
<format type='TXT' target='http://tools.ietf.org/id/draft-ietf-pce-wson-routing-wavelength-09.txt' />
</reference>
<reference anchor='PCEP-MIB'>
<front>
<title>PCE communication protocol (PCEP) Management Information Base</title>
<author fullname="A S Kiran Koushik" initials="A." surname="Koushik"><organization />
</author>
<author fullname="Stephan Emile" initials="S." surname="Emile">
<organization />
</author>
<author fullname="Quintin Zhao" initials="Q." surname="Zhao">
<organization />
</author>
<author fullname="Daniel King" initials="D." surname="King">
<organization />
</author>
<author fullname="Jonathan Hardwick" initials="J." surname="Hardwick">
<organization />
</author>
<date month='July' year='2013' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-mib-05"/>
<format type='TXT' target='http://tools.ietf.org/id/draft-ietf-pce-pcep-mib-05.txt' />
</reference>
&rfc4216;
&rfc4655;
&rfc4657;
&rfc4726;
&rfc4874;
&rfc5394;
&rfc5925;
&rfc6457;
&rfc6952;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:39 |