TEAS Working Group J. He Internet-Draft I. Busi Updates: 4872, 4873 (if approved) Huawei Technologies Intended status: Standards Track J. Ryoo Expires: July 17, 2022 B. Yoon ETRI P. Park KT January 13, 2022 GMPLS Signaling Extensions for Shared Mesh Protection draft-ietf-teas-gmpls-signaling-smp-09 Abstract ITU-T Recommendation G.808.3 defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, where the difference between SMP and Shared Mesh Restoration (SMR) is also identified. ITU-T Recommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network. This document updates RFC 4872 and RFC 4873 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP. Status of This Memo 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 https://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 July 17, 2022. He, et al. Expires July 17, 2022 [Page 1] Internet-Draft GMPLS Extension for SMP January 2022 Copyright Notice Copyright (c) 2022 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 (https://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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5 5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 8 5.5. Notifying Availability of Shared Resources . . . . . . . 8 5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 9 6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 9 6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 9 6.2. Updates on Notification and Operational Bits . . . . . . 10 6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 12 He, et al. Expires July 17, 2022 [Page 2] Internet-Draft GMPLS Extension for SMP January 2022 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration (SMR) mechanisms. SMR can be seen as a particular case of pre- planned Label Switched Path (LSP) rerouting that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. The recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, and explicit restoration signaling is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the provisioning phase. RFC 4873 [RFC4873] details the encoding of the last 32-bit Reserved field of the PROTECTION object defined in [RFC4872] ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a shared mesh protection (SMP) mechanism, which are not specific to a particular network technology in terms of architecture types, preemption principle, and path monitoring methods, etc. ITU-T Recommendation G.873.3 [G873.3] defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network. SMP differs from SMR in the activation/protection switching operation. The former activates a protecting LSP via the automatic protection switching (APS) protocol in the data plane when the working LSP fails, while the latter does it via control plane signaling. It is therefore necessary to distinguish SMP from SMR during provisioning so that each node involved behaves appropriately in the recovery phase when activation of a protecting LSP is done. This document updates [RFC4872] and [RFC4873] to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism. Specifically, it; o defines a new LSP protection type, "Shared Mesh Protection," for the LSP Flags field [RFC4872] of the PROTECTION object (see Section 6.1), He, et al. Expires July 17, 2022 [Page 3] Internet-Draft GMPLS Extension for SMP January 2022 o updates the definitions of the Notification (N) and Operational (O) fields [RFC4872] of the PROTECTION object to take the new SMP type into account (see Section 6.2), and o updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to take the new SMP type into account (see Section 6.3). Only the generic aspects for signaling SMP are addressed by this document. The technology-specific aspects are expected to be addressed by other documents. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In addition, the reader is assumed to be familiar with the terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372]. 3. SMP Definition [G808.3] defines the generic aspects of an SMP mechanism. [G873.3] defines the protection switching operation and associated protocol for SMP at the ODU layer. [RFC7412] provides requirements for any mechanism that would be used to implement SMP in a MPLS-TP network. The SMP mechanism is based on pre-computed protecting LSPs that are pre-configured into the network elements. Pre-configuration here means pre-reserving resources for the protecting LSPs without activating a particular protecting LSP (e.g., in circuit networks, the cross-connects in the intermediate nodes of the protecting LSP are not pre-established). Pre-configuring but not activating a protecting LSP allows the common link and node resources in the protecting LSP to be shared by multiple working LSPs that are physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint. Protecting LSPs are activated in response to failures of working LSPs or operator's commands by means of the APS protocol that operates in the data plane. The APS protocol messages are exchanged along the protecting LSP. SMP is always revertive. SMP has a lot of similarity to SMR except that the activation in case of SMR is achieved by control plane signaling during the recovery operation, while SMP is done by the APS protocol in the data plane. He, et al. Expires July 17, 2022 [Page 4] Internet-Draft GMPLS Extension for SMP January 2022 SMP has advantages with regard to the recovery speed compared with SMR. 4. Operation of SMP with GMPLS Signaling Extension Consider the following network topology: A---B---C---D \ / E---F---G / \ H---I---J---K Figure 1: An example of SMP topology The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they MUST have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Similar to SMR, this document defines a new LSP Protection Type of the secondary LSP as "Shared Mesh Protection" (see Section 6.1) to allow resource sharing along nodes E, F, and G. Examples of shared resources include the capacity of a link and the cross-connects in a node. In this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared. When a failure, such as Signal Fail (SF) and Signal Degrade (SD), occurs on one of the working LSPs (say working LSP [A,B,C,D]), the end-node (say node A) that detects the failure initiates the protection switching operation. End-node A will send a protection switching request APS message (for example, SF) to its adjacent (downstream) intermediate node (say node E) to activate the corresponding protecting LSP and will wait for a confirmation message from node E. If the protection resource is available, node E will send the confirmation APS message to the end-node A and forward the switching request APS message to its adjacent (downstream) node (say node F). When the confirmation APS message is received by node A, the cross- connection on node A is established. At this time the traffic is bridged to and selected from the protecting LSP at node A. After forwarding the switching request APS message, node E will wait for a confirmation APS message from node F, which triggers node E to set up the cross-connection for the protecting LSP being activated. He, et al. Expires July 17, 2022 [Page 5] Internet-Draft GMPLS Extension for SMP January 2022 If the protection resource is not available (due to failure or being used by higher priority connections), the switching will not be successful; the intermediate node (node E) MUST send a message to notify the end node (see Section 5.5). If the resource is in use by a lower priority protecting LSP, the lower priority service will be removed and then the intermediate node will follow the procedure as described for the case when the protection resource is available for the higher priority protecting LSP. 5. GMPLS Signaling Extension for SMP The following subsections detail how LSPs using SMP can be signaled in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 3473 [RFC3473]). This includes: (1) the ability to identify a "secondary protecting LSP" (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the "secondary LSP") used to recover another "primary working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the "protected LSP"), (2) the ability to associate the secondary LSP with the protected LSP, (3) the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP, (4) the capability to instantiate during the provisioning phase several secondary LSPs in an efficient manner, and (5) the capability to support activation of a secondary LSP after failure occurrence via APS protocol in the data plane. 5.1. Identifiers To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying normal traffic and the secondary LSP. A new LSP Protection Type "Shared Mesh Protection" is defined (see Section 6.1) to the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two LSPs. This LSP Protection Type value is applicable only to bidirectional LSPs as required in [G808.3]. He, et al. Expires July 17, 2022 [Page 6] Internet-Draft GMPLS Extension for SMP January 2022 5.2. Signaling Primary LSPs The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the primary working LSPs, with the LSP Protection Type value set to "Shared Mesh Protection". Primary working LSPs are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID. Note: N bit is set to indicate that the protection switching signaling is done via data plane. 5.3. Signaling Secondary LSPs The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the secondary protecting LSPs, with the LSP Protection Type value set to "Shared Mesh Protection". Secondary protecting LSPs are signaled by setting in the PROTECTION object the S bit and the P bit to 1, the N bit to 1 and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP MUST include at least one PRIMARY_PATH_ROUTE object (see [RFC4872]) that further allows for recovery resource sharing at each intermediate node along the secondary path. With this setting, the resources for the secondary LSP MUST be pre- reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP and protection switching to the activated protecting LSP is done using APS protocol in the data plane. After protection switching completes the protecting LSP MUST be signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION object. At this point, the link and node resources MUST be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic). The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]). Support for extra traffic in SMP is for further study. Therefore, mechanisms to set up LSPs for extra traffic are also for further study. He, et al. Expires July 17, 2022 [Page 7] Internet-Draft GMPLS Extension for SMP January 2022 5.4. SMP Preemption Priority The SMP preemption priority of a protecting LSP that the APS protocol uses to resolve the competition for shared resources among multiple protecting LSPs, is indicated in Preemption Priority field of the PROTECTION object in the Path message of the protecting LSP. In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE object can be used by GMPLS to control LSP preemption, but, they are not used by the APS to resolve the competition among multiple protecting LSPs. This avoids the need to define a complex policy for defining Setup and Holding priorities when used for both GMPLS control plane LSP preemption and SMP shared resource competition resolution. When an intermediate node on the protecting LSP receives the Path message, the priority value in the Preemption Priority field MUST be stored for that protecting LSP. When resource competition among multiple protecting LSPs occurs, the APS protocol will use their priority values to resolve the competition. In SMP, a preempted LSP MUST NOT be torn down. Once the working LSP and the protecting LSP are configured or pre-configured, the end node MUST keep refreshing both working and protecting LSPs regardless of failure or preempted situation. 5.5. Notifying Availability of Shared Resources When a lower priority protecting LSP is preempted, the intermediate node that performed preemption MUST send a Notify message with error code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared resources unavailable" (TBA1) to the end nodes of that protecting LSP. Upon receipt of this Notify message, the end node MUST stop sending and selecting normal traffic to/from its protecting LSP and try switching the traffic to another protection LSP, if available. When the shared resources become unavailable, including a case of the shared resources failure, the same Notify message MUST also be generated by the intermediate node to all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that has occupied the shared resources. These end nodes, in case of a failure of the working LSP, MUST avoid trying to switch the traffic to these protection LSPs that have been configured to use the shared resources and try switching the traffic to other protection LSPs, if available. When the shared resources become available, a Notify message with error code "Notify Error" (25) and error sub-code "Shared resources He, et al. Expires July 17, 2022 [Page 8] Internet-Draft GMPLS Extension for SMP January 2022 available" (TBA2) MUST be generated by the intermediate node. The recipients of this Notify message are the end nodes of the lower priority protecting LSPs that have been preempted and/or all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that does not need the shared resources any more. Upon receipt of this Notify message, the end node is allowed to reinitiate the protection switching operation as described in Section 4, if it still needs the protection resource. 5.6. SMP APS Configuration SMP relies on APS protocol messages being exchanged between the nodes along the path to activate an SMP protecting LSP. In order to allow exchange of APS protocol messages, an APS channel has to be configured between adjacent nodes along the path of the SMP protecting LSP. This should be done before any SMP protecting LSP has been set up by other means than GMPL signaling which are therefore outside the scope of this document. Depending on the APS protocol message format, the APS protocol may use different identifiers than GMPLS signaling to identify the SMP protecting LSP. Since APS protocol is for further study in [G808.3], it can be assumed that APS message format and identifiers are technology- specific and/or vendor-specific. Therefore, additional requirements for APS configuration are outside the scope of this document. 6. Updates to PROTECTION Object GMPLS extension requirements for SMP introduce several updates to the Protection Object (see [RFC4872]). 6.1. New Protection Type A new LSP protection type "Shared Mesh Protection" is added in the PROTECTION object. This LSP Protection Type value is applicable to only bidirectional LSPs. LSP (Protection Type) Flags: 0x20: Shared Mesh Protection The rules defined in Section 14.2 of [RFC4872] ensure that all the nodes along an SMP LSP are SMP aware. Therefore, there are no backward compatibility issues. He, et al. Expires July 17, 2022 [Page 9] Internet-Draft GMPLS Extension for SMP January 2022 6.2. Updates on Notification and Operational Bits The definitions of the N and O bits in Section 14.1 of [RFC4872] are replaced as follows: Notification (N): 1 bit When set to 1, this bit indicates that the control plane message exchange is only used for notification during protection switching. When set to 0 (default), it indicates that the control plane message exchanges are used for protection-switching purposes. The N bit is only applicable when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra- Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). If 0x20 (SMP), the N bit MUST be set to 1. The N bit MUST be set to 0 in any other case. Operational (O): 1 bit When set to 1, this bit indicates that the protecting LSP is carrying the normal traffic after protection switching. The O bit is only applicable when the P bit is set to 1, and the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra- Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in any other case. 6.3. Preemption Priority In order to indicate the SMP preemption priority, the 16-bit Reserved field [RFC4873] of the PROTECTION object is redefined. The last 32 bits in the PROTECTION object defined in [RFC4873] are updated as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R| Reserved | Seq.Flags | Reserved | Preempt Prio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Preemption Priority (Preempt Prio): 8 bit This field indicates the SMP preemption priority of a protecting LSP, when the LSP Protection Type field indicates "Shared Mesh Protection". The SMP preemption priority value is configured at the end nodes of the protecting LSP by a network operator. A lower value has a higher priority. The decision of how many He, et al. Expires July 17, 2022 [Page 10] Internet-Draft GMPLS Extension for SMP January 2022 priority levels to be operated in an SMP network is a network operator's choice. See [RFC4873] for the definition of other fields. 7. IANA Considerations IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". Within this subregistry there is a definition of the "Notify Error" error code (25). The definition lists a number of error value sub-codes that may be used with this error code. IANA is requested to allocate further error value sub-codes for use with this error code as described in this document. Value Description Reference ----- ---------------------------- --------------- TBA1 Shared resources unavailable (this document) TBA2 Shared resources available (this document) 8. Security Considerations Since this document makes use of the exchange of RSVP messages including a Notify message, the security threats discussed in [RFC4872] also apply to this document. Additionally, it may be possible to cause disruption to traffic on one protecting LSP by targeting a link used by the primary LSP of another, higher priority LSP somewhere completely different in the network. For example, in Figure 1, assume that the preemption priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being used to transport traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted. For this reason, it is important not only to use security mechanisms as discussed in [RFC4872] but also to preserve privacy of information about protecting LSPs within the network. 9. Acknowledgements The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram, Tom Petch, Ines Robles, and John Scudder for their valuable comments and suggestions on this document. He, et al. Expires July 17, 2022 [Page 11] Internet-Draft GMPLS Extension for SMP January 2022 10. Contributor The following person contributed significantly to the content of this document and should be considered as a co-author. Yuji Tochio Fujitsu Email: tochio@fujitsu.com 11. References 11.1. Normative References [G808.3] International Telecommunication Union, "Generic protection switching - Shared mesh protection", ITU-T Recommendation G.08.3, October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, DOI 10.17487/RFC4426, March 2006, . [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, . He, et al. Expires July 17, 2022 [Page 12] Internet-Draft GMPLS Extension for SMP January 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [G873.3] International Telecommunication Union, "Optical transport network - Shared mesh protection", ITU-T Recommendation G.873.3, September 2017. [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, . [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, December 2014, . Authors' Addresses Jia He Huawei Technologies F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen China Email: hejia@huawei.com Italo Busi Huawei Technologies Email: italo.busi@huawei.com Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong-gu, Daejeon 34129 South Korea Phone: +82-42-860-5384 Email: ryoo@etri.re.kr He, et al. Expires July 17, 2022 [Page 13] Internet-Draft GMPLS Extension for SMP January 2022 Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Peter Park KT Email: peter.park@kt.com He, et al. Expires July 17, 2022 [Page 14]