| PCE Working Group | E. Oki |
| Internet-Draft | University of Electro-Communications |
| Intended status: Standards Track | T. Takeda |
| Expires: May 20, 2017 | NTT |
| A. Farrel | |
| Juniper Networks | |
| F. Zhang | |
| Huawei Technologies Co., Ltd. | |
| November 16, 2016 |
Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-layer-ext-11
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.
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 [RFC2119].
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 May 20, 2017.
Copyright (c) 2016 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.
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed, and a PCE may initiate or modify services in a network by supplying new paths ([I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp]).
A network may comprise multiple layers. These layers may represent separations of technologies (e.g., packet switch capable (PSC), time division multiplex (TDM), lambda switch capable (LSC)) [RFC3945], separation of data plane switching granularity levels (e.g., VC4 and VC12) [RFC5212], or a distinction between client and server networking roles (e.g., commercial or administrative separation of client and server networks). In this multi-layer network, Label Switched Paths (LSPs) in lower layers are used to carry higher-layer LSPs. The network topology formed by lower-layer LSPs and advertised as traffic engineering links (TE links) in the higher layer is called a Virtual Network Topology (VNT) [RFC5212]. Discussion of other ways that network layering can be support such that connectivity in a higher layer network can be provided by LSPs in a lower layer network is provided in [RFC7926].
It is important to optimize network resource utilization globally, i.e., taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved. This is what we call inter-layer traffic engineering. This includes mechanisms allowing the computation of end-to-end paths across layers (known as inter-layer path computation), and mechanisms for control and management of the VNT by setting up and releasing LSPs in the lower layers [RFC5212].
PCE can provide a suitable mechanism for resolving inter-layer path computation issues. The framework for applying the PCE-based path computation architecture to inter-layer traffic engineering is described in [RFC5623].
The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. A set of requirements for PCEP extensions to support inter-layer traffic engineering is described in [RFC6457].
This document presents PCEP extensions for inter-layer traffic engineering that satisfy the requirements described in [RFC6457].
[RFC4206] defines a way to signal a higher-layer LSP which has an explicit route that includes hops traversed by LSPs in lower layers. The computation of end-to-end paths across layers is called Inter- Layer Path Computation.
A Label Switching Router (LSR) in the higher-layer might not have information on the lower-layer topology, particularly in an overlay or augmented model [RFC3945], and hence may not be able to compute an end-to-end path across layers.
PCE-based inter-layer path computation consists of using one or more PCEs to compute an end-to-end path across layers. This could be achieved by relying on a single PCE that has topology information about multiple layers and can directly compute an end-to-end path across layers considering the topology of all of the layers. Alternatively, the inter-layer path computation could be performed using multiple cooperating PCEs where each PCE has information about the topology of one or more layers (but not all layers) and where the PCEs collaborate to compute an end-to-end path.
As described in [RFC5339], a hybrid nodes may advertise a single TE link with multiple switching capabilities. Those TE links exist at the layer/region boarder normally. In this case, PCE needs to be capable of specifying the server layer path information when the server layer path information is required to be returned to the PCC.
[RFC5623] describes models for inter-layer path computation in more detail.
This section describes PCEP extensions for inter-layer path computation. Four new objects are defined: the INTER-LAYER object, the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER- INDICATION object. Also, two new metric types are defined.
The INTER-LAYER object is optional and can be used in PCReq and PCRep messages, and also in PCRpt, PCUpd, and PCInitiate message.
In a PCReq message, the INTER-LAYER object indicates whether inter- layer path computation is allowed, the type of path to be computed, and whether triggered signaling (hierarchical LSPs per [RFC4206] or stitched LSPs per [RFC5150] depending on physical network technologies) is allowed. When the INTER-LAYER object is absent from a PCReq message, the receiving PCE MUST process as though inter-layer path computation had been explicitly disallowed (I-bit set to zero - see below).
In a PCRep message, the INTER-LAYER object indicates whether inter- layer path computation has been performed, the type of path that has been computed, and whether triggered signaling is used.
When a PCReq message includes more than one request, an INTER-LAYER object is used per request. When a PCRep message includes more than one path per request that is responded to, an INTER-LAYER object is used per path.
The applicability of this object to PCRpt and PCUpd messages follows as the usage of other objects on those messages as described in [I-D.ietf-pce-stateful-pce]. The applicability of this object to the PCInitiate message follows as the usage of other objects on those messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions, and so the <attribute-list> as extended in Section 5 can be used to include the INTER-LAYER object on these messages.
INTER-LAYER Object-Class TBD1 to be assigned by IANA.
INTER-LAYER Object-Type 1 to be assigned by IANA.
The format of the INTER-LAYER object body is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The INTER-LAYER Object
I flag (1 bit): The I flag is used by a PCC in a PCReq message to indicate to a PCE whether an inter-layer path is allowed. When the I flag is set (one), the PCE MAY perform inter-layer path computation and return an inter-layer path. When the flag is clear (zero), the path that is returned MUST NOT be an inter-layer path.
The I flag is used by a PCE in a PCRep message to indicate to a PCC whether the path returned is an inter-layer path. When the I flag is set (one), the path is an inter-layer path. When it is clear (zero), the path is contained within a single layer either because inter- layer path computation was not performed or because a mono-layer path (without any virtual TE link and without any loose hop that spans the lower-layer network) was found notwithstanding the use of inter-layer path computation.
M flag (1 bit): The M flag is used by a PCC in a PCReq message to indicate to a PCE whether mono-layer path or multi-layer path is requested. When the M flag is set (one), multi-layer path is requested. When it is clear (zero), mono-layer path is requested.
The M flag is used by a PCE in a PCRep message to indicate to a PCC whether mono-layer path or multi-layer path is returned. When M flag is set (one), multi-layer path is returned. When M flag is set (zero), mono-layer path is returned.
If the I flag is clear (zero), the M flag has no meaning and MUST be ignored.
[RFC6457] describes two sub-options for mono-layer path.
The choice of this sub-option can be specified by the use of O flag in the RP object specified in [RFC5440].
T flag (1 bit): The T flag is used by a PCC in a PCReq message to indicate to a PCE whether triggered signaling is allowed. When the T flag is set (one), triggered signaling is allowed. When it is clear (zero), triggered signaling is not allowed.
The T flag is used by a PCE in a PCRep message to indicate to a PCC whether triggered signaling is required to support the returned path. When the T flag is set (one), triggered signaling is required. When it is clear (zero), triggered signaling is not required.
Note that triggered signaling is used to support hierarchical [RFC4206] or stitched (xref target="RFC5150" /> LSPs according to the physical attributes of the network layers.
If the I flag is clear (zero), the T flag has no meaning and MUST be ignored.
Note that the I flag and M flag differ in the following ways. When the I flag is clear (zero), virtual TE links must not be used in path computation. In addition, loose hops that span the lower-layer network must not be specified. Only regular TE links from the same layer may be used.
Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero and SHOULD be ignored on receipt. A PCE that forwards a path computation request to other PCEs SHOULD preserve the settings of reserved bits in the PCReq messages it sends and in the PCRep messages it forwards to PCCs.
Note that the flags in the PCRpt message indicate the state of an LSP, whereas the flags in the PCUpd and the PCInitiate messages indicate the intended/desired state as determined by the PCE.
The SWITCH-LAYER object is optional on a PCReq message and specifies switching layers in which a path MUST, or MUST NOT, be established. A switching layer is expressed as a switching type and encoding type.
When a SWITCH-LAYER object is used on a PCReq it is interpreted in the context of the INTER-LAYER object on the same message. If no INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER object as though inter-layer path computation had been explicitly disallowed. In such a case, the SWITCH-LAYER object MUST NOT have more than one LSP Encoding Type and Switching Type with the I flag set.
The SWITCH-LAYER object is optional on a PCRep message, where it is used with the NO-PATH object in the case of unsuccessful path computation to indicate the set of constraints that could not be satisfied.
The SWTCH-LAYER object may be used on a PCRpt message consistent with how properties of existing LSPs are reported on that message [I-D.ietf-pce-stateful-pce]. The PCRpt message uses the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. This message can use the <attribute-list> as extended in Section 5 to carry the SWITCH-LAYER object. The SWTCH-LAYER object is not used on a PCUpd or PCInitiate message.
SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA.
SWITCH-LAYER Object-Type 1 is to be assigned by IANA.
The format of the SWITCH-LAYER object body is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SWITCH-LAYER Object
Each row indicates a switching type and encoding type that must or must not be used for specified layer(s) in the computed path.
The format is based on [RFC3471], and has equivalent semantics.
LSP Encoding Type (8 bits): see [RFC3471] for a description of parameters.
Switching Type (8 bits): see [RFC3471] for a description of parameters.
I flag (1 bit): the I flag indicates whether a layer with the specified switching type and encoding type must or must not be used by the computed path. When the I flag is set (one), the computed path MUST traverse a layer with the specified switching type and encoding type. When the I flag is clear (zero), the computed path MUST NOT enter or traverse any layer with the specified switching type and encoding type.
When a combination of switching type and encoding type is not included in SWITCH-LAYER object, the computed path MAY traverse a layer with that combination of switching type and encoding type.
A PCC may want to specify only a Switching Type and not an LSP Encoding Type. In this case, the LSP Encoding Type is set to zero.
The REQ-ADAP-CAP object is optional and is used to specify a requested adaptation capability for both ends of the lower layer LSP. The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE communication, where the PCE that is responsible for computing higher layer paths acts as a PCC to request a path computation from a PCE that is responsible for computing lower layer paths.
The REQ-ADAP-CAP object is used in a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the REQ-ADAP-CAP object is used to indicate the set of constraints that could not be satisfied).
The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- layer network to specify a requested adaptation capability for both ends of the LSP. In this case, it MAY be carried without INTER-LAYER Object.
The applicability of this object to PCRpt and PCUpd messages follows as the usage of other objects on those messages as described in [I-D.ietf-pce-stateful-pce]. The applicability of this object to the PCInitiate message follows as the usage of other objects on those messages as described in [I-D.ietf-pce-pce-initiated-lsp]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. These messages can use the <attribute-list> as extended in Section 5 to carry the REQ-ADAP-CAP object.
REQ-ADAP-CAP Object-Class TBD3 is to be assigned by IANA.
REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA.
The format of the REQ-ADAP-CAP object body is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The REQ-ADAP-CAP Object
The format is based on [RFC6001] and has equivalent semantics as the IACD Upper SC and Lower SC.
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
Encoding (8 bits): see [RFC3471] for a description of parameters.
A PCC may want to specify a Switching Capability, but not an Encoding. In this case, the Encoding MUST be set zero.
This document defines two new metric types for use in the PCEP METRIC object.
IANA has assigned the value TBD5 to indicate the metric "Number of adaptations on a path."
IANA has assigned the value TBD6 to indicate the metric "Number of layers to be involved on a path."
See Section 4.1, Section 4.2, and Section 4.3 for a description of how these metrics are applied.
The SERVER-INDICATION is optional and is used to indicate that path information included in the ERO is server layer information and specify the characteristics of the server layer, e.g., the switching capability and encoding of the server layer path.
The format of the SERVER-INDICATION object body is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SERVER-INDICATION Object
SERVER-INDICATION Object-Class TBD4 to be assigned by IANA.
SERVER-INDICATION Object-Type 1 to be assigned by IANA.
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
Encoding (8 bits): see [RFC3471] for a description of parameters.
Optional TLVs: Optional TLVs may be included within the object to specify more specific server layer path information (e.g., traffic parameters).
A PCC requests or allows inter-layer path computation in a PCReq message by including the INTER-LAYER object with the I flag set. The INTER-LAYER object indicates whether inter-layer path computation is allowed, which path type is requested, and whether triggered signaling is allowed.
The SWITCH-LAYER object, which MUST NOT be present unless the INTER- LAYER object is also present, is optionally used to specify the switching types and encoding types that define layers that must, or must not, be used in the computed path. When the SWITCH-LAYER object is used with the INTER-LAYER object I flag clear (zero), inter-layer path computation is not allowed, but constraints specified in the SWITCH-LAYER object apply. Example usage includes path computation in a single layer GMPLS network.
The REQ-ADAP-CAP object is optionally used to specify the interface switching capability of both ends of the lower layer LSP. The REQ- ADAP-CAP object is used in inter-PCE communication, where the PCE that is responsible for computing higher layer paths makes a request as a PCC to a PCE that is responsible for computing lower layer paths. Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that is responsible for computing lower-layer paths.
The METRIC object is optionally used to specify metric types to be optimized or bounded. When metric type TBD5 is used, it indicates that path computation MUST minimize or bound the number of adaptations on a path. When metric type TBD6 is used, it indicates that path computation MUST minimize or bound the number of layers to be involved on a path.
Furthermore, in order to allow different objective functions to be applied within different network layers, multiple OF objects MAY be present. In such a case, the first OF object specifies an objective function for the higher-layer network, and subsequent OF objects specify objection functions of the subsequent lower-layer networks.
In the case of successful path computation, the requested PCE replies to the requesting PCC for the inter-layer path computation result in a PCRep message that MAY include the INTER-LAYER object. When the INTER-LAYER object is included in a PCRep message, the I flag, M flag, and T flag indicate semantics of the path as described in Section 3.1. Furthermore, when the C flag of the METRIC object in a PCReq is set, the METRIC object MUST be included in the PCRep to provide the computed metric value, as specified in [RFC5440].
PCE MAY specify the server layer path information in the ERO. In this case, the requested PCE replies a PCRep message that includes at least two sets of ERO information in the path-list, one is for the client layer path information, and another one is the server layer path information. When SERVER-INDICATION is included in a PCRep message, it indicates that the path in the ERO is the server layer path information. The server layer path specified in the ERO could be loose or strict. On receiving the replied path, the PCC (e.g., NMS, ingress node) can trigger the signaling to setup the LSPs according to the computed paths.
In the case of unsuccessful path computation, the PCRep message also contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ- ADAP-CAP MAY be used to indicate the set of constraints that could not be satisfied.
Processing for stateful PCEs is described in [I-D.ietf-pce-stateful-pce]. That document defines the PCRpt message to allow a PCC to report to a PCE an LSP that already exists in the network and to delegate control of that LSP to the PCE.
When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects define in this document are used on the PCRpt to describe an LSP that is delegated to the PCE so that the PCE may process the LSP.
Furthermore, [I-D.ietf-pce-stateful-pce] defines the PCUpd message to allow a PCE to modify an LSP that has been delegated to it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCUpd to describe the new attributes of the modified LSP.
Processing for PCE initiated LSPs is described in [I-D.ietf-pce-pce-initiated-lsp]. That document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCInitiate to describe the attributes of the new LSP.
The new metric types defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp] uses <attribute-list> (which is extended in Section 5 for the purpose of including the new metrics.
The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5 to enable the use of inter- layer parameters during passive stateful operations too, using the LSP object.
Message formats in this section, as those in [RFC5440] are presented using Backus-Naur Format as specified in [RFC5511].
The format of the PCReq message is updated as shown in Figure 5
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<of-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 5: The Updated PCReq Message
The format of the PCRep message is updated as shown in Figure 6
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 6: The Updated PCRep Message
Implementations of this specification should provide a mechanism to configure any optional features (such as whether a PCE supports inter-layer computation, and which metrics are supported).
A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. Systems that already use a MIB module to manage their PCEP implementations might want to augment that module to provide controls and indicators for support of inter-layer features defined in this document, and to add counters of messages sent and received containing the objects defined here.
However, the preferred mechanism for configuration is through a YANG model. Work has started on a YANG model for PCEP [I-D.ietf-pce-pcep-yang], and this could be enhanced as described for the MIB module, above.
Additional policy configuration might be provided to allow a PCE to discriminate between the computation services offered to different PCCs.
A set of monitoring tools for the PCE-based architecture are provided in [RFC5886]. Systems implementing this specification and PCE monitoring should consider defining extensions to the mechanisms defined in [RFC5886] to help monitor inter-layer path computation requests.
IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers". This document requests IANA to carry out actions on subregistries of that registry.
IANA is requested to make the following assignments from the "PCEP Objects" subregistry.
Object-Class Value |Name |Object-Type |Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D]
| | 2-15: Unassigned |
SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D]
| | 2-15: Unassigned |
REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D]
| | 2-15: Unassigned |
SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D]
Figure 7
IANA is requested to create a new subregistry to manage the Flag field of the INTER-Layer object called the "Inter-Layer Object Path Property Bits" registry.
New bit numbers may be allocated only by an "IETF Review" action [RFC5226]. Each bit should be tracked with the following qualities:
IANA is requested to pre-populate the registry as follows:
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| Unassigned |
29 | T | Triggered Signalling Required | [This.I-D]
30 | M | Multi-Layer Requested | [This.I-D]
31 | I | Inter-Layer Allowed | [This.I-D]
Figure 8
Two new metric types are defined in this document for the METRIC object (specified in [RFC5440]). The IANA is requested to make the following allocations from the "Metric Object T Field" registry.
Value | Description | Reference
------+---------------------------------+------------
TBD5 | Number of adaptations on a path | [This.I-D]
TBD6 | Number of layers on a path | [This.I-D]
Figure 9
IANA is further requested to update the registry to show an assignment action of "IETF Consensus" as already documented in [RFC5440].
Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication is done between different layer networks for inter-layer path computation. Security issues may also exist when a single PCE is granted full visibility of TE information that applies to multiple layers.
Path-Key-based mechanism defined in [RFC5520] MAY be applied to address the topology confidentiality between different layers.
The authors would like to thank Cyril Margaria for his valuable comments. Helpful comments and suggeted text were offered by Dhruv Dhody who also fixed the RBNF.
Jean-Louis Le Roux
France Telecom R&D
Av Pierre Marzin
Lannion
France
22300
Email: jeanlouis.leroux@orange.com