idnits 2.17.1 draft-contreras-teas-slice-nbi-06.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 : ---------------------------------------------------------------------------- ** There are 52 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2022) is 779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-teas-ietf-network-slice-definition' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'I-D.nsdt-teas-ns-framework' is defined on line 1205, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational S. Homma 5 Expires: September 8, 2022 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 J. Tantsura 9 Microsoft 10 H. Nishihara 11 NTT 12 March 7, 2022 14 IETF Network Slice Use Cases and Attributes for Northbound Interface of 15 IETF Network Slice Controllers 16 draft-contreras-teas-slice-nbi-06 18 Abstract 20 This document analyses the needs of potential customers of network 21 slices realized with IETF techniques in several use cases, identifies 22 the functionalities for the North Bound Interface (NBI) of an IETF 23 Network Slice Controller to satisfy such requests. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document and terminology . . . . . . 3 61 3. Northbound Interface for IETF Network Slices . . . . . . . . 4 62 4. IETF Network Slice Use Cases . . . . . . . . . . . . . . . . 5 63 4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.1. 3GPP network slice . . . . . . . . . . . . . . . . . 6 65 4.1.1.1. Topology of the TN-NSS . . . . . . . . . . . . . 6 66 4.1.1.2. Traffic segregation and mapping to S-NSSAI list . 7 67 4.1.1.3. Reachability information . . . . . . . . . . . . 10 68 4.1.1.4. QoS profiling . . . . . . . . . . . . . . . . . . 10 69 4.1.2. Private 5G networks . . . . . . . . . . . . . . . . . 11 70 4.1.2.1. Structure Patterns of Private 5G system . . . . . 11 71 4.1.2.2. Use Cases Assumed in Private 5G . . . . . . . . . 11 72 4.1.2.3. Attributes Required in Private 5G . . . . . . . . 12 73 4.1.3. Generic network Slice Template . . . . . . . . . . . 12 74 4.1.4. Categorization of GST attributes . . . . . . . . . . 13 75 4.1.4.1. Attributes with direct impact on the IETF network 76 slice definition . . . . . . . . . . . . . . . . 14 77 4.1.4.2. Attributes with indirect impact on the IETF 78 network slice definition . . . . . . . . . . . . 14 79 4.1.4.3. Attributes with no impact on the IETF network 80 slice definition . . . . . . . . . . . . . . . . 15 81 4.1.5. Provisioning procedures . . . . . . . . . . . . . . . 16 82 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 16 83 4.2.1. Connectivity attributes . . . . . . . . . . . . . . . 16 84 4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 17 85 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 18 86 4.3.1. Connectivity attributes . . . . . . . . . . . . . . . 18 87 4.3.2. Provisioning procedures . . . . . . . . . . . . . . . 19 88 4.4. SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.4.1. SD-WAN Structure . . . . . . . . . . . . . . . . . . 19 90 4.4.2. Connectivity Attributes . . . . . . . . . . . . . . . 21 91 4.4.3. SD-WAN Endpoint Attributes . . . . . . . . . . . . . 22 92 4.4.4. SD-WAN UNI Attributes . . . . . . . . . . . . . . . . 23 93 4.5. Radio functional splits . . . . . . . . . . . . . . . . . 23 94 4.5.1. Attributes and procedures . . . . . . . . . . . . . . 24 95 4.6. Additional use cases . . . . . . . . . . . . . . . . . . 24 96 5. Summary of attributes and procedures . . . . . . . . . . . . 25 97 5.1. Summary of SLOs . . . . . . . . . . . . . . . . . . . . . 25 98 5.2. Summary of SLEs . . . . . . . . . . . . . . . . . . . . . 25 99 5.3. Summary of procedures . . . . . . . . . . . . . . . . . . 25 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 104 8.2. Informative References . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Introduction 109 A number of new technologies, such as 5G, NFV and SDN are not only 110 evolving the network from a pure technological perspective but also 111 are changing the concept in which new services are offered to the 112 customers [I-D.homma-slice-provision-models] by introducing the 113 concept of network slicing. 115 The transport network is an essential component in the end-to-end 116 delivery of services and, consequently, it is necessary to understand 117 what could be the way in which the transport network is consumed as a 118 slice. For a definition of IETF network slice refer to 119 [I-D.ietf-teas-ietf-network-slices]. 121 In this document it is assumed that there exists a (logically) 122 centralized component in the transport network, namely IETF Network 123 Slice Controller (NSC) with the responsibilities on the control and 124 management of the IETF network slices invoked for a given service, as 125 requested by IETF network slice customers. 127 This document analyses different use cases deriving the needs of 128 potential IETF network slice customers in order to identify the 129 functionality required on the North Bound Interface (NBI) of the NSC 130 to be exposed towards such IETF network slice customers. Solutions 131 to construct the requested IETF network slices are out of scope of 132 this document. 134 2. Conventions used in this document and terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC2119 [RFC2119]. 140 The terminology in this draft will be aligned in forthcoming versions 141 with the final terminology selected for describing the notion of IETF 142 network slice when applied to IETF technologies, as defined in 143 [I-D.ietf-teas-ietf-network-slices] . 145 The term "transport network" in the context of this draft refers in 146 broad sense to WAN, MBH, IP backbone and other network segments 147 implemented by IETF technologies. 149 3. Northbound Interface for IETF Network Slices 151 In a general manner, the transport network supports different kinds 152 of services. These services consume capabilities provided by the 153 transport network for deploying end-to-end services, interconnecting 154 network functions or applications spread across the network and 155 providing connectivity toward the final users of these services. 157 Under the slicing approach, a IETF network slice customer requests to 158 a IETF network slice controller a slice with certain characteristics 159 and parametrization. Such request it is assumed here to be done 160 through a NBI exposed by the NSC to the customer, as reflected in 161 Figure 1. 163 +--------------------+ 164 | | 165 | IETF Network | 166 | Slice Customer | 167 | | 168 +--------------------+ 169 A 170 | 171 | IETF Network 172 | Slice Controller 173 | NBI 174 | 175 V 176 +--------------------+ 177 | | 178 | IETF Network | 179 | Slice Controller | 180 | | 181 +--------------------+ 183 Figure 1: IETF network slice NBI concept 185 The functionality supported by the NBI depends on the requirements 186 that the slice customer has to satisfy. It is then important to 187 understand the needs of the slice customers as well as the way of 188 expressing them. 190 4. IETF Network Slice Use Cases 192 Different use cases for slice customers can be identified, as 193 described in the following sections. 195 4.1. 5G Services 197 5G services natively rely on the concept of network slicing. 5G is 198 expected to allow vertical customers to request slices in such a 199 manner that the allocated resources and capabilities in the network 200 appear as dedicated for them. 202 In network slicing scenarios, a vertical customer requests a network 203 operator to allocate a network slice instance (NSI) satisfying a 204 particular set of service requirements. The content/format of these 205 requirements are highly dependent on the networking expertise and use 206 cases of the customer under consideration. To deal with this 207 heterogeneity, it is fundamental for the network operator to define a 208 a unified ability to interpret service requirements from different 209 vertical customers, and to represent them in a common language, with 210 the purposes of facilitating their translation/mapping into specific 211 slicing-aware network configuration actions. In this regard, model- 212 based network slice descriptors built on the principles of 213 reproducibility, reusability and customizability can be defined for 214 this end. 216 As a starting point for such a definition, GSMA developed the idea of 217 having a universal blueprint that, being offered by network 218 operators, can be used by any vertical customer to order the 219 deployment of an NSI based on a specific set of service requirements. 220 The result of this work has been the definition of a baseline network 221 slice descriptor called Generic network Slice Template (GST). The 222 GST contains multiple attributes that can be used to characterize a 223 network slice. A Network Slice Type (NEST) describes the 224 characteristics of a network slice by means of filling GST attributes 225 with values based on specific service requirements. Basically, a 226 NEST is a filled-in version of a GST. Different NESTs allow 227 describing different types of network slices. For slices based on 228 standardized service types, e.g. eMBB, uRLLC and mIoT, the network 229 operator may have a set of readymade, standardized NESTs (S-NESTs). 230 For slices based on specific industry use cases, the network operator 231 can define additional NESTs. 233 Service requirements from a given vertical customer are mapped to a 234 NEST, which provides a self-contained description of the network 235 slice to be provisioned for that vertical customer. According to 236 this reasoning, the NEST can be used by the network operator as input 237 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 238 working on the translation of the GST/NEST attributes into NSI 239 related requirements, which are defined in the "ServiceProfile" data 240 type from the Network Slice Information Object Class (IOC) in 241 [TS28.541]. These requirements are used by the 3GPP Management 242 System to allocate the NSI across all network domains, including 243 transport network. The IETF network slice defines the part of that 244 NSI that is deployed across the transport network. 246 Despite the translation is an on-going work in 3GPP it seems 247 convenient to start looking at the GST attributes to understand what 248 kind of parameters could be required for the IETF network slice NBI. 250 4.1.1. 3GPP network slice 252 A 3GPP network slice represents a logical network that provides 253 specific capabilities and network characteristics, supporting the 254 service requirements of one or more network slice customers. The 255 service requirements of each network slice customer are captured into 256 a separate "ServiceProfile" artifact within the network slice class 257 (see Network Slicing NRM fragment in TS 28.541). 259 A 3GPP network slice spans from 5GNR access nodes to the UPF that 260 terminates the PDU session, i.e. PSA UPF. In this in-slice data 261 path, there are TN segments (e.g. backhaul) that are out of scope of 262 3GPP management domain. For the provisioning and operation of these 263 TN segments, usually referred to as transport Network Slice Subnets 264 (TN-NSS), the 3GPP management system relies on an external TN 265 management system, which hosts (among other components) the IETF NSC. 266 To proceed with this delegation, the 3GPP management system needs to 267 make available to the TN management system the information described 268 in the following sub-sections. 270 4.1.1.1. Topology of the TN-NSS 272 The TN management system needs to know the transport termination/end 273 points to determine the transport resources, either physical or 274 virtual nodes. 3GPP management system systems need to provide the 275 transport endpoints of 3GPP managed functions that are part of the 276 RAN-NSS (e.g., gNB-CU-UP, gNB-CU-CP) and CN-NSS (e.g., UPF, AMF), and 277 if applicable further information such as the next-hop router IP 278 address configured in a RAN-NSS or CN-NSS. The TN management system 279 should be able to correlate this with the transport network topology 280 and derive the site or border routers connecting to 3GPP managed 281 functions. 283 4.1.1.2. Traffic segregation and mapping to S-NSSAI list 285 As network functions can be shared by many network slices, it will be 286 necessary to segregate the traffic belonging to specific slices on 287 transport interfaces. 289 One option for traffic segregation is to assign application endpoints 290 to specific sets of S-NSSAI values. The transport network can map 291 packets to connectivity services based on local remote or remote 292 endpoints, provided that the allocation of S-NSSAI to endpoints is 293 known and exposed, and provided that the application endpoints are 294 visible on the transport layer. The application endpoints visible in 295 a RAN-NSS and CN-NSS are already mapped to a specific set of S-NSSAI. 296 Figure 2 illustrates an example of this solution, whereby a 3GPP 297 network slice with S-NSSAI=1 is mapped to specific application 298 endpoints (e.g., N3 tunnel endpoint 1) by the access network node. 299 In this example, the TN management system decides to map application 300 endpoints 1 and 2 to the same transport connectivity service A. This 301 mapping is implemented by the site router connecting to the access 302 network node. On the core network slice, a similar mapping is done 303 by the border router. Demultiplexing the packet streams belonging to 304 different transport interfaces is based on regular routing and 305 reachability of endpoint IP addresses. 307 Transport Interface Transport Interface 308 (App_EP "x" <-> CSR) (BR <-> App_EP "x") 310 +--------------+ +-------+ +-------+ +--------------+ 311 +---|----+ +----|----+ | | | | +---|-----+ +---|----+ 312 |NSS-AN 1|----| App_EP 1|<-->|-- | | --|<-->|App_EP 1 |----|NSS-CN 1| 313 +---|----+ +----|----+ | \ +-|--Transport-----+ / | +---|-----+ +---|----+ 314 | | | --| Connectivity |-- | | | 315 +---|----+ +----|----+ | / +-|-----"A"--------+ \ | +---|-----+ +---|----+ 316 |NSS-AN 2|----| App_EP 2|<-->|-- | | --|<-->|App_EP 2 |----|NSS-CN 2| 317 +---|----+ +----|----+ | | | | +---|-----+ +---|----+ 318 | | | | | | | | 319 +---|----+ | | | | | | +---|----+ 320 |NSS-AN 3|- | | | | | | |NSS-CN 3| 321 +---|----+ \ +----|----+ | +----Transport-----+ | +---|-----+ +---|----+ 322 | --| App_EP 3|<-->|-----| Connectivity |-----|<-->|App_EP 3 |-- | 323 +---|----+ / +----|----+ | +-------"B"--------+ | +---|-----+ \ +---|----+ 324 |NSS-AN 4|- | | | | | | -|NSS-CN 4| 325 +---|----+ | | | | | | +---|----+ 326 +--------------+ +-------+ +-------+ +--------------+ 328 Access network node(s) Cell Site Router (CSR) Border Router (BR) Core network node(s) 330 S-NSSAI=1: {NSS-AN 1, App_EP 1, Transport Connectivity A, App_EP 1, NSS-CN 1} 331 S-NSSAI=2: {NSS-AN 2, App_EP 2, Transport Connectivity A, App_EP 2, NSS-CN 2} 332 S-NSSAI=4: {NSS-AN 4, App_EP 3, Transport Connectivity B, App_EP 3, NSS-CN 3} 334 Figure 2: Mapping of S-NSSAI to specific application endpoints 336 Despite the simplicity of the above-referred approach, notice that it 337 is not a universal solution as the application endpoint addresses are 338 not always visible to the TN, for example when they are encrypted by 339 IPSec tunnels. In such a case, the application endpoints are not 340 visible to the site router, and thus cannot be used for transport 341 connectivity mappings. To deal with these situations, an alternative 342 solution is to use the concept of logical transport interfaces. A 343 logical transport interface is a virtual interface separate from 344 application endpoints; it can be for example a specific IP address / 345 VLAN combination that corresponds to an IPSec termination point, an 346 identifier (e.g., MPLS label, segment ID) that the TN recognizes, or 347 it can be just a logical interface defined on top of top a physical 348 transport interface. As long as the interface identity can derived 349 from packet headers, the TN nodes can perform the mapping to 350 transport connectivity services. In this regard, it is useful to 351 indicate to the TN which traffic types are carried over an interface 352 (e.g., N3 user plane packets, N2 control plane packets, etc.). 354 Figure 3 illustrates an example on the use of this solution. As 355 seen, logical transport need to be exposed from 3GPP management 356 system to TN management system, so that the latter can create 357 transport network topology and determine the TN resources to support 358 the 3GPP slice. 360 Logical transport interface, Logical transport interface, 361 exposed by RAN NSSMF exposed by CN NSSMF 363 +--------+ +-------+ +-------+ +-------+ 364 | | | | | | | | 365 +---|----+ +----Logical-----+ | | +----Logical----+ +---|----+ 366 |NSS-AN 1|--| Transport |- | | -| Transport |--|NSS-CN 1| 367 +---|----+ +--Interface 1---+ \ +---Transport----+ / +--Interface 1--+ +---|----+ 368 | | | --| Connectivity |-- | | | 369 +---|----+ +----Logical-----+ / +-------"A"------+ \ +----Logical----+ +---|----+ 370 |NSS-AN 2|--| Transport |- | | -| Transport |--|NSS-CN 2| 371 +---|----+ +--Interface 2---+ | | +--Interface 1--+ +---|----+ 372 | | | | | | | | 373 +---|----+ | | | | | | +---|----+ 374 |NSS-AN 3|- | | | | | | -|NSS-CN 3| 375 +---|----+ \+----Logical-----+ +---Transport---+ +----Logical-----+/ +---|----+ 376 | | Transport |----| Connectivity |----| Transport | | 377 +---|----+ /+--Interface 2---+ +-------"B"-----+ +--Interface 1---+\ +---|----+ 378 |NSS-AN 4|- | | | | | | -|NSS-CN 4| 379 +---|----+ | | | | | | +---|----+ 380 | | | | | | | | 381 +--------+ +-------+ +-------+ +-------+ 383 Access network Cell Site Border Router Core network 384 node(s) Router (CSR) (BR) node(s) 386 S-NSSAI=1: {NSS-AN 1, Logical Transport Interface 1, Transport Connectivity A, 387 Logical Transport Interface 1, NSS-CN 1} 388 S-NSSAI=2: {NSS-AN 2, Logical Transport Interface 2, Transport Connectivity A, 389 Logical Transport Interface 2, NSS-CN 2} 390 S-NSSAI=4: {NSS-AN 4, Logical Transport Interface 3, Transport Connectivity B, 391 Logical Transport Interface 3, NSS-CN 4} 393 Figure 3: Logical Transport Interfaces 395 For traffic segregation, though solutions might be valid, 3GPP 396 prefers the second solution: on the use of concept of transport 397 logical interface. The reason is that it does not impose 1:1 mapping 398 between application endpoint and transport interface (allowing for 399 better redundancy) and that it always works, no matter if encryption. 400 To support this solution, the 3GPP has recently extended the Network 401 Slice NRM fragment, including a new Information Object Class called 402 EP_Transport. This class provides a complete characterization of the 403 logical transport interface, including transport level information 404 (i.e., IP address, reachability information, QoS profile) and the set 405 of application endpoints aggregated to this interface. For further 406 information on reachability information and QoS profile, see next 407 subsections. For further details on fields of EP_Transport, see 408 Network Slice NRM fragment in TS 28.541. 410 4.1.1.3. Reachability information 412 Each physical or logical transport interface will carry the traffic 413 associated with some 3GPP application endpoints that may be using IP 414 addresses separate from the transport interface. These IP addresses 415 must be reachable within the TN-NSS, and hence they need to be 416 advertised to populate forwarding tables. A 3GPP network function 417 can advertise such reachability information by running a dynamic 418 routing protocol towards the next hop router. If that is not 419 possible, it can create association between the reachability data 420 with the logical transport interface and expose it towards the 3GPP 421 and TN management system. This information can be derived from the 422 IP addresses available for application and transport endpoints. 424 4.1.1.4. QoS profiling 426 Each TN-NSS may be associated a "TNSliceSubnetProfile", which hosts 427 the SLO requirements (e.g., guaranteed throughput, bounded latency, 428 maximum jitter) that the TN-NSS must support. "TNSliceSubnetProfile" 429 is a 3GPP artifact that result from the decomposition of e2e service 430 requirements ("ServiceProfile" artifact ) into domain-specific 431 service requirements ("RANSliceSubnetProfile", "CNSliceSubnetProfile" 432 and "TNSliceSubnetProfile") applicable to RAN-NSS, CN-NSS and TN-NSS 433 respectively. Unlike "RANSliceSubnetProfile" and 434 "CNSliceSubnetProfile", there is not agreement yet on the specific 435 parameters to be captured by the "TNSliceSubnetProfile". Further 436 work in this regard in the upcoming 3GPP SA5 meetings. 438 Upon receiving the "TNSliceSubnetProfile" from the 3GPP management 439 system, the TN management system translates the SLO requirements 440 therein into a QoS profile, which includes applicability and use of 441 DSCPs and other QoS related properties onto the TN-NSS realization. 442 To enable this, each logical interface may have an associated QoS 443 profile. The QoS profile is just a reference to the detailed profile 444 parameters which are logically provisioned on both sides of a logical 445 transport interface. 447 4.1.2. Private 5G networks 449 Private 5G is one of variations of 5G service provision. Private 5G 450 allows unlicensed as well as licensed companies to establish and 451 operate 5G networks, with frequency band assigned for private 5G, in 452 their own companies. 454 Private 5G can be customized flexibly rather than public 5G, and thus 455 it enables us to provide networks specialized for their use cases. 456 Private 5G is also called non-public 5G, and its deployment scenarios 457 and service attributes are described in (ref. [TS23.501]). 459 4.1.2.1. Structure Patterns of Private 5G system 461 In Private 5G, a Service Provider does not necessarily have its own 462 resources (e.g., radio bases, transit network and server resources 463 for 5G CP functions) and can flexibly customize and deploy by 464 selecting and combining various resources. 466 Private 5G has several structure patterns: 468 o Pattern 1: a service provider has all resources including radio 469 bases, transit networks, and server resources for 5G CP functions. 471 o Pattern 2: a service provider has radio bases and server resources 472 for 5G CP functions, and lends transit networks from other network 473 operators. 475 o Pattern 3: a service provider has only radio bases and lends 476 transit networks and server resources for 5G CP functions from 477 other network operators and data center companies. 479 In pattern 2 and 3, it is assumed that a service provider uses 480 network slices provided by other companies. 482 4.1.2.2. Use Cases Assumed in Private 5G 484 Private 5G provides a wireless communication environment which has 485 specific features depending on applications or usage, within limited 486 areas. From such aspects, within 5G use cases (ref. [TS22.261]), 487 the following communication types and use cases could be especially 488 expected to be provided with private 5G. 490 o High-bandwidth and reliable communication: 492 * VR streaming 494 o Low latency and jitter: 496 * Smart factory 498 * Remote automated robot operation (e.g., robot concierge/ 499 assistant, robot waiter, drone) 501 o High-bandwidth on up-link and low latency and jitter 503 * Remote surgery 505 * Uploading of high-definition video 507 4.1.2.3. Attributes Required in Private 5G 509 Private 5G has some distinguished requirements to network slice as 510 below. 512 o QoS customization: 514 * assured bandwidth 516 * assured latency and jitter 518 * customization of UL/DL rate on throughput (e.g., for video 519 upstreaming consumes much UL bandwidth) 521 o Multi-homing (for high reliability, preparing multiple paths 522 traverse different physical routes) 524 o Performance monitoring (e.g., for connectivity status and service 525 availability of devices) 527 o Traffic flow separation/segregation (e.g., segregation of user 528 plane and other communications physically and/or logically) 530 4.1.3. Generic network Slice Template 532 The structure of the GST is defined in [GSMA]. The template defines 533 a total of 35 attributes. For each of them, the following 534 information is provided: 536 o Attribute definition, which provides a formal definition of what 537 the attribute represents. 539 o Attribute parameters, including: 541 * Value, e.g. integer, float. 543 * Measurement unit, e.g. milliseconds, Gbps 544 * Example, which provides examples of values the parameter can 545 take in different use cases. 547 * Tag, which allow describing the type of parameter, according to 548 its semantics. An attribute can be tagged as a 549 characterization attribute or a scalability attribute. If it 550 is characterization attribute, it can be further tagged as a 551 performance-related attribute, a functionality-related 552 attribute or an operation-related attribute. 554 * Exposure, which allow describing how this attribute interact 555 with the slice customer, either as an API or a KPI. 557 o Attribute presence, either mandatory, conditional or optional. 559 Attributes from GST can be used by the network operator (slice 560 controller) and a vertical customer (slice customer) to agree SLA. 562 GST attributes are generic in the sense that they can be used to 563 characterize different types of network slices. Once those 564 attributes become filled with specific values, it becomes a NEST 565 which can be ordered by slice customers. 567 4.1.4. Categorization of GST attributes 569 Not all the GST attributes as defined in [GSMA] have impact in the 570 transport network since some of them are specific to either the radio 571 or the mobile core part. 573 In the analysis performed in this document, the attributes have been 574 categorized as: 576 o Directly impactive attributes, which are those that have direct 577 impact on the definition of the IETF network slice, i.e., 578 attributes that can be directly translated into requirements 579 required to be satisfied by a IETF network slice. 581 o Indirectly impactive attributes, which are those that impact in an 582 indirect manner on the definition of the IETF network slice, i.e., 583 attributes that indirectly impose some requirements to a IETF 584 network slice. 586 o Non-impactive attributes, that are those which do not have impact 587 on the IETF network slice at all. 589 The following sections describe the attributes falling into the three 590 categories. 592 4.1.4.1. Attributes with direct impact on the IETF network slice 593 definition 595 The following attributes impose requirements in the IETF network 596 slice 598 o Availability 600 o Deterministic communication 602 o Downlink throughput per network slice 604 o Energy efficiency 606 o Group communication support 608 o Isolation level 610 o Maximum supported packet size 612 o Mission critical support 614 o Performance monitoring 616 o Slice quality of service parameters 618 o Support for non-IP traffic 620 o Uplink throughput per network slice 622 o User data access (i.e., tunneling mechanisms) 624 4.1.4.2. Attributes with indirect impact on the IETF network slice 625 definition 627 The following attributes indirectly impose requirements in the IETF 628 network slice to support the end-to-end service. 630 o Area of service (i.e., the area where terminals can access a 631 particular network slice) 633 o Delay tolerance (i.e., if the service can be delivered when the 634 system has sufficient resources) 636 o Downlink (maximum) throughput per UE 638 o Network functions owned by Network Slice Customer 639 o Maximum number of (concurrent) PDU sessions 641 o Performance prediction (i.e., capability to predict the network 642 and service status) 644 o Root cause investigation 646 o Session and Service Continuity support 648 o Simultaneous use of the network slice 650 o Supported device velocity 652 o UE density 654 o Uplink (maximum) throughput per UE 656 o User management openness (i.e., capability to manage users' 657 network services and corresponding requirements) 659 o Latency from (last) UPF to Application Server 661 4.1.4.3. Attributes with no impact on the IETF network slice definition 663 The following attributes do not impact the IETF network slice. 665 o Location based message delivery (not related to the geographical 666 spread of the network slice itself but with the localized 667 distribution of information) 669 o MMTel support, i.e. support of and Multimedia Telephony Service 670 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 672 o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network 673 slice. 675 o Maximum number of (simultaneous) UEs 677 o Positioning support 679 o Radio spectrum 681 o Synchronicity (among devices) 683 o V2X communication mode 685 o Network Slice Specific Authentication and Authorization (NSSAA) 687 4.1.5. Provisioning procedures 689 3GPP identifies in [TS28.541] a number of procedures for the 690 provisioning of a network slice in general. It can be assumed that 691 similar procedures may also apply to a transport slice, facilitating 692 a consistent management and control of end-to-end slices. 694 The envisioned procedures are the following: 696 o Slice instance allocation: this procedure permits to create a new 697 slice instance (or reuse an existing one). 699 o Slice instance de-allocation: this procedure decommissions a 700 previously instantiated slice. 702 o Slice instance modification: this procedure permits the change in 703 the characteristics of an existing slice instance. 705 o Get slice instance status: this procedure helps to retrieve run- 706 time information on the status of a deployed slice instance. 708 o Retrieval of slice capabilities: this procedure assists on getting 709 information about the capabilities (e.g. maximum latency 710 supported). 712 All these procedures fit in the operation of transport network 713 slices. 715 4.2. NFV-based services 717 NFV technology allows the flexible and dynamic instantiation of 718 virtualized network functions (and their composition into network 719 services) on top of a distributed, cloud-enabled compute 720 infrastructure. This infrastructure can span across different points 721 of presence in a carrier network. By leveraging on transport network 722 slicing, connectivity services established across geographically 723 remote points of presence can be enriched by providing additional QoS 724 guarantees with respect present state-of-the-art mechanisms, as 725 conventional L2/L3 VPNs. 727 4.2.1. Connectivity attributes 729 The connectivity services are expressed through a number of 730 attributes as listed: 732 o Incoming and outgoing bandwidth: bandwidth required for the 733 connectivity services (in Mbps). 735 o Qos metrics: set of metrics (e.g., cost, latency and delay 736 variation) applicable to a specific connectivity service 738 o Directionality: indication if the traffic is unidirectional or 739 bidirectional. 741 o MTU: value of the largest PDU to be transmitted in the 742 connectivity service. 744 o Protection scheme: indication of the kind of protection to be 745 performed (e.g., 1;1, 1+1, etc.) 747 o Connectivity mode: indication of the service is point-to-point of 748 point-to-multipoint 750 All those attributes will assist on the characterization of the 751 connectivity slice to be deployed, and thus, are relevant for the 752 definition of a IETF network slice supporting such connectivity. 754 4.2.2. Provisioning procedures 756 ETSI NFV defines the role of WAN Infrastructure Manager (WIM) as the 757 component in charge of managing and controlling the connectivity 758 external to the PoPs. In [IFA032] a number of interfaces are 759 identified to be exposed by the WIM for supporting the multi-site 760 connectivity, thus representing the capabilities expected for a 761 transport network slice, as well, in case of satisfying such 762 connectivity needs by means of the slice concept. 764 The interfaces considered are the following: 766 o Multi-Site Connectivity Service (MSCS) Management: this interface 767 permits the creation, termination, update and query of MSCSs, 768 including reservation. It also enables subscription for 769 notifications and information retrieval associated to the 770 connectivity service. 772 o Capacity Management: this interface allows querying about the 773 capacity (e.g. bandwidth), topology, and network edge points of 774 the connectivity service, as well as about information of consumed 775 and available capacity on the underlying network resources. 777 o Fault Management: this interface serves for the provision of 778 alarms related to the MSCSs. 780 o Performance Management: this interface assists on the retrieval of 781 performance information (measurement results collection and 782 notifications) related to MSCSs. 784 4.3. Network sharing 786 Network sharing is one of the means network operators exploit for 787 increasing efficiencies. There are different scenarios of network 788 sharing, being especially popular in the deployment of mobile 789 networks, typically referred to as Radio Access Network (RAN) 790 sharing. From an operational perspective, in RAN sharing we have two 791 roles: master operator, being the actor (e.g. infrastructure 792 provider, network operator) to which the deployment and daily 793 operation of shared RAN elements are entrusted to; and the 794 participant operators, who are the mobile operators who share the RAN 795 facilities provided by the master operator. Note that in this 796 context the master and participant operator can be seen as provider 797 and customer, respectively. 799 While there exist different modes of RAN sharing [TS23.251], 800 including passive RAN sharing (infrastructure site sharing) and 801 active RAN sharing (e.g. Multi-Operator Core Networks or MOCN), most 802 of the cases require the establishment of separated connections in 803 order to separate the traffic per participant operator. Such 804 connections typically extend from the cell site to some pre-defined 805 and agreed interconnection points, from which the traffic is routed 806 and delivered to individual participant operators. 808 The above-referred connections can have specific attributes. Aspects 809 like guaranteed bandwidth (in line with the expected load from the 810 aggregated cells), redundancy, bounded latency (per kind of traffic), 811 or secure delivery of the information should be considered. 813 The master operator is the one in charge of provisioning the 814 connections and collecting management data (e.g. performance 815 measurements, telemetry, fault alarms, trace data) for individual 816 participant operators. The use of network slicing could make the 817 network sharing approach more flexible by allowing the other 818 operators control and manage the established connections [MEF]. 820 The implications of the RAN sharing scenario here described can be 821 extended to either fixed networks or even to mobile networks 822 leveraging on radio functional split (i.e., including fronthaul and 823 midhaul network segments). 825 4.3.1. Connectivity attributes 827 The connections for RAN sharing typically consider attributes like: 829 o Maximum and Guaranteed Bit Rate (MBR and GBR respectively). 831 o Bounded latency (e.g., for user plane, control plane, etc) 832 o Packet loss rate. 834 o IP addressing (consistent among the operators sharing the 835 infrastructure). 837 o L2/L3 reachability. 839 o Recovery time (on the event of failures). 841 o Secure connection (e.g., encryption support). 843 4.3.2. Provisioning procedures 845 The expected provisioning procedures are: 847 o Connection provisioning between site and interconnection point. 848 Those connections could evolve in time in terms of capacity 849 depending on the capacity growth of each particular site. 851 o Collection of management data, including performance measurements, 852 fault alarms and trace data. 854 4.4. SD-WAN 856 SD-WAN is a solution to provide a virtual overlay network for 857 connecting between customer's sites, (virtual) private cloud, or 858 public cloud/Internet. SD-WAN operates over one or more underlay 859 networks, and enables to offer more differentiated service delivery 860 capabilities. SD-WAN can be esteemed as a type of network slices or 861 can be established over underlay networks provided as network slices. 862 The definitions, specification, service attributes, and framework of 863 SD-WAN is defined in Metro Ethernet Forum ([MEF-70]). 865 SD-WAN forwards traffic based on application flows, and the policies 866 include rules and constraints on the forwarding of the application 867 flows. In SD-WAN, it may be required from the customer to adjust the 868 behaviors based on its needs in near real time. The service provider 869 is required to monitor the performance of the service and modify the 870 forwarding policies based on the real-time telemetry from the 871 underlying network components. 873 4.4.1. SD-WAN Structure 875 SD-WAN has three logical constructs: 877 o SD-WAN virtual connection 879 o SD-WAN virtual connection endpoint 880 o SD-WAN UNI 882 Several additional components may be visible to the customer. These 883 include: 885 o Customer network 887 o Service provider network 889 o Underlay connectivity 891 o Tunnel virtual connection 893 The following figure shows the overview of SD-WAN structure. In this 894 case, the customer sites are connected with underlay connectivity#1 895 and they are also connected to remote private cloud with underlay 896 connectivity#2. An SD-WAN endpoint is usually located in each 897 customer network site as a CPE or a customer edge, and it allocates 898 application flow to appropriate underlay connectivity. 900 ,----. 901 | \ 902 ,-/ Private`--. 903 | cloud | 904 `---+---+-----/ 905 - - - - |EP | - - - - - 906 | +---+ | 907 | # | 908 /---------\| # |/----------\ 909 | Customer +--+=========#===========+--+ Customer | 910 | Network |EP|. . . . . . . . . . .|EP| Network | 911 | site A +--+ Service Provider +--+ site B | 912 \--------/| Network |\--------/ 913 | - - - - - - - - - - - - - | 914 | | 915 SD-WAN UNI SD-WAN UNI 917 * Legend 918 . . . : Underlay connectivity#1 919 ===== : Underlay Connectivity#2 920 EP : SD-WAN Endpoint 922 Figure 4: Overview of SD-WAN Structure 924 SD-WAN may be provided as a network slice, or it is realized on 925 several network slices provided as underlay connectivities. In the 926 former case, a network slice PE will be mapped to CE in SD-WAN. In 927 the later case, PEs of the provider of underlay connectivities will 928 behave as network slice PEs. 930 4.4.2. Connectivity Attributes 932 SD-WAN defined in MEF-70 has several attributes on its connectivity 933 as below: 935 o SD-WAN Identifier: the value is a string that is used by the 936 customer and service provider to uniquely identify an SD-WAN 937 connectivity. 939 o Endpoint list: the value is a list contains endpoint identifiers 940 and their connected endpoints. 942 o Service Uptime Objective: the value is the proportion of time 943 that the connectivity service is working during a given time 944 period. 946 o Reserved Prefixes: the values are IP prefixes reserved by the 947 service provider for use for SD-WAN within its own network or for 948 distribution to the customer via DHCP or SLAAC. 950 o List for Policies: the value is a list of policies applied to 951 application flows and application flow groups at endpoints. An 952 SD-WAN policy list contains policy name and list of policy 953 criteria. Support of the criteria listed below would be required: 955 * Encryption: indicates whether or not the application flow 956 requires encryption 958 * Public-Private: indicates whether the application flow can 959 traverse public or private underlay connectivity services (or 960 both). 962 * Internet-Breakout: indicates whether the application flow 963 should be forwarded to an Internet destination. 965 * Billing-Method: indicate the application flow can be sent over 966 an underlay connectivity service that has usage-based or flat- 967 rate billing. 969 * Backup: indicates whether this application flow can use a TVC 970 designated as aEURbackupaEUR. 972 * Bandwidth: specifies a rate limit on the application flow. 974 o List of Application Flow Groups: the value is a list of 975 application flow groups that application flows can be members of. 976 An application flow group list contains application flow group 977 name and application flow group policy. 979 o List of Application Flows: the value is a list of the application 980 flows that are recognized by the SD-WAN. An application flow list 981 contains application flow name, list of application flow criteria, 982 and application flow group name. The criteria is listed below: 984 * Ethertype 986 * C-VLAN ID list 988 * IPv4 source address 990 * IPv4 destination address 992 * IPv4 source or destination address 994 * IPv4 protocol list 996 * IPv6 source address 998 * IPv6 destination address 1000 * IPv6 source or destination address 1002 * IPv6 next header list 1004 * TCP/UDP source port list 1006 * TCP/UDP destination port list 1008 * Application identifier 1010 * any 1012 4.4.3. SD-WAN Endpoint Attributes 1014 SD-WAN contains some endpoints as boundary nodes between underlay 1015 connections and customers sites. [MEF-70] defines some attributes 1016 for SD-WAN endpoints as below: 1018 o Endpoint Identifier: the value is for identification of SD-WAN 1019 endpoint for management purposes. 1021 o Endpoint UNI: the value is for identification of the UNI that the 1022 endpoint is associated with. 1024 o Endpoint policy map: the value is for mapping policies to 1025 application flows and application flow groups. 1027 4.4.4. SD-WAN UNI Attributes 1029 SD-WAN UNI is a reference point that represents the demarcation 1030 between the responsibility of the customer and the responsibility of 1031 the provider. Some attributes for UNI is defined in [MEF-70] as 1032 below: 1034 o SD-WAN UNI Identifier: the value is for identification of the UNI 1035 for management purposes. 1037 o SD-WAN UNI L2 Interface: the value describes the underlay L2 1038 interface for the UNI. 1040 o SD-WAN UNI Maximum L2 Frame Size: the value specifies the maximum 1041 length L2 frame that is accepted by the provider. 1043 o SD-WAN UNI IPv4 connection addressing: the value describes IPv4 1044 connection address mechanisms (e.g., Static or DHCP). 1046 o SD-WAN UNI IPv6 connection addressing: the value describes IPv6 1047 connection address mechanisms (e.g., DHCP, SLAAC, Static or Link- 1048 Local-only). 1050 4.5. Radio functional splits 1052 The disaggregation of the software stack in radio base stations 1053 allows the centralization of some of the radio processing functions. 1054 O-RAN is promoting the interoperability of implementations of radio 1055 functional splits, defining an architecture where three main entities 1056 can be considered: the Radio Unit (RU), with some basic processing, 1057 the Distributed Unit (DU) with the rest of real-time processing 1058 capabilities, and the Centralized Unit (CU) with the non-real-time 1059 processing of the software stack. The network segment between RU and 1060 DU is known as fronthaul (FH), while the segment between DU and CU is 1061 referred as midhaul (MH). Figure 5 shows this situation. 1063 ......................................... 1064 : Radio functional split : 1065 +-------+ : : 1066 | radio | :+----+ Fronthaul +----+ Midhaul +----+ : Backhaul +-----+ 1067 | base | <=> :| RU |<=========>| DU |<=======>| CU | :<========>| UPF | 1068 |station| :+----+ +----+ +----+ : +-----+ 1069 +-------+ : : 1070 : : 1071 :.......................................: 1073 Figure 5: Logical Transport Interfaces 1075 The fronthaul leverages on eCPRI protocol which can be transported 1076 directly on Ethernet frames or encapsulated in IP/UDP (for the user 1077 plane). The midhaul can be transported in a similar way as the 1078 backhaul. 1080 With current specifications, individual service flows being carried 1081 by FH cannot be distinguished, so no possibility of differentiating 1082 connectivity slices at that point. Similar thing happens for MH. 1083 The only possible differentiation per flow can happen in downstream 1084 direction from CU to DU, but this basically can only help for 1085 policing traffic at that point (i.e., slice is yet the same). 1087 Advanced scenarios such as RU sharing could allow traffic 1088 differentiation per mobile operator based on e.g. vlans, being each 1089 of those vlans mapped to a different slice. 1091 4.5.1. Attributes and procedures 1093 The attributes of IETF network slices for the conveniently supported 1094 the radio functional split are based on main characteristics of FH/ 1095 MH: Latency, BW, and packet loss, as specified in [O-RAN]. 1096 Geographical location could have an impact due to latency 1097 restrictions for FH. 1099 Regarding slice management procedures, it can be assumed a similar 1100 lifecycle as in 3GPP slices. 1102 4.6. Additional use cases 1104 This is a placeholder for describing additional use cases (e.g., data 1105 center interconnection, etc). To be completed. 1107 5. Summary of attributes and procedures 1109 After analysing the different use cases, a number of attributes and 1110 procedures can be identified to provide IETF Network Slice services. 1111 Following sections summarize the findings per SLO, SLE and 1112 procedures. 1114 Editor Note: this summary is yet under review. 1116 5.1. Summary of SLOs 1118 The following SLOs can be considered common to the majority of use 1119 cases. 1121 o Bandwidth (or throughput), as an indication of the amount of 1122 traffic allowed to the delivered. It can be expressed 1123 unidirectional or bidirectional. 1125 o Latency, as an indication of the maximum delay expected in a 1126 connection. 1128 o Jitter (or delay variation), as an indication of the maximum 1129 variation on the delay expected in a connection. 1131 o Packet loss, as an indication of the bounded limit of packet 1132 losses allowed in a connection 1134 o To be completed 1136 5.2. Summary of SLEs 1138 To be completed. 1140 5.3. Summary of procedures 1142 The following procedures allow to cover the analysed use cases. 1144 o IETF Network Slice provision, including allocation and de- 1145 allocation of the slice. 1147 o IETF Network Slice modification (or update) of an existing 1148 allocated slice. 1150 o Retrieval (or query) of IETF Network Slice status and capabilities 1151 of an existing allocated slice. 1153 o IETF Network Slice reservation, allowing a late instantiation of 1154 the slice. 1156 o IETF Network Slice fault management, permitting the collection of 1157 alarms associated to the IETF NEtwork Slice. 1159 o IETF Network Slice performance management, permitting the 1160 retrieval of performance measurements associated to the IETF 1161 NEtwork Slice. 1163 6. Security Considerations 1165 This draft does not include any security considerations. 1167 7. IANA Considerations 1169 This draft does not include any IANA considerations 1171 8. References 1173 8.1. Normative References 1175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1176 Requirement Levels", BCP 14, RFC 2119, 1177 DOI 10.17487/RFC2119, March 1997, 1178 . 1180 8.2. Informative References 1182 [GSMA] "Generic Network Slice Template, version 3.0", NG.116 , 1183 May 2020. 1185 [I-D.homma-slice-provision-models] 1186 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V. 1187 R., Lopez, D. R., Contreras, L. M., Ordonez-Lucena, J. A., 1188 Martinez-Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., 1189 and X. D. Foy, "Network Slice Provision Models", draft- 1190 homma-slice-provision-models-02 (work in progress), 1191 November 2019. 1193 [I-D.ietf-teas-ietf-network-slice-definition] 1194 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 1195 J. Tantsura, "Definition of IETF Network Slices", draft- 1196 ietf-teas-ietf-network-slice-definition-01 (work in 1197 progress), February 2021. 1199 [I-D.ietf-teas-ietf-network-slices] 1200 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 1201 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 1202 Network Slices", draft-ietf-teas-ietf-network-slices-08 1203 (work in progress), March 2022. 1205 [I-D.nsdt-teas-ns-framework] 1206 Gray, E. and J. Drake, "Framework for IETF Network 1207 Slices", draft-nsdt-teas-ns-framework-05 (work in 1208 progress), February 2021. 1210 [IFA032] "IFA032 Interface and Information Model Specification for 1211 Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA 1212 032 V3.2.1 , April 2019. 1214 [MEF] "Slicing for Shared 5G Fronthaul and Backhaul", MEF White 1215 paper , April 2020. 1217 [MEF-70] "SD-WAN Service Attributes and Services", MEF-70 , July 1218 2019. 1220 [O-RAN] "O-RAN Xhaul Transport Requirements 1.0", O-RAN.WG9.XTRP- 1221 REQ-v01.00 , November 2020. 1223 [TS23.251] 1224 "TS 23.251 Network Sharing; Architecture and functional 1225 description (Release 16) V16.0.0.", 3GPP TS 23.251 1226 V16.0.0 , July 2020. 1228 [TS28.530] 1229 "TS 28.530 Management and orchestration; Concepts, use 1230 cases and requirements (Release 16) V16.0.0.", 3GPP TS 1231 28.530 V16.0.0 , September 2019. 1233 [TS28.541] 1234 "TS 28.541 Management and orchestration; 5G Network 1235 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 1236 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 1238 Authors' Addresses 1240 Luis M. Contreras 1241 Telefonica 1242 Ronda de la Comunicacion, s/n 1243 Sur-3 building, 3rd floor 1244 Madrid 28050 1245 Spain 1247 Email: luismiguel.contrerasmurillo@telefonica.com 1248 URI: http://lmcontreras.com/ 1249 Shunsuke Homma 1250 NTT 1251 Japan 1253 Email: shunsuke.homma.ietf@gmail.com 1255 Jose A. Ordonez-Lucena 1256 Telefonica 1257 Ronda de la Comunicacion, s/n 1258 Sur-3 building, 3rd floor 1259 Madrid 28050 1260 Spain 1262 Email: joseantonio.ordonezlucena@telefonica.com 1264 Jeff Tantsura 1265 Microsoft 1267 Email: jefftant.ietf@gmail.com 1269 Hidetaka Nishihara 1270 NTT 1272 Email: hidetaka.nishihara1104@gmail.com