rfc9730v1.txt | rfc9730.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) H. Zheng | Internet Engineering Task Force (IETF) H. Zheng | |||
Request for Comments: 9730 Y. Lin | Request for Comments: 9730 Y. Lin | |||
Category: Informational Huawei Technologies | Category: Informational Huawei Technologies | |||
ISSN: 2070-1721 Y. Zhao | ISSN: 2070-1721 Y. Zhao | |||
China Mobile | China Mobile | |||
Y. Xu | Y. Xu | |||
CAICT | CAICT | |||
D. Beller | D. Beller | |||
Nokia | Nokia | |||
January 2025 | February 2025 | |||
Interworking of GMPLS Control and Centralized Controller Systems | Interworking of GMPLS Control and Centralized Controller Systems | |||
Abstract | Abstract | |||
Generalized Multiprotocol Label Switching (GMPLS) control allows each | Generalized Multiprotocol Label Switching (GMPLS) control allows each | |||
network element (NE) to perform local resource discovery, routing, | network element (NE) to perform local resource discovery, routing, | |||
and signaling in a distributed manner. | and signaling in a distributed manner. | |||
The advancement of software-defined transport networking technology | The advancement of software-defined transport networking technology | |||
skipping to change at line 180 ¶ | skipping to change at line 180 ¶ | |||
H-PCE: Hierarchical PCE [RFC8685] | H-PCE: Hierarchical PCE [RFC8685] | |||
IDS: Intrusion Detection System | IDS: Intrusion Detection System | |||
IGP: Interior Gateway Protocol | IGP: Interior Gateway Protocol | |||
IoCs: Indicators of Compromise [RFC9424] | IoCs: Indicators of Compromise [RFC9424] | |||
IPS: Intrusion Prevention System | IPS: Intrusion Prevention System | |||
IS-IS: Intermediate System to Intermediate System protocol | IS-IS: Intermediate System to Intermediate System | |||
LMP: Link Management Protocol [RFC4204] | LMP: Link Management Protocol [RFC4204] | |||
LSP: Label Switched Path | LSP: Label Switched Path | |||
LSP-DB: LSP Database | LSP-DB: LSP Database | |||
MD: multi-domain | MD: multi-domain | |||
MDSC: Multi-Domain Service Coordinator [RFC8453] | MDSC: Multi-Domain Service Coordinator [RFC8453] | |||
skipping to change at line 204 ¶ | skipping to change at line 204 ¶ | |||
ML: multi-layer | ML: multi-layer | |||
MPI: MDSC to PNC Interface [RFC8453] | MPI: MDSC to PNC Interface [RFC8453] | |||
NE: network element | NE: network element | |||
NETCONF: Network Configuration Protocol [RFC6241] | NETCONF: Network Configuration Protocol [RFC6241] | |||
NMS: Network Management System | NMS: Network Management System | |||
OSPF: Open Shortest Path First protocol | OSPF: Open Shortest Path First | |||
PCC: Path Computation Client [RFC4655] | PCC: Path Computation Client [RFC4655] | |||
PCE: Path Computation Element [RFC4655] | PCE: Path Computation Element [RFC4655] | |||
PCEP: PCE Communication Protocol [RFC5440] | PCEP: PCE Communication Protocol [RFC5440] | |||
PCEP-LS: Link State PCEP [PCEP-LS] | PCEP-LS: Link State PCEP [PCEP-LS] | |||
PLR: Point of Local Repair | PLR: Point of Local Repair | |||
skipping to change at line 330 ¶ | skipping to change at line 330 ¶ | |||
Controller(N): A domain controller controlling a non-GMPLS domain | Controller(N): A domain controller controlling a non-GMPLS domain | |||
Controller(G): A domain controller controlling a GMPLS domain | Controller(G): A domain controller controlling a GMPLS domain | |||
Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS | Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS | |||
domain. This system supports the interworking among non-GMPLS | domain. This system supports the interworking among non-GMPLS | |||
domains, GMPLS domains, and the controller hierarchies. | domains, GMPLS domains, and the controller hierarchies. | |||
For domain 1, the network elements were not enabled with GMPLS, so | For domain 1, the network elements were not enabled with GMPLS, so | |||
the control is purely from the controller, via Network Configuration | the control is purely from the controller, via Network Configuration | |||
Protocol (NETCONF) [RFC6241] / YANG and/or PCE Communication Protocol | Protocol (NETCONF) [RFC6241] with a YANG data model [RFC7950] and/or | |||
(PCEP) [RFC5440]. | PCE Communication Protocol (PCEP) [RFC5440]. | |||
For domains 2 and 3: | For domains 2 and 3: | |||
* Each domain has the GMPLS control plane enabled at the physical | * Each domain has the GMPLS control plane enabled at the physical | |||
network level. The Provisioning Network Controller (PNC) can | network level. The Provisioning Network Controller (PNC) can | |||
exploit GMPLS capabilities implemented in the domain to listen to | exploit GMPLS capabilities implemented in the domain to listen to | |||
the IGP routing protocol messages (for example, OSPF Link State | the IGP routing protocol messages (for example, OSPF Link State | |||
Advertisements (LSAs)) that the GMPLS control plane instances are | Advertisements (LSAs)) that the GMPLS control plane instances are | |||
disseminating into the network and thus learn the network | disseminating into the network and thus learn the network | |||
topology. For path computation in the domain with the PNC | topology. For path computation in the domain with the PNC | |||
skipping to change at line 712 ¶ | skipping to change at line 712 ¶ | |||
downstream domain and its upstream neighbor domain; and | downstream domain and its upstream neighbor domain; and | |||
this stitching label will be passed to the upstream | this stitching label will be passed to the upstream | |||
neighbor domain by PCE protocol, which will be used for the | neighbor domain by PCE protocol, which will be used for the | |||
path segment creation in the upstream neighbor domain. | path segment creation in the upstream neighbor domain. | |||
2.2) Inter-domain labels assigned by the controller: | 2.2) Inter-domain labels assigned by the controller: | |||
If the resources of inter-domain links are managed by the | If the resources of inter-domain links are managed by the | |||
Orchestrator(MD), each domain controller can provide to the | Orchestrator(MD), each domain controller can provide to the | |||
Orchestrator(MD) the list of available labels (e.g., time | Orchestrator(MD) the list of available labels (e.g., time | |||
slots, if the OTN is the scenario) using the IETF Topology | slots if the OTN is the scenario) using topology-related | |||
YANG module and a related technology-specific extension. | YANG modules and specific technology-related extensions. | |||
Once the Orchestrator(MD) has computed the E2E path, RSVP- | Once the orchestrator(MD) has computed the E2E path, RSVP- | |||
TE or PCEP can be used in the different domains to set up | TE or PCEP can be used in the different domains to set up | |||
the related segment tunnel consisting of label inter-domain | the related segment tunnel consisting of information about | |||
information; for example, for PCEP, the label Explicit | inter-domain labels; for example, for PCEP, the label | |||
Route Object (ERO) can be included in the PCInitiate | Explicit Route Object (ERO) can be included in the | |||
message to indicate the inter-domain labels so that each | PCInitiate message to indicate the inter-domain labels so | |||
border node of each domain can configure the correct cross- | that each border node of each domain can configure the | |||
connect within itself. | correct cross-connect within itself. | |||
8.3. Multi-Layer Service Provisioning | 8.3. Multi-Layer Service Provisioning | |||
GMPLS can interwork with centralized controller systems in multi- | GMPLS can interwork with centralized controller systems in multi- | |||
layer networks. | layer networks. | |||
+----------------+ | +----------------+ | |||
|Orchestrator(ML)| | |Orchestrator(ML)| | |||
+------+--+------+ | +------+--+------+ | |||
| | Higher-layer Network | | | Higher-layer Network | |||
skipping to change at line 799 ¶ | skipping to change at line 799 ¶ | |||
To apply [RFC5623] in a multi-layer network with GMPLS-controller | To apply [RFC5623] in a multi-layer network with GMPLS-controller | |||
interworking, the H-Controller and the L-Controller can act as the | interworking, the H-Controller and the L-Controller can act as the | |||
PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML) | PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML) | |||
can act as a VNTM because it has the abstracted view of both the | can act as a VNTM because it has the abstracted view of both the | |||
higher-layer and lower-layer networks. | higher-layer and lower-layer networks. | |||
Table 1 shows all possible combinations of path computation and path | Table 1 shows all possible combinations of path computation and path | |||
control models in multi-layer network with GMPLS-controller | control models in multi-layer network with GMPLS-controller | |||
interworking: | interworking: | |||
+=====================+=================+===========+===========+ | +======================+========+================+===============+ | |||
| Path computation / | Single PCE (Not | Multiple | Multiple | | | Path computation / | Single | Multiple PCE | Multiple PCE | | |||
| Path control | applicable) | PCE with | PCE w/o | | | Path control | PCE | with inter-PCE | w/o inter-PCE | | |||
| | | inter-PCE | inter-PCE | | +======================+========+================+===============+ | |||
+=====================+=================+===========+===========+ | | PCE-VNTM cooperation | N/A | Yes | Yes | | |||
| PCE-VNTM | N/A | Yes | Yes | | +----------------------+--------+----------------+---------------+ | |||
| cooperation | | | | | | Higher-layer | N/A | Yes | Yes | | |||
+---------------------+-----------------+-----------+-----------+ | | signaling trigger | | | | | |||
| Higher-layer | N/A | Yes | Yes | | +----------------------+--------+----------------+---------------+ | |||
| signaling trigger | | | | | | NMS-VNTM cooperation | N/A | Yes (1) | No (1) | | |||
+---------------------+-----------------+-----------+-----------+ | | (integrated flavor) | | | | | |||
| NMS-VNTM | N/A | Yes (1) | No (1) | | +----------------------+--------+----------------+---------------+ | |||
| cooperation | | | | | | NMS-VNTM cooperation | N/A | No (1) | Yes (1) | | |||
| (integrated flavor) | | | | | | (separate flavor) | | | | | |||
+---------------------+-----------------+-----------+-----------+ | +----------------------+--------+----------------+---------------+ | |||
| NMS-VNTM | N/A | No (1) | Yes (1) | | ||||
| cooperation | | | | | ||||
| (separate flavor) | | | | | ||||
+---------------------+-----------------+-----------+-----------+ | ||||
Table 1: Combinations of Path Computation and Path Control Models | Table 1: Combinations of Path Computation and Path Control Models | |||
Note that: | Note that: | |||
* Since there is one PCE in each layer network, the path computation | * Since there is one PCE in each layer network, the path computation | |||
model "Single PCE path computation" is not applicable (N/A). | model "Single PCE path computation" is not applicable (N/A). | |||
* For the other two path computation models "Multiple PCE with | * For the other two path computation models "Multiple PCE with | |||
inter-PCE" and "Multiple PCE w/o inter-PCE", the possible | inter-PCE" and "Multiple PCE w/o inter-PCE", the possible | |||
combinations are the same as defined in [RFC5623]. More | combinations are the same as defined in [RFC5623]. More | |||
specifically: | specifically: | |||
skipping to change at line 842 ¶ | skipping to change at line 838 ¶ | |||
flavor)" and "NMS-VNTM cooperation (separate flavor)" are the | flavor)" and "NMS-VNTM cooperation (separate flavor)" are the | |||
typical models to be used in a multi-layer network with GMPLS- | typical models to be used in a multi-layer network with GMPLS- | |||
controller interworking. This is because, in these two models, | controller interworking. This is because, in these two models, | |||
the path computation is triggered by the NMS or VNTM. And in | the path computation is triggered by the NMS or VNTM. And in | |||
the centralized controller system, the path computation | the centralized controller system, the path computation | |||
requests are typically from the Orchestrator(ML) (acts as | requests are typically from the Orchestrator(ML) (acts as | |||
VNTM). | VNTM). | |||
- For the other two path control models "PCE-VNTM cooperation" | - For the other two path control models "PCE-VNTM cooperation" | |||
and "Higher-layer signaling trigger", the path computation is | and "Higher-layer signaling trigger", the path computation is | |||
triggered by the NEs, i.e., the NE performs PCC functions. | triggered by the NEs, i.e., the NE performs PCC functions. It | |||
These two models are still possible to be used, although they | is still possible to use these two models, although they are | |||
are not the main methods. | not the main methods. | |||
8.3.2. Cross-Layer Path Creation | 8.3.2. Cross-Layer Path Creation | |||
In a multi-layer network, a lower-layer LSP in the lower-layer | In a multi-layer network, a lower-layer LSP in the lower-layer | |||
network can be created, which will construct a new link in the | network can be created, which will construct a new link in the | |||
higher-layer network. Such a lower-layer LSP is called Hierarchical | higher-layer network. Such a lower-layer LSP is called Hierarchical | |||
LSP, or H-LSP for short; see [RFC6107]. | LSP, or H-LSP for short; see [RFC6107]. | |||
The new link constructed by the H-LSP can then be used by the higher- | The new link constructed by the H-LSP can then be used by the higher- | |||
layer network to create new LSPs. | layer network to create new LSPs. | |||
skipping to change at line 869 ¶ | skipping to change at line 865 ¶ | |||
1) Static (pre-provisioned) method: | 1) Static (pre-provisioned) method: | |||
In this method, the H-LSP in the lower-layer network is created | In this method, the H-LSP in the lower-layer network is created | |||
in advance. After that, the higher-layer network can create LSPs | in advance. After that, the higher-layer network can create LSPs | |||
using the resource of the link constructed by the H-LSP. | using the resource of the link constructed by the H-LSP. | |||
The Orchestrator(ML) is responsible to decide the creation of | The Orchestrator(ML) is responsible to decide the creation of | |||
H-LSP in the lower-layer network if it acts as a VNTM. Then it | H-LSP in the lower-layer network if it acts as a VNTM. Then it | |||
requests the L-Controller to create the H-LSP via, for example, | requests the L-Controller to create the H-LSP via, for example, | |||
an MPI interface under the ACTN architecture. See Section 3.3.2 | an MPI under the ACTN architecture. | |||
of [YANG-TE]. | ||||
If the lower-layer network is a GMPLS domain, the L-Controller(G) | If the lower-layer network is a GMPLS domain, the L-Controller(G) | |||
can trigger the GMPLS control plane to create the H-LSP. As a | can trigger the GMPLS control plane to create the H-LSP. As a | |||
typical example, the PCInitiate message can be used for the | typical example, the PCInitiate message can be used for the | |||
communication between the L-Controller and the source node of the | communication between the L-Controller and the source node of the | |||
H-LSP. And the source node of the H-LSP can trigger the RSVP-TE | H-LSP. And the source node of the H-LSP can trigger the RSVP-TE | |||
signaling procedure to create the H-LSP, as described in | signaling procedure to create the H-LSP, as described in | |||
[RFC6107]. | [RFC6107]. | |||
If the lower-layer network is a non-GMPLS domain, other methods | If the lower-layer network is a non-GMPLS domain, other methods | |||
skipping to change at line 894 ¶ | skipping to change at line 889 ¶ | |||
2) Dynamic (triggered) method: | 2) Dynamic (triggered) method: | |||
In this method, the signaling of LSP creation in the higher-layer | In this method, the signaling of LSP creation in the higher-layer | |||
network will trigger the creation of H-LSP in the lower-layer | network will trigger the creation of H-LSP in the lower-layer | |||
network dynamically, if it is necessary. Therefore, both the | network dynamically, if it is necessary. Therefore, both the | |||
higher-layer and lower-layer networks need to support the RSVP-TE | higher-layer and lower-layer networks need to support the RSVP-TE | |||
protocol and thus need to be GMPLS domains. | protocol and thus need to be GMPLS domains. | |||
In this case, after the cross-layer path is computed, the | In this case, after the cross-layer path is computed, the | |||
Orchestrator(ML) requests the H-Controller(G) for the cross-layer | Orchestrator(ML) requests the H-Controller(G) for the cross-layer | |||
LSP creation. As a typical example, the MPI interface under the | LSP creation. As a typical example, the MPI under the ACTN | |||
ACTN architecture could be used. | architecture could be used. | |||
The H-Controller(G) can trigger the GMPLS control plane to create | The H-Controller(G) can trigger the GMPLS control plane to create | |||
the LSP in the higher-layer network. As a typical example, the | the LSP in the higher-layer network. As a typical example, the | |||
PCInitiate message can be used for the communication between the | PCInitiate message can be used for the communication between the | |||
H-Controller(G) and the source node of the higher-layer LSP, as | H-Controller(G) and the source node of the higher-layer LSP, as | |||
described in Section 4.3 of [RFC8282]. At least two sets of ERO | described in Section 4.3 of [RFC8282]. At least two sets of ERO | |||
information should be included to indicate the routes of higher- | information should be included to indicate the routes of higher- | |||
layer LSP and lower-layer H-LSP. | layer LSP and lower-layer H-LSP. | |||
The source node of the higher-layer LSP follows the procedure | The source node of the higher-layer LSP follows the procedure | |||
skipping to change at line 929 ¶ | skipping to change at line 924 ¶ | |||
by this FA-LSP can be advertised in the routing instance, so that the | by this FA-LSP can be advertised in the routing instance, so that the | |||
H-Controller can be aware of this new FA. [RFC4206] and the | H-Controller can be aware of this new FA. [RFC4206] and the | |||
following updates to it (including [RFC6001] and [RFC6107]) describe | following updates to it (including [RFC6001] and [RFC6107]) describe | |||
the detailed extensions to support advertisement of an FA. | the detailed extensions to support advertisement of an FA. | |||
If the higher-layer network and the lower-layer network are under | If the higher-layer network and the lower-layer network are under | |||
separate GMPLS control plane instances or if one of the layer | separate GMPLS control plane instances or if one of the layer | |||
networks is a non-GMPLS domain, after an H-LSP is created in the | networks is a non-GMPLS domain, after an H-LSP is created in the | |||
lower-layer network, the link discovery procedure will be triggered | lower-layer network, the link discovery procedure will be triggered | |||
in the higher-layer network to discover the information of the link | in the higher-layer network to discover the information of the link | |||
constructed by the H-LSP. The LMP protocol defined in [RFC4204] can | constructed by the H-LSP. The LMP defined in [RFC4204] can be used | |||
be used if the higher-layer network supports GMPLS. The information | if the higher-layer network supports GMPLS. The information of this | |||
of this new link will be advertised to the H-Controller. | new link will be advertised to the H-Controller. | |||
8.4. Recovery | 8.4. Recovery | |||
The GMPLS recovery functions are described in [RFC4426]. Span | The GMPLS recovery functions are described in [RFC4426]. Span | |||
protection and end-to-end protection and restoration are discussed | protection and end-to-end protection and restoration are discussed | |||
with different protection schemes and message exchange requirements. | with different protection schemes and message exchange requirements. | |||
Related RSVP-TE extensions to support end-to-end recovery are | Related RSVP-TE extensions to support end-to-end recovery are | |||
described in [RFC4872]. The extensions in [RFC4872] include | described in [RFC4872]. The extensions in [RFC4872] include | |||
protection, restoration, preemption, and rerouting mechanisms for an | protection, restoration, preemption, and rerouting mechanisms for an | |||
end-to-end LSP. Besides end-to-end recovery, a GMPLS segment | end-to-end LSP. Besides end-to-end recovery, a GMPLS segment | |||
skipping to change at line 1142 ¶ | skipping to change at line 1137 ¶ | |||
procedure need to be GMPLS domains, which support the RSVP- | procedure need to be GMPLS domains, which support the RSVP- | |||
TE signaling for the creation of a rerouting LSP segment. | TE signaling for the creation of a rerouting LSP segment. | |||
For inter-domain rerouting, the interaction between GMPLS | For inter-domain rerouting, the interaction between GMPLS | |||
and a centralized controller system is needed: | and a centralized controller system is needed: | |||
* A report of the result of intra-domain segment rerouting | * A report of the result of intra-domain segment rerouting | |||
to its Controller(G) and then to the Orchestrator(MD). | to its Controller(G) and then to the Orchestrator(MD). | |||
The former could be supported by the PCRpt message in | The former could be supported by the PCRpt message in | |||
[RFC8231], while the latter could be supported by the | [RFC8231], while the latter could be supported by the | |||
MPI interface of ACTN. | MPI of ACTN. | |||
* A report of inter-domain link failure to the two | * A report of inter-domain link failure to the two | |||
Controllers (e.g., Controller(G) 1 and Controller(G) 2 | Controllers (e.g., Controller(G) 1 and Controller(G) 2 | |||
in Figure 7) by which the two ends of the inter-domain | in Figure 7) by which the two ends of the inter-domain | |||
link are controlled, respectively, and then to the | link are controlled, respectively, and then to the | |||
Orchestrator(MD). The former could be done as described | Orchestrator(MD). The former could be done as described | |||
in Section 8.1, while the latter could be supported by | in Section 8.1, while the latter could be supported by | |||
the MPI interface of ACTN. | the MPI of ACTN. | |||
* The computation of a rerouting path or path segment | * The computation of a rerouting path or path segment | |||
crossing multi-domains by the centralized controller | crossing multi-domains by the centralized controller | |||
system (see [PATH-COMP]); | system (see [PATH-COMP]); | |||
* The creation of a rerouting LSP segment in each related | * The creation of a rerouting LSP segment in each related | |||
domain. The Orchestrator(MD) can send the LSP segment | domain. The Orchestrator(MD) can send the LSP segment | |||
rerouting request to the source Controller(G) (e.g., | rerouting request to the source Controller(G) (e.g., | |||
Controller(G) 1 in Figure 7) via MPI interface, and then | Controller(G) 1 in Figure 7) via MPI interface, and then | |||
the Controller(G) can trigger the creation of a | the Controller(G) can trigger the creation of a | |||
End of changes. 14 change blocks. | ||||
46 lines changed or deleted | 41 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |