idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4872, updated by this document, for RFC5378 checks: 2004-04-06) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 14, 2021) is 1199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'A' is mentioned on line 194, but not defined == Missing Reference: 'B' is mentioned on line 194, but not defined == Missing Reference: 'C' is mentioned on line 194, but not defined == Missing Reference: 'D' is mentioned on line 194, but not defined == Missing Reference: 'H' is mentioned on line 182, but not defined == Missing Reference: 'I' is mentioned on line 181, but not defined == Missing Reference: 'J' is mentioned on line 181, but not defined == Missing Reference: 'K' is mentioned on line 182, but not defined == Missing Reference: 'E' is mentioned on line 182, but not defined == Missing Reference: 'F' is mentioned on line 182, but not defined == Missing Reference: 'G' is mentioned on line 182, but not defined Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. He 3 Internet-Draft I. Busi 4 Updates: 4872 (if approved) Huawei Technologies 5 Intended status: Standards Track J. Ryoo 6 Expires: July 18, 2021 B. Yoon 7 ETRI 8 P. Park 9 KT 10 January 14, 2021 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-05 15 Abstract 17 ITU-T Recommendation G.808.3 defines the generic aspects of a Shared 18 Mesh Protection (SMP) mechanism, where the difference between SMP and 19 Shared Mesh Restoration (SMR) is also identified. ITU-T 20 Recommendation G.873.3 defines the protection switching operation and 21 associated protocol for SMP at the Optical Data Unit (ODU) layer. 22 RFC 7412 provides requirements for any mechanism that would be used 23 to implement SMP in a Multi-Protocol Label Switching - Transport 24 Profile (MPLS-TP) network. 26 This document updates RFC 4872 to provide the extensions to the 27 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 28 support the control of the SMP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 18, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 78 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4 80 4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 82 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 83 4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8 84 5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8 85 5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8 86 5.2. Updates on Notification and Operational Bits . . . . . . 9 87 5.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 9 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 93 9.2. Informative References . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 96 1. Introduction 98 RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol 99 - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration 100 (SMR) mechanism. SMR can be seen as a particular case of pre-planned 101 Label Switched Path (LSP) rerouting that reduces the recovery 102 resource requirements by allowing multiple protecting LSPs to share 103 common link and node resources. The recovery resources for the 104 protecting LSPs are pre-reserved during the provisioning phase, and 105 an explicit restoration signaling is required to activate (i.e., 106 commit resource allocation at the data plane) a specific protecting 107 LSP instantiated during the provisioning phase. 109 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 110 a shared mesh protection (SMP) mechanism. ITU-T Recommendation 111 G.873.3 [G873.3] defines the protection switching operation and 112 associated protocol for SMP at the Optical Data Unit (ODU) layer. 113 RFC 7412 [RFC7412] provides requirements for any mechanism that would 114 be used to implement SMP in a Multi-Protocol Label Switching - 115 Transport Profile (MPLS-TP) network. 117 SMP differs from SMR in the activation/protection switching 118 operation. The former activates a protecting LSP via the automatic 119 protection switching (APS) protocol in the data plane when the 120 working LSP fails, while the latter does it via the control plane 121 signaling. It is therefore necessary to distinguish SMP from SMR 122 during provisioning so that each node involved behaves appropriately 123 in the recovery phase when activation of a protecting LSP is done. 125 This document updates [RFC4872] to provide the extensions to the 126 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 127 support the control of the SMP mechanism. Only the generic aspects 128 for signaling SMP are addressed by this document. The technology- 129 specific aspects are expected to be addressed by other documents. 131 2. Conventions Used in This Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 In addition, the reader is assumed to be familiar with the 140 terminology used in [RFC4872] and RFC 4426 [RFC4426]. 142 3. SMP Definition 144 [G808.3] defines the generic aspects of a SMP mechanism. [G873.3] 145 defines the protection switching operation and associated protocol 146 for SMP at the ODU layer. [RFC7412] provides requirements for any 147 mechanism that would be used to implement SMP in a MPLS-TP network. 149 The SMP mechanism is based on pre-computed protecting LSPs that are 150 pre-configured into the network elements. Pre-configuration here 151 means pre-reserving resources for the protecting LSPs without 152 activating a particular protecting LSP (e.g. in circuit networks, the 153 cross-connects in the intermediate nodes of the protecting LSP are 154 not pre-established). Pre-configuring but not activating a 155 protecting LSP allows the common link and node resources in the 156 protecting LSP to be shared by multiple working LSPs that are 157 physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) 158 disjoint. Protecting LSPs are activated in response to failures of 159 working LSPs or operator's commands by means of the APS protocol that 160 operates in the data plane. The APS protocol messages are exchanged 161 along the protecting LSP. SMP is always revertive. 163 SMP has a lot of similarity to SMR except that the activation in case 164 of SMR is achieved by control plan signaling during the recovery 165 operation while SMP is done by the APS protocol in the data plane. 166 SMP has advantages with regard to the recovery speed compared with 167 SMR. 169 4. GMPLS Signaling Extension for SMP 171 Consider the following network topology: 173 A---B---C---D 174 \ / 175 E---F---G 176 / \ 177 H---I---J---K 179 Figure 1: An example of SMP topology 181 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 182 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], 183 in order to achieve resource sharing during the signaling of these 184 protecting LSPs, they must have the same Tunnel Endpoint Address (as 185 part of their SESSION object). However, these addresses are not the 186 same in this example. Similar to SMR, a new LSP Protection Type of 187 the secondary LSP is defined as "Shared Mesh Protection" (see 188 Section 5.1) to allow resource sharing along nodes E, F, and G. In 189 this case, the protecting LSPs are not merged (which is useful since 190 the paths diverge at G), but the resources along E, F, G can be 191 shared. 193 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 194 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 195 end-node (say node A) that detects the failure initiates the 196 protection switching operation. End-node A will send a protection 197 switching request APS message (for example SF) to its adjacent 198 (downstream) intermediate node (say node E) to activate the 199 corresponding protecting LSP and will wait for a confirmation message 200 from node E. If the protection resource is available, node E will 201 send the confirmation APS message to the end-node A and forward the 202 switching request APS message to its adjacent (downstream) node (say 203 node F). When the confirmation APS message is received by node A, 204 the cross-connection on node A is established. At this time the 205 traffic is bridged to and selected from the protecting LSP at node A. 206 After forwarding the switching request APS message, node E will wait 207 for a confirmation APS message from node F, which triggers node E to 208 set up the cross-connection for the protecting LSP being activated. 209 If the protection resource is not available (due to failure or being 210 used by higher priority connections), the switching will not be 211 successful; the intermediate node may send a message to notify the 212 end node, or may keep trying until the resource is available, or the 213 switching request is cancelled. If the resource is in use by a lower 214 priority protecting LSP, the lower priority service will be removed 215 and then the intermediate node will follow the procedure as described 216 for the case when the protection resource is available for the higher 217 priority protecting LSP. 219 The SMP preemption priority of a protecting LSP that the APS protocol 220 uses to resolve the competition for shared resources among multiple 221 protecting LSPs, is indicated in Preemption Priority field of the 222 PROTECTION object in the Path message of the protecting LSP. 224 In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE 225 object can be used by GMPLS to control LSP preemption, but, they are 226 not used by the APS to resolve the competition among multiple 227 protecting LSPs. This would avoid the need to define a complex 228 policy for defining Setup and Holding priorities when used for both 229 GMPLS control plane LSP preemption and SMP shared resource 230 competition resolution. 232 When an intermediate node on the protecting LSP receives the Path 233 message, the priority value in the Preemption Priority field MUST be 234 stored for that protecting LSP. When resource competition among 235 multiple protecting LSPs occurs, the APS protocol will use their 236 priority values to resolve the competition. 238 In SMP, a preempted LSP SHOULD NOT be torn down. Once the working 239 LSP and the protecting LSP are configured or pre-configured, the end 240 node SHOULD keep refreshing both working and protecting LSPs 241 regardless of failure or preempted situation. 243 When a lower priority protecting LSP is preempted, the intermediate 244 node that performed preemption MAY send a Notify message with a new 245 sub-code "Shared resources unavailable" under "Notify Error" code 246 (see [RFC4872]) to the end nodes of that protecting LSP. Upon 247 receipt of this Notify message, the end node MAY stop sending and 248 selecting normal traffic to/from its protecting LSP and try switching 249 the traffic to another protection LSP, if available. 251 When the shared resources become unavailable, the same Notify message 252 MAY also be generated by the intermediate node to all the end nodes 253 of the protecting LSPs that have lower SMP preemption priorities than 254 the one that has occupied the shared resources. These end nodes, in 255 case of a failure of the working LSP, MAY avoid trying to switch the 256 traffic to these protection LSPs that have been configured to use the 257 shared resources and try switching the traffic to other protection 258 LSPs, if available. 260 When the shared resources become available, a Notify message with a 261 new sub-code "Shared resources available" under "Notify Error" code 262 MAY be generated by the intermediate node. The recipients of this 263 Notify message are the end nodes of the lower priority protecting 264 LSPs that have been preempted and/or all the end nodes of the 265 protecting LSPs that have lower SMP preemption priorities than the 266 one that does not need the shared resources any more. 268 The following subsections detail how LSPs using SMP can be signaled 269 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 270 3473 [RFC3473]). This includes; 272 (1) the ability to identify a "secondary protecting LSP" (hereby 273 called the "secondary LSP") used to recover another primary 274 working LSP (hereby called the "protected LSP"), 276 (2) the ability to associate the secondary LSP with the protected 277 LSP, 279 (3) the capability to include information about the resources used 280 by the protected LSP while instantiating the secondary LSP, 282 (4) the capability to instantiate during the provisioning phase 283 several secondary LSPs in an efficient manner, and 284 (5) the capability to support activation of a secondary LSP after 285 failure occurrence via APS protocol in the data plane. 287 4.1. Identifiers 289 To simplify association operations, both LSPs (i.e., the protected 290 and the secondary LSPs) belong to the same session. Thus, the 291 SESSION object MUST be the same for both LSPs. The LSP ID, however, 292 MUST be different to distinguish between the protected LSP carrying 293 normal traffic and the secondary LSP. 295 A new LSP Protection Type "Shared Mesh Protection" is introduced to 296 the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two 297 LSPs. This LSP Protection Type value is applicable only to 298 bidirectional LSPs as required in [G808.3]. 300 4.2. Signaling Primary LSPs 302 The PROTECTION object (see [RFC4872]) is included in the Path message 303 during signaling of the primary working LSPs, with the LSP Protection 304 Type value set to "Shared Mesh Protection". 306 Primary working LSPs are signaled by setting in the PROTECTION object 307 the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION 308 object, the Association ID to the associated secondary protecting 309 LSP_ID. 311 Note: N bit is set to indicate that the protection switching 312 signaling is done via data plane. 314 4.3. Signaling Secondary LSPs 316 The PROTECTION object (see [RFC4872]) is included in the Path message 317 during signaling of the secondary protecting LSPs, with the LSP 318 Protection Type value set to "Shared Mesh Protection". 320 Secondary protecting LSPs are signaled by setting in the PROTECTION 321 object the S bit and the P bit to 1, the N bit to 1 and in the 322 ASSOCIATION object, the Association ID to the associated primary 323 working LSP_ID, which MUST be known before signaling of the secondary 324 LSP. Moreover, the Path message used to instantiate the secondary 325 LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see 326 [RFC4872]) that further allows for recovery resource sharing at each 327 intermediate node along the secondary path. 329 With this setting, the resources for the secondary LSP SHOULD be pre- 330 reserved, but not committed at the data plane level, meaning that the 331 internals of the switch need not be established until explicit action 332 is taken to activate this LSP. Activation of a secondary LSP and 333 protection switching to the activated protecting LSP is done using 334 APS protocol in the data plane. 336 After protection switching completes the protecting LSP SHOULD be 337 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 338 object. At this point, the link and node resources must be allocated 339 for this LSP that becomes a primary LSP (ready to carry normal 340 traffic). The formerly working LSP MAY be signaled with the A bit 341 set in the ADMIN_STATUS object (see [RFC3473]). 343 Support for extra traffic in SMP is for further study. Therefore, 344 mechanisms to setup LSPs for extra traffic are also for further 345 study. 347 4.4. SMP APS Configuration 349 SMP relies on APS protocol messages being exchanged between the nodes 350 along the path to activate a SMP protecting LSP. 352 In order to allow exchange of APS protocol messages, an APS channel 353 has to be configured between adjacent nodes along the path of the SMP 354 protecting LSP. This should be done before any SMP protecting LSP 355 has been setup by other means than GMPL signaling which are therefore 356 outside the scope of this document. 358 Depending on the APS protocol message format, the APS protocol may 359 use different identifiers than GMPLS signaling to identify the SMP 360 protecting LSP. 362 Since APS protocol is for further study in [G808.3], it can be 363 assumed that APS message format and identifiers are technology- 364 specific and/or vendor-specific. Therefore, additional requirements 365 for APS configuration are outside the scope of this document. 367 5. Updates to PROTECTION Object 369 GMPLS extension requirements for SMP introduce several updates to the 370 Protection Object (see [RFC4872]). 372 5.1. New Protection Type 374 A new LSP protection type "Shared Mesh Protection" is added in the 375 PROTECTION object. This LSP Protection Type value is applicable to 376 only bidirectional LSPs. 378 LSP (Protection Type) Flags: 380 0x11: Shared Mesh Protection 382 According to the rules defined in Section 14.2 of [RFC4872], all the 383 nodes along an SMP LSP MUST be SMP aware and therefore there are no 384 backward compatibility issues. 386 5.2. Updates on Notification and Operational Bits 388 N bit and O bit in the PROTECTION object as defined in [RFC4872] are 389 also updated to include applicability to SMP. 391 Notification (N): 1 bit 393 When set to 1, this bit indicates that the control plane message 394 exchange is only used for notification during protection 395 switching. When set to 0 (default), it indicates that the control 396 plane message exchanges are used for protection-switching 397 purposes. The N bit is only applicable when the LSP Protection 398 Type Flag is set to either 0x04 (1:N Protection with Extra- 399 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 400 Bidirectional Protection). In SMP, N bit MUST be set to 1. The N 401 bit MUST be set to 0 in any other case. 403 Operational (O): 1 bit 405 When set to 1, this bit indicates that the protecting LSP is 406 carrying the normal traffic after protection switching. The O bit 407 is only applicable when the P bit is set to 1, and the LSP 408 Protection Type Flag is set to either 0x04 (1:N Protection with 409 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 410 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 411 The O bit MUST be set to 0 in any other case. 413 5.3. Preemption Priority 415 The 32-bit Reserved field in the PROTECTION object defined in 416 [RFC4872] is updated as follows: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Reserved | Preempt Prio | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Preemption Priority (Preempt Prio): 8 bit 426 This field indicates the SMP preemption priority of a protecting 427 LSP, when the LSP Protection Type field indicates "Shared Mesh 428 Protection". A lower value has a higher priority. The decision 429 of how many priority levels to be operated in an SMP network is a 430 network operator's choice. 432 6. IANA Considerations 434 This document requests IANA to define two new sub-code values under 435 "Notify Error" code in Resource Reservation Protocol (RSVP) 436 parameters. 438 Value Description Reference 439 ----- ---------------------------- --------------- 440 TBD1 Shared resources unavailable (this document) 441 TBD2 Shared resources available (this document) 443 7. Security Considerations 445 No further security considerations than [RFC4872]. 447 8. Contributor 449 The following person contributed significantly to the content of this 450 document and should be considered as a co-author. 452 Yuji Tochio 453 Fujitsu 454 Email: tochio@fujitsu.com 456 9. References 458 9.1. Normative References 460 [G808.3] International Telecommunication Union, "Generic protection 461 switching - Shared mesh protection", ITU-T Recommendation 462 G.08.3, October 2012. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 470 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 471 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 472 . 474 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 475 Switching (GMPLS) Signaling Resource ReserVation Protocol- 476 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 477 DOI 10.17487/RFC3473, January 2003, 478 . 480 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 481 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 482 Recovery Functional Specification", RFC 4426, 483 DOI 10.17487/RFC4426, March 2006, 484 . 486 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 487 Ed., "RSVP-TE Extensions in Support of End-to-End 488 Generalized Multi-Protocol Label Switching (GMPLS) 489 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 490 . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 9.2. Informative References 498 [G873.3] International Telecommunication Union, "Optical transport 499 network - Shared mesh protection", ITU-T Recommendation 500 G.873.3, September 2017. 502 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 503 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 504 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 505 December 2014, . 507 Authors' Addresses 509 Jia He 510 Huawei Technologies 511 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 512 Shenzhen 513 China 515 Email: hejia@huawei.com 517 Italo Busi 518 Huawei Technologies 520 Email: italo.busi@huawei.com 521 Jeong-dong Ryoo 522 ETRI 523 218 Gajeongno 524 Yuseong-gu, Daejeon 34129 525 South Korea 527 Phone: +82-42-860-5384 528 Email: ryoo@etri.re.kr 530 Bin Yeong Yoon 531 ETRI 533 Email: byyun@etri.re.kr 535 Peter Park 536 KT 538 Email: peter.park@kt.com