< draft-zheng-teas-gmpls-controller-inter-work-01.txt   draft-zheng-teas-gmpls-controller-inter-work-02.txt >
TEAS Working Group Haomian Zheng TEAS Working Group Haomian Zheng
Internet Draft Xianlong Luo Internet Draft Xianlong Luo
Category: Informational Huawei Technologies Category: Informational Huawei Technologies
Yang Zhao Yang Zhao
China Mobile China Mobile
Yunbin Xu Yunbin Xu
CAICT CAICT
Sergio Belotti Sergio Belotti
Dieter Beller Dieter Beller
Nokia Nokia
Expires: April 22, 2019 October 22, 2018 Expires: June 6, 2019 December 6, 2018
Interworking of GMPLS Control and Centralized Controller System Interworking of GMPLS Control and Centralized Controller System
draft-zheng-teas-gmpls-controller-inter-work-01 draft-zheng-teas-gmpls-controller-inter-work-02
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) control allows Generalized Multi-Protocol Label Switching (GMPLS) control allows
each network element (NE) to perform local resource discovery (e.g., each network element (NE) to perform local resource discovery,
LMP), routing (e.g., OSPF-TE) and signaling (e.g., RSVP-TE) in a routing and signaling in a distributed manner.
distributed manner.
On the other hand, with the development of software-defined On the other hand, with the development of software-defined
transport networking technology, a set of NEs can be controlled via transport networking technology, a set of NEs can be controlled via
centralized controller hierarchies to address the issue from multi- centralized controller hierarchies to address the issue from multi-
domain, multi-vendor and multi-technology. An example of such domain, multi-vendor and multi-technology. An example of such
centralized architecture is ACTN controller hierarchy [RFC8453]. centralized architecture is ACTN controller hierarchy described in
RFC 8453.
Instead of competing with each other, both the distributed and the Instead of competing with each other, both the distributed and the
centralized control plane have their own advantage, and should be centralized control plane have their own advantages, and should be
complementary in the system. This document describes how the GMPLS complementary in the system. This document describes how the GMPLS
distributed control plane can interwork with a centralized distributed control plane can interwork with a centralized
controller system in a transport network. controller system in a transport network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 13 skipping to change at page 2, line 13
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2019. This Internet-Draft will expire on June 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Overview .................................................... 4 2. Overview .................................................... 4
2.1. Overview of GMPLS Control Plane ........................... 4 2.1. Overview of GMPLS Control Plane ........................... 4
2.2. Overview of Centralized Controller System ................. 4 2.2. Overview of Centralized Controller System ................. 4
2.3. GMPLS Control Interwork with Centralized Controller System. 5 2.3. GMPLS Control Interwork with Centralized Controller System. 5
3. Link Management Protocol .................................... 6 3. Link Management Protocol .................................... 6
4. Routing Options ............................................. 6 4. Routing Options ............................................. 6
4.1. OSPF-TE ................................................ 7 4.1. OSPF-TE ................................................ 6
4.2. ISIS-TE ................................................ 7 4.2. ISIS-TE ................................................ 7
4.3. Netconf/RESTconf ....................................... 7 4.3. Netconf/RESTconf ....................................... 7
5. Path Computation ............................................ 7 5. Path Computation ............................................ 7
5.1. Constraint-based Path Computing in GMPLS Control ....... 7 5.1. Constraint-based Path Computing in GMPLS Control ....... 7
5.2. Path Computation Element (PCE) ......................... 8 5.2. Path Computation Element (PCE) ......................... 7
6. Signaling Options ........................................... 8 6. Signaling Options ........................................... 8
6.1. RSVP-TE ................................................ 8 6.1. RSVP-TE ................................................ 8
7. Interworking Scenarios ...................................... 9 7. Interworking Scenarios ...................................... 8
7.1. Topology Collection & Synchronization .................. 9 7.1. Topology Collection & Synchronization .................. 8
7.2. Multi-domain/layer Service Provisioning ................ 9 7.2. Multi-domain/layer Service Provisioning ................ 9
7.3. Recovery .............................................. 10 7.3. Recovery ............................................... 9
7.4. Controller Reliability ................................ 10 7.4. Controller Reliability ................................ 10
8. Network Management ......................................... 10 8. Manageability Considerations ............................... 10
9. Security Considerations .................................... 10 9. Security Considerations .................................... 10
10. IANA Considerations........................................ 10 10. IANA Considerations........................................ 10
11. References ................................................ 10 11. References ................................................ 11
11.1. Normative References ................................. 10 11.1. Normative References ................................. 11
11.2. Informative References ............................... 14 11.2. Informative References ............................... 12
12. Authors' Addresses ........................................ 14 12. Authors' Addresses ........................................ 14
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
MPLS to support different classes of interfaces and switching MPLS to support different classes of interfaces and switching
capabilities such as Time-Division Multiplex Capable (TDM), Lambda capabilities such as Time-Division Multiplex Capable (TDM), Lambda
Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network
element (NE) running a GMPLS control plane collects network element (NE) running a GMPLS control plane collects network
information from other NEs and supports service provisioning through information from other NEs and supports service provisioning through
signaling in a distributed manner. More generic description for signaling in a distributed manner. More generic description for
Traffic-engineering networking information exchange can be found in Traffic-engineering networking information exchange can be found in
[RFC7926]. [RFC7926].
On the other hand, Software-Defined Networking (SDN) technologies On the other hand, Software-Defined Networking (SDN) technologies
have been introduced to control the transport network in a have been introduced to control the transport network in a
centralized manner. Central controllers can collect network centralized manner. Central controllers can collect network
information from each node and provision services to corresponding information from each node and provision services to corresponding
nodes. One of the examples is the Abstraction and Control of Traffic nodes. One of the examples is the Abstraction and Control of Traffic
Engineered Networks (ACTN) [RFC8453], which defines a hierarchical Engineered Networks (ACTN) [RFC8453], which defines a hierarchical
architecture with PNC, MDSC and CNC as central controllers for architecture with Provisioning Network Controller(PNC), Multi-domain
different network abstraction levels. A PCE-based approach has been Service Coordinator(MDSC) and Customer Network Controller(CNC) as
proposed as Application-Based Network Operations (ABNO) in central controllers for different network abstraction levels. A Path
[RFC7491]. Computation Element (PCE) based approach has been proposed as
Application-Based Network Operations (ABNO) in [RFC7491].
In such centralized controller architectures, GMPLS can be applied In such centralized controller architectures, GMPLS can be applied
for the NE-level control. A central controller may support GMPLS for the NE-level control. A central controller may support GMPLS
enabled domains and may interact with a GMPLS enabled domain where enabled domains and may interact with a GMPLS enabled domain where
the GMPLS control plane does the service provisioning from ingress the GMPLS control plane does the service provisioning from ingress
to egress. In this case the centralized controller sends the request to egress. In this case the centralized controller sends the request
to the ingress node and does not have to configure all NEs along the to the ingress node and does not have to configure all NEs along the
path through the domain from ingress to egress thus leveraging the path through the domain from ingress to egress thus leveraging the
GMPLS control plane. This document describes how GMPLS control GMPLS control plane. This document describes how GMPLS control
interworks with centralized controller system in transport network. interworks with centralized controller system in transport network.
skipping to change at page 4, line 30 skipping to change at page 4, line 27
Functionalities such as service provisioning, protection, and Functionalities such as service provisioning, protection, and
restoration can be performed via GMPLS communication among multiple restoration can be performed via GMPLS communication among multiple
NEs. At the same time, the controller can also collect node and NEs. At the same time, the controller can also collect node and
link resources in the network to construct the network topology and link resources in the network to construct the network topology and
compute routing paths for serving service requests. compute routing paths for serving service requests.
Several protocols have been designed for GMPLS control [RFC3945] Several protocols have been designed for GMPLS control [RFC3945]
including link management [RFC4204], signaling [RFC3471], and including link management [RFC4204], signaling [RFC3471], and
routing [RFC4202] protocols. The controllers applying these routing [RFC4202] protocols. The controllers applying these
protocols communicate with each other to exchange resource protocols communicate with each other to exchange resource
information and establish LSP. In this way, controllers in different information and establish Label Switched Paths (LSPs). In this way,
nodes in the network have the same network topology and provision controllers in different nodes in the network have the same view of
services based on local policies. the network topology and provision services based on local policies.
2.2. Overview of Centralized Controller System 2.2. Overview of Centralized Controller System
With the development of SDN technologies, a centralized controller With the development of SDN technologies, a centralized controller
architecture has been introduced to transport networks such as ACTN architecture has been introduced to transport networks such as ACTN
[RFC8453]. In centralized controller system, a controller is aware [RFC8453]. In centralized controller systems, a controller is aware
of the network topology and is responsible for provisioning incoming of the network topology and is responsible for provisioning incoming
service requests. In ACTN, multiple abstraction levels are designed service requests. In ACTN, multiple abstraction levels are designed
and controllers at different levels implement different functions. and controllers at different levels implement different functions.
This kind of abstraction enables multi-vendor, multi-domain, and This kind of abstraction enables multi-vendor, multi-domain, and
multi-technology control. multi-technology control.
For example in ACTN, an MDSC coordinates several PNCs controlling For example in ACTN, an MDSC coordinates several PNCs controlling
different domains. Each PNC provides a topological view of the different domains. Each PNC provides a topological view of the
domain it controls, which can be abstracted, to the MDSC, so that domain it controls, which can be abstracted, to the MDSC, so that
the MDSC learns the topology of the network encompassing multiple the MDSC learns the topology of the network encompassing multiple
skipping to change at page 5, line 21 skipping to change at page 5, line 18
architecture and describes how these controllers communicate with architecture and describes how these controllers communicate with
each other in order to control a multi-domain transport network. The each other in order to control a multi-domain transport network. The
controllers at the different levels in the hierarchy typically controllers at the different levels in the hierarchy typically
perform network abstraction of the domain they control and provide perform network abstraction of the domain they control and provide
an abstracted view of their domain to the controller at the next an abstracted view of their domain to the controller at the next
level in the hierarchy. The controllers at the different level in the hierarchy. The controllers at the different
hierarchical levels also interact with each other during end-to-end hierarchical levels also interact with each other during end-to-end
service establishment, which can span multiple domains. Within each service establishment, which can span multiple domains. Within each
domain, GMPLS control can be applied to each NE. The bottom-level domain, GMPLS control can be applied to each NE. The bottom-level
central controller like PNC can act as a NE to collect network central controller like PNC can act as a NE to collect network
information and initiate LSP. Following figure shows an example of information and initiate LSP. Figure 1 shows an example of GMPLS
GMPLS interworking with ACTN. interworking with ACTN.
+----------+ +----------+
| MDSC | | MDSC |
+----------+ +----------+
^ ^ ^ ^
| | | |
+---------+ +---------+ +---------+ +---------+
| RESTConf / YANG models | | RESTConf / YANG models |
V V V V
+---------+ +---------+ +---------+ +---------+
skipping to change at page 6, line 19 skipping to change at page 6, line 14
plane instances are disseminating into the network and thus learn plane instances are disseminating into the network and thus learn
the network topology. For path computation in the domain with PNC the network topology. For path computation in the domain with PNC
implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP implementing a PCE, PCCs (e.g. NEs, other controller/PCE) use PCEP
to ask the PNC for a path and get replies. The MDSC communicates to ask the PNC for a path and get replies. The MDSC communicates
with PNCs using for example REST/RESTConf based on YANG data models. with PNCs using for example REST/RESTConf based on YANG data models.
As a PNC has learned its domain topology, it can report the topology As a PNC has learned its domain topology, it can report the topology
to the MDSC. When a service arrives, the MDSC computes the path and to the MDSC. When a service arrives, the MDSC computes the path and
coordinates PNCs to establish the corresponding LSP segment. coordinates PNCs to establish the corresponding LSP segment.
Alternatively, the NETCONF protocol can be used to retrieve topology Alternatively, the NETCONF protocol can be used to retrieve topology
information utilizing the [TE-TOPO] Yang model and the technology- information utilizing the [TE-topo] Yang model and the technology-
specific YANG model augmentations required for the specific network specific YANG model augmentations required for the specific network
technology. The PNC can retrieve topology information from any NE technology. The PNC can retrieve topology information from any NE
(the GMPLS control plane instance of each NE in the domain has the (the GMPLS control plane instance of each NE in the domain has the
same topological view), construct the topology of the domain and same topological view), construct the topology of the domain and
export an abstracted view to the MDSC. Based on the topology export an abstracted view to the MDSC. Based on the topology
retrieved from multiple PNCs, the MDSC can create topology graph of retrieved from multiple PNCs, the MDSC can create topology graph of
the multi-domain network, and can use it for path computation. To the multi-domain network, and can use it for path computation. To
setup a service, the MDSC can exploit Yang tunnel model together setup a service, the MDSC can exploit Yang tunnel model together
with the technology-specific YANG model augmentations. with the technology-specific YANG model augmentations.
3. Link Management Protocol 3. Link Management Protocol
Link management protocol (LMP) [RFC4204] runs between a pair of Link management protocol (LMP) [RFC4204] runs between a pair of
nodes and is used to manage TE links. In addition to setup and nodes and is used to manage TE links. In addition to the setup and
maintain control channels, LMP can be used to verify the data link maintenance of control channels, LMP can be used to verify the data
connectivity and correlate the link property. In this way, link link connectivity and correlate the link property. In this way, link
resources, which are fundamental resources in the network, are resources, which are fundamental resources in the network, are
discovered by both ends of the link. discovered by both ends of the link.
4. Routing Options 4. Routing Options
In GMPLS control, link state information is flooded within the In GMPLS control, link state information is flooded within the
network as defined in [RFC4202]. Each node in the network can build network as defined in [RFC4202]. Each node in the network can build
the network topology according to the flooded link state the network topology according to the flooded link state
information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE information. Routing protocols such as OSPF-TE [RFC4203] and ISIS-TE
[RFC5307] have been extended to support different interfaces in [RFC5307] have been extended to support different interfaces in
skipping to change at page 7, line 32 skipping to change at page 7, line 26
Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally Netconf [RFC6241] and RESTconf [RFC8040] protocols are originally
used for network configuration. Besides, these protocols can also be used for network configuration. Besides, these protocols can also be
used for topology retrieval by using topology-related YANG models, used for topology retrieval by using topology-related YANG models,
such as [RFC8345] and [TE-topo]. These protocols provide a powerful such as [RFC8345] and [TE-topo]. These protocols provide a powerful
mechanism for notification that permits to notify the client about mechanism for notification that permits to notify the client about
topology changes. topology changes.
5. Path Computation 5. Path Computation
Once a controller learn the network topology, it can utilize the Once a controller learns the network topology, it can utilize the
available resources to serve service requests by performing path available resources to serve service requests by performing path
computation. Due to abstraction, the MDSC may not have sufficient computation. Due to abstraction, the MDSC may not have sufficient
information to compute the optimal path. In this case, the MDSC can information to compute the optimal path. In this case, the MDSC can
interact with different domain controllers by sending Yang Path interact with different domain controllers by sending Yang Path
Computation requests [PAT-COMP] to compute a set of potential Computation requests [PAT-COMP] to compute a set of potential
optimal paths and then, based on its own constraints, policy and optimal paths and then, based on its own constraints, policy and
specific knowledge (e.g. cost of access link) can choose the more specific knowledge (e.g. cost of access link) can choose the more
feasible path for service e2e path setup. feasible path for service e2e path setup.
Path computation is one of the key objectives in various types of Path computation is one of the key objectives in various types of
skipping to change at page 8, line 25 skipping to change at page 8, line 16
paths. paths.
To address this issue, stateful PCE has been proposed in [RFC8231]. To address this issue, stateful PCE has been proposed in [RFC8231].
Besides the TED, an additional LSP Database (LSP-DB) is introduced Besides the TED, an additional LSP Database (LSP-DB) is introduced
to archive each LSP computed by the PCE. In this way, PCE can easily to archive each LSP computed by the PCE. In this way, PCE can easily
figure out the relationship between the computing path and former figure out the relationship between the computing path and former
computed paths. In this approach, PCE provides computed paths to computed paths. In this approach, PCE provides computed paths to
PCC, and then PCC decides which path is deployed and when to be PCC, and then PCC decides which path is deployed and when to be
established. established.
In PCE Initiation [I-D.ietf-pce-pce-initiated-lsp], PCE is allowed In PCE Initiation [RFC8281], PCE is allowed to trigger the PCC to
to trigger the PCC to setup, maintenance, and teardown of the PCE- setup, maintenance, and teardown of the PCE-initiated LSP under the
initiated LSP under the stateful PCE model. This would allow a stateful PCE model. This would allow a dynamic network that is
dynamic network that is centrally controlled and deployed. centrally controlled and deployed.
In centralized controller system, the PCE can be implement in a In centralized controller system, the PCE can be implement in a
central controller, and the central controller performs path central controller, and the central controller performs path
computation according to its local policies. On the other hand, the computation according to its local policies. On the other hand, the
PCE can also be placed outside of the central controller. In this PCE can also be placed outside of the central controller. In this
case, the central controller acts as a PCC to request path case, the central controller acts as a PCC to request path
computation to the PCE through PCEP. computation to the PCE through PCEP.
6. Signaling Options 6. Signaling Options
Signaling mechanism is used to setup LSPs in GMPLS control. Messages Signaling mechanisms are used to setup LSPs in GMPLS control.
are sent hop by hop between the ingress node and the egress node of Messages are sent hop by hop between the ingress node and the egress
the LSP to allocate labels. Once the labels are allocated along the node of the LSP to allocate labels. Once the labels are allocated
path, the LSP setup is accomplished. Signaling protocols such as along the path, the LSP setup is accomplished. Signaling protocols
RSVP-TE [RFC3473] and CR-LDP [RFC3472] have been extended to support such as RSVP-TE [RFC3473] have been extended to support different
different interfaces in GMPLS. interfaces in GMPLS.
6.1. RSVP-TE 6.1. RSVP-TE
RSVP-TE is introduced in [RFC3209] and extended to support GMPLS RSVP-TE is introduced in [RFC3209] and extended to support GMPLS
signaling in [RFC3473]. Several label formats are defined for a signaling in [RFC3473]. Several label formats are defined for a
generalized label request, a generalized label, suggested label and generalized label request, a generalized label, suggested label and
label sets. Based on [RFC3473], RSVP-TE has been extended to support label sets. Based on [RFC3473], RSVP-TE has been extended to support
technology-specific signaling. The RSVP-TE extensions for OTN, WSON, technology-specific signaling. The RSVP-TE extensions for OTN, WSON,
optical flexi-grid network are defined in [RFC7139], [RFC7689], and optical flexi-grid network are defined in [RFC7139], [RFC7689], and
[RFC7792], respectively. [RFC7792], respectively.
7. Interworking Scenarios 7. Interworking Scenarios
7.1. Topology Collection & Synchronization 7.1. Topology Collection & Synchronization
Topology information is necessary on both network elements and Topology information is necessary on both network elements and
controllers. The topology on network element is usually raw controllers. The topology on network element is usually raw
information, while the topology on the controller can be either raw information, while the topology on the controller can be either raw
or abstracted. Three different abstraction method has been described or abstracted. Three different abstraction methods have been
in [RFC8453], and different controllers can select the corresponding described in [RFC8453], and different controllers can select the
method depending on application. corresponding method depending on application.
When there are changes in the network topology, the impacted network When there are changes in the network topology, the impacted network
element(s) need to report changes to all the other network elements, element(s) need to report changes to all the other network elements,
together with the controller, to sync up the topology information. together with the controller, to sync up the topology information.
The inter-NE synchronization can be achieved via protocols mentioned The inter-NE synchronization can be achieved via protocols mentioned
in section 3 and 4. The topology synchronization between NEs and in section 3 and 4. The topology synchronization between NEs and
controllers can either be achieved by routing protocols OSPF- controllers can either be achieved by routing protocols OSPF-
TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model. TE/PCEP-LS in [PCEP-LS] or Netconf protocol with YANG model.
7.2. Multi-domain/layer Service Provisioning 7.2. Multi-domain/layer Service Provisioning
skipping to change at page 10, line 35 skipping to change at page 10, line 22
7.4. Controller Reliability 7.4. Controller Reliability
Given the important role in the network, the reliability of Given the important role in the network, the reliability of
controller is critical. Once a controller is shut down, the network controller is critical. Once a controller is shut down, the network
should operate as well. It can be either achieved by controller back should operate as well. It can be either achieved by controller back
up or functionality back up. There are several of controller backup up or functionality back up. There are several of controller backup
or federation mechanisms in the literature. It is also more reliable or federation mechanisms in the literature. It is also more reliable
to have some function back up in the network element, to guarantee to have some function back up in the network element, to guarantee
the performance in the network. the performance in the network.
8. Network Management 8. Manageability Considerations
TBD. Each entity in the network, including both controllers and network
elements, should be managed properly as it will interact with other
entities. The manageability considerations in controller hierarchies
and network elements still apply respectively. For the protocols
applied in the network, manageability is also requested.
The responsibility of each entity should be clarified. The control
of function and policy among different controllers should be
consistent via proper negotiation process.
9. Security Considerations 9. Security Considerations
TBD. This document provides the interwork between the GMPLS and
controller hierarchies. The security requirements in both system
still applies respectively. Protocols referenced in this document
also have various security considerations, which is also expected to
be satisfied.
Other considerations on the interface between the controller and the
network element are also important. Such security includes the
functions to authenticate and authorize the control access to the
controller from multiple network elements. Security mechanisms on
the controller are also required to safeguard the underlying network
elements against attacks on the control plane and/or unauthorized
usage of data transport resources.
10. IANA Considerations 10. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol (CR-
LDP) Extensions", RFC 3472, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630, Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label
witching (GMPLS) Recovery Functional Specification", RFC
4426, March 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007. Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
skipping to change at page 12, line 32 skipping to change at page 12, line 9
March 2009. March 2009.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A., [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder J., Bierman A.,
"Network Configuration Protocol (NETCONF)", RFC 6241, June "Network Configuration Protocol (NETCONF)", RFC 6241, June
2011. 2011.
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the
GMPLS Switching Capability and Type Fields", RFC 7074, GMPLS Switching Capability and Type Fields", RFC 7074,
November 2013. November 2013.
[RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for
Application-Based Network Operations", RFC7491, March
2015.
[RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli,
D. and Zhang, X., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic-
Engineered Networks", RFC7926, July 2016.
[RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", RFC 8453, August
2018.
11.2. Informative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label
witching (GMPLS) Recovery Functional Specification", RFC
4426, March 2006.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, March 2014. Networks", RFC 7138, March 2014.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139, of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014. March 2014.
[RFC7491] King, D., Farrel, A., "A PCE-Based Architecture for
Application-Based Network Operations", RFC7491, March
2015.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
Enhancement for Signal and Network Element Compatibility Enhancement for Signal and Network Element Compatibility
for Wavelength Switched Optical Networks", RFC 7688, for Wavelength Switched Optical Networks", RFC 7688,
November 2015. November 2015.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689, November 2015. Switched Optical Networks", RFC 7689, November 2015.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792, March 2016. Multiplexing (DWDM) Networks", RFC 7792, March 2016.
[RFC7926] Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli,
D. and Zhang, X., "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic-
Engineered Networks", RFC7926, July 2016.
[RFC8040] Bierman, A., Bjorklund, M., Watsen, K., "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, September 2017. Extensions for Stateful PCE", RFC 8231, September 2017.
[RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D.
Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi-
grid DWDM networks", RFC8363, February 2017.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", RFC 8281, October 2017. Model", RFC 8281, October 2017.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., Liu, X., "A YANG Data Model for Ananthakrishnan, H., Liu, X., "A YANG Data Model for
Network Topologies", RFC 8345, March 2018. Network Topologies", RFC 8345, March 2018.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and [RFC8363] Zhang, X., Zheng, H., Casellas, R., Dios, O., and D.
Control of Traffic Engineered Networks", RFC 8453, August Ceccarelli, "GMPLS OSPF-TE Extensions in support of Flexi-
2018. grid DWDM networks", RFC8363, February 2017.
[I-D. dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., Ceccarelli, D.,
"PCEP Extensions for Distribution of Link-State and TE
Information", draft-dhodylee-pce-pcep-ls, work in
progress.
[TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., [TE-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H.,
Gonzalez De Dios, O., "YANG Data Model for Traffic Gonzalez De Dios, O., "YANG Data Model for Traffic
Engineering (TE) Topologies", draft-ietf-teas-yang-te- Engineering (TE) Topologies", draft-ietf-teas-yang-te-
topo-15, work in progress. topo-18, work in progress.
[PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O., [PAT-COMP] Busi, I., Belotti, S., Lopez, V., Gonzalez de Dios, O.,
Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang Sharma, A., Shi, Y., Vilalta, R., Setheraman, K., "Yang
model for requesting Path Computation", draft-ietf-teas- model for requesting Path Computation", draft-ietf-teas-
yang-path-computation-01, work in progress. yang-path-computation-04, work in progress.
11.2. Informative References [PCEP-LS] Dhody, D., Lee, Y., Ceccarelli, D., "PCEP Extensions for
Distribution of Link-State and TE Information", draft-
dhodylee-pce-pcep-ls, work in progress.
12. Authors' Addresses 12. Authors' Addresses
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
F3 R&D Center, Huawei Industrial Base, F3 R&D Center, Huawei Industrial Base,
Bantian, Longgang District, Bantian, Longgang District,
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
skipping to change at page 14, line 29 skipping to change at page 14, line 27
Bantian, Longgang District, Bantian, Longgang District,
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Email: luoxianlong@huawei.com Email: luoxianlong@huawei.com
Yunbin Xu Yunbin Xu
CAICT CAICT
Email: xuyunbin@ritt.cn Email: xuyunbin@ritt.cn
Yang Zhao Yang Zhao
China Mobile China Mobile
Email: zhaoyangyjy@chinamobile.com Email: zhaoyangyjy@chinamobile.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Dieter Beller Dieter Beller
Nokia Nokia
Email: Dieter.Beller@nokia.com Email: Dieter.Beller@nokia.com
 End of changes. 40 change blocks. 
116 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/