idnits 2.17.1 draft-oki-pce-gmpls-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 1090. -- Found old boilerplate from RFC 3978, Section 5.5 on line 48. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1019 has weird spacing: '...in PCEs and G...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7010 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: 'OKI-INTERWORK' is mentioned on line 1138, but not defined == Missing Reference: 'LSP-HIERARCHY' is mentioned on line 1126, but not defined == Missing Reference: 'OKI-GTEP' is mentioned on line 1135, but not defined == Missing Reference: 'MPLS-COMP' is mentioned on line 1131, but not defined == Unused Reference: 'RFC3477' is defined on line 1113, but no explicit reference was found in the text -- No information found for draft-ietf-ccamp-ospf-gmpls-exten-sions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eiji Oki (NTT) 2 Internet Draft Takashi Kurimoto (NTT) 3 Expiration Date: August 2005 Ichiro Inoue (NTT) 4 Kohei Shiomoto (NTT) 6 February 2005 8 Requirements for Path Computation Element 9 in GMPLS and IP/MPLS Networks 11 draft-oki-pce-gmpls-req-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than a "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). This document is subject 39 to the rights, licenses and restrictions contained in BCP 78, and 40 except as set forth therein, the authors retain all their rights. 42 This document and the information contained herein are provided on an 43 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 44 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 45 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 46 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 47 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 48 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 50 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 52 Abstract 54 Path Computation Element (PCE) provides functions of traffic engineering 55 in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- 56 works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- 57 straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal 58 virtual network topology reconfiguration control, and jugdes on whether 59 a new lower-region LSP should be established when a higher-region LSP is 60 requested. PCE also handles interworking between GMPLS and IP/MPLS net- 61 works, both of which will coexist at some point during the migration 62 process. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119. 70 1. Introduction 72 Path Computation Element (PCE) provides functions of traffic engineering 73 in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- 74 works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- 75 straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal 76 virtual network topology reconfiguration control, and judges on whether 77 a new lower-region LSP should be established when a higher-region LSP is 78 requested. PCE also handles interworking between GMPLS and IP/MPLS net- 79 works, both of which will coexist at some point during the migration 80 process [OKI-INTERWORK]. 82 GMPLS extends MPLS to support various switching technologies [GMPLS- 83 ARC]. GMPLS enables us to control a packet switching network, layer 2 84 switching networks such as asynchronous transfer mode (ATM) and Ether- 85 net, TDM networks such as synchronous digital hierarchy/synchronous 86 optical network (SDH/SONET), lambda and fiber networks all at once. 88 A GMPLS-based multi-region network architecture is addressed in 89 [MRN_REQ][MRN_EXT]. Multi-region traffic engineering in GMPLS networks 90 increase network resource efficiency, because all the network resources 91 are taken into account at the same time. However, in GMPLS multi-region 92 network environments, traffic engineering becomes more complicated, com- 93 pared with that in single-region network environments. 95 Multi-region traffic engineering includes LSPs route calculation, opti- 96 mal virtual network topology calculation, and judgement on whether a new 97 lower-region LSP should be established when a higher-region LSP is 98 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 100 requested. Multi-region traffic engineering also includes control of 101 virtual network topology reconfiguration, which is triggered by traffic 102 demand change, by topology change, and by network failure. Single- 103 region traffic engineering is a subset of multi-region traffic engineer- 104 ing. 106 For example, let us consider hierarchical label switched paths (LSPs) 107 [LSP-HIERARCHY], where a higher-region LSP uses a lower-region LSP as a 108 TE-link. When the higher-region LSP is setup, it is necessary to judge 109 whether new lower-region LSPs should be established for forwarding adja- 110 cency LSPs (FA-LSPs), or existing lower-region LSPs should be used for 111 FA-LSPs. Judgement such as whether new LSPs should be established or 112 existing LSPs should be used depends on the network providers' traffic- 113 engineering policy. 115 This draft describes requirements for Path Computation Element (PCE) in 116 GMPLS and IP/MPLS networks. Section 2 describes an issue on functional, 117 or logical, separation between PCE and GMPLS node. Section 3 presents 118 several traffic engineering scenarios, where PCE is involved. Section 4 119 describes PCE placement scenarios. Section 5 describes PCE functional 120 scenarios. Section 6 describes requirements of PCE. Section 7 describes 121 nodal requirements related to PCE. 123 2. Functional separation between PCE and GMPLS node 125 2.1. GMPLS node 127 A GMPLS node handles GMPLS protocols. When a GMPLS node is a border node 128 between GMPLS and IP/MPLS networks, the GMPLS node handles both GMPLS 129 and IP/MPLS protocols. 131 2.2. Network providers' perspective 133 Traffic-engineering policies are different among network providers. For 134 example, when the higher-region LSP is setup, it is necessary judged 135 whether new lower-region LSPs should be established, or existing lower- 136 region LSPs should be used. The judgement, which is performed by PCE, 137 depends on network providers' policy. PCE performance affects the rev- 138 enue of network providers. Network providers want to have their own PCE, 139 because they want to choose appropriate algorithms, which depend on 140 their policies. 142 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 144 2.3. Venders' perspective 146 It is not desirable to implement PCE that considers all the requirements 147 from network providers. A complicated PCE may also cause the node to 148 degrade its processing capability. 150 2.4. PCE implementation 152 Two approaches for PCE implementation are considered. One is that PCE is 153 implemented as a part of a GMPLS node. PCE is functionally separated 154 from a GMPLS node, from network providers' point of view. The other is 155 that PCE is separately functionally implemented in a GMPLS node. 157 From the above considerations in Sections 2.1 and 2.2, it is desirable 158 to functionally separate PCE from a GMPLS node so that network providers 159 choose their own PCE. 161 3. Traffic engineering scenarios 163 This section describes key topics of traffic engineering in GMPLS and 164 IP/MPLS networks. Multi-region traffic engineering are mainly described. 166 3.1. Virtual network topology optimization 168 Two-region GMPLS networks are considered. Discussion on more than two 169 regions can be easily extended in a similar way. Assume that the higher- 170 region network is an IP-packet region network, while the lower-region is 171 an optical network based on TDM or Lambda switching network. The band- 172 width granularity of the lower region is coarse. For example, the band- 173 width is equal to 2.5Gbit/s or 10Gbit/s. On the other hand, the granu- 174 larity of the higher region is flexible and well engineered. 176 Consider the case in which source and destination IP routers request 177 packet (higher-region) LSPs with specified bandwidths. Higher-region 178 LSPs are routed on the optical network that consists of optical (lower- 179 region) LSPs. When the specified packet LSP bandwidths are much smaller 180 than the lower-region LSP bandwidth, the one-hop lower-region LSP 181 between the source-destination IP routers is not fully utilized. In 182 order to utilize network resources, low-speed higher-region LSPs should 183 be efficiently merged at some transit nodes into high-speed lower-region 184 LSPs. There are two main options for routing a higher-region LSP over 185 the optical network: single hop routes or multiple hop routes. Whether 186 low-speed traffic streams should be groomed or not depends on the net- 187 work resource availability such as the number of available wavelengths 188 and the number of available ports in the packet-switching fabric. 190 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 192 Lower-region LSPs form network topology, which is used for routing of 193 higher-region LSPs. The network topology formed by lower-region LSPs is 194 called a virtual network topology. 196 There are on-line and off-line approaches for configuring virtual net- 197 work topologies. Since it is difficult to predict traffic demands pre- 198 cisely, the on-line approach may be realistic and useful in utilizing 199 the network resources more fully and maximizing the revenue from the 200 given resources. 202 Virtual network topology optimization may be performed in a distributed 203 manner, or in a centralized manner. 205 3.2. Interworking between GMPLS and IP/MPLS networks 207 IP/MPLS and GMPLS networks will coexist at some point in time in the 208 migration process. Such IP/MPLS nodes that do not support GMPLS proto- 209 cols must also operate with GMPLS networks. Migration scenarios from 210 IP/MPLS networks to GMPLS networks that illustrate the issues for rout- 211 ing and signaling are presented in [OKI-INTERWORK]. 213 Consider an MPLS LSP that is established from an MPLS source node to an 214 MPLS destination node via a GMPLS network. The GMPLS network provides a 215 link, which is a GMPLS LSP, for the MPLS LSP. The GMPLS LSP is consid- 216 ered as a lower-region LSP, while the MPLS LSP is considered as a 217 higher-region LSP. In other words, a lower-region LSP is established by 218 GMPLS nodes, while a higher-region LSP is established by MPLS nodes. 220 3.3. Triggered lower-region LSP setup 222 3.3.1. Overview of triggered lower-region LSP setup 224 In the triggered lower-region LSP setup, higher-region traffic increase 225 or a higher-region LSP setup invokes the lower-region LSP setup when the 226 lower-region LSP setup is needed. The triggered lower-region LSP setup 227 are required in the following cases. 229 Case 1: When a higher-region LSP setup is processed, a new lower-region 230 LSP is setup, 231 Case 1-1: because there is no lower-region LSP whose residual bandwidth 232 is larger than the requested higher-region bandwidth, or 233 Case 1-2: because the network provider judges that establishing a new 234 lower-region LSP is more cost effective than using an existing lower- 235 region LSP even it is available. 237 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 239 Case 2: higher-region traffic volume increases, but a lower-region 240 residual LSP bandwidth is not enough to transmit the higher-region traf- 241 fic with a certain quality of service. 243 Note that the higher-region traffic and LSP includes ones in IP/MPLS 244 networks, as is described in Section 3.2. 246 Since the lower-region LSP setup triggered by higher-region traffic 247 increase (case 2) can be classified in a subset of a scenario of the 248 virtual network topology reconfiguration, as described in Section 3.4, 249 only the lower-region LSP setup triggered by the higher-region LSP setup 250 (case 1) is considered in Section 3.3. 252 Figure 1 shows the framework of multi-region routing as an one-line 253 approach. If a new lower-region LSP must be setup to support higher- 254 region LSP routing, a lower-region LSP setup request is invoked and 255 lower-region LSP routing is performed. The lower-region LSP-routing 256 result is returned back to the higher-region LSP routing procedure for 257 confirmation of its acceptability. This process is iterated until the 258 desired result is obtained. If successful, the multi-region routing pro- 259 cedure notifies its acceptance for the higher-region LSP setup request. 261 +-------------------------------+ 262 |Higher-region LSP setup request| 263 +-------------------------------+ 264 | 265 v 266 +-----------------+ +-------------------------------+ 267 | Lower-region |--------->|Higher-region LSP accept/reject| 268 | LSP routing|<---------+-------------------------------+ 269 +-----------------+ ^ 270 | | 271 v | 272 +------------------------------+ | 273 |Lower-region LSP setup request| | 274 +------------------------------+ | 275 | | 276 v | 277 +------------------------+ | 278 |Lower-region LSP routing|---------+ 279 +------------------------+ 280 Figure 1 Framework for multi-region routing. 282 In multi-region routing, there are mainly two possible routing policies. 283 When a new higher-region LSP is requested with specified bandwidth, both 284 policies first try to allocate the new requested higher-region LSP to an 285 existing lower-region LSP that directly connects the source and destina- 286 tion nodes. If such a lower-region LSP (existing) is not available, the 287 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 289 two policies adopt different procedures. Policy 1 tries to find a series 290 of available existing lower-region LSPs with two or more hops that con- 291 nect source and destination nodes. On the other hand, policy 2 tries to 292 setup a new one hop lower-region LSP between source and destination 293 nodes. 295 Which policy should be adopted depends on available network resources 296 such as link and port resources. PCE should judge whether new lower- 297 region LSPs should be established, or existing lower-region LSPs should 298 be used. PCE provides LSP routes for both region LSPs if it is neces- 299 sary. The LSP routes may be specified as a "explicit" or " loose" 300 route. 302 3.3.2. Two approaches for triggered lower-region LSP setup 304 To achieve triggered lower-region LSP setups, there are two possible 305 approaches. 307 The first approach is that PCE participates in both route calculation of 308 both region LSPs and the management of hierarchical signaling including 309 initiating the lower-region LSP setup. The GMPLS node does not have to 310 manage multi-region hierarchical signaling. The GMPLS node can handle 311 two single-region LSP establishments separately. 313 The second approach is that PCE participates only in the route calcula- 314 tion of both region LSPs and does not have to handle the management of 315 hierarchical signaling. The GMPLS node handles multi-region hierarchical 316 signaling. 318 More messages between the GMPLS node and PCE need to be defined in the 319 first approach than the second approach. In the first approach, PCE more 320 involves in multi-region traffic engineering, but the GMPLS node less 321 does. Vice versa in the second approach. 323 A GMPLS node that supports only single-region traffic engineering 324 prefers adopting the first approach to adopting the second approach. 325 This is because a single-region supporting GMPLS node can support multi- 326 region traffic engineering in corporation with PCE as long as PCE inter- 327 faces are implemented. 329 3.4. Virtual network topology reconfiguration 331 A virtual network topology should be optimized, or reconfigured, so that 332 a set of traffic demand is efficiently carried, considering available 333 network resources such as ports and links. 335 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 337 Procedures of a virtual network topology reconfiguration includes lower- 338 region LSP setup, lower-region LSP release, and higher-region LSP 339 rerouting according to the virtual network topology change. 341 A virtual network topology reconfiguration are required in the following 342 cases. 344 Case 1: higher-region traffic volume increases, but a lower-region 345 residual LSP bandwidth is not enough to transmit the higher-region traf- 346 fic with a certain quality of service. 348 Case 2: Since higher-region traffic volumes between source and destina- 349 tion nodes are dramatically fluctuated, a fixed virtual network topology 350 is not able to provide a certain quality of service, or it is no longer 351 an optimal topology. For example, traffic fluctuations may occur due to 352 differences of user traffic patterns between day and night times. It may 353 occur due to appearances of new services or new servers. 355 Case 3: Topology configurations are changed when physical nodes or links 356 are added/deleted, or when nodal configurations are changed. 358 Case 4: Since network failures occur, existing lower-region LSPs are not 359 available. Higher-region traffic transmitted through the fault lower- 360 region LSPs need to be rerouted. If no possible reroute to save the 361 traffic is found on a current virtual network topology, a virtual net- 362 work topology reconfiguration is necessary. 364 Thus, a virtual network topology reconfiguration may be triggered by 365 traffic demand change (cases 1-2), by topology change (case 3), or by 366 network failure (case 4). 368 3.5. Single-region traffic engineering 370 Single-region traffic engineering is a subset of multi-region traffic 371 engineering, as is described in Sections 3.1-3.4. PCE supports to pro- 372 vide an LSP route request in a single-region environment. 374 4. PCE placement scenarios 376 A PCE is placed in a GMPLS network in two possible ways. One way is 377 that each PCE is attached to each GMPLS node, as shown in Figure 2. A 378 PCE behaves as a part of functions in a corresponding GMPLS node. PCE 379 processing load does not dramatically increase as the number of nodes in 380 the networks increases. Traffic engineering is performed in a dis- 381 tributed manner. 383 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 385 Distributed traffic engineering mechanisms, including traffic engineer- 386 ing database (TEDB) synchronization between PCEs, algorithm synchroniza- 387 tion, LSP establishment/release sequence synchronization, etc., are 388 needed. Detail TEDB information is described in Section 5.2 390 +---+ +---+ +---+ 391 |PCE| |PCE| |PCE| 392 +---+ +---+ +---+ 393 | | | 394 +----------+ +----------+ +----------+ 395 |GMPLS node|--|GMPLS node|--|GMPLS node| 396 +----------+ +----------+ +----------+ 397 Figure 2 PCE that communicates with one GMPLS node. 399 The other way is that a PCE communicates with more than one GMPLS node, 400 as shown in Figure 3. PCE processing load may increase as the number of 401 nodes attached to PCE. In an extreme case that there are one PCE in the 402 GMPLS network, traffic engineering may be performed in a centralized 403 manner. 405 +---+ 406 +-----------|PCE|-----------+ 407 | +---+ | 408 | | | 409 +----------+ +----------+ +----------+ 410 |GMPLS node|--|GMPLS node|--|GMPLS node| 411 +----------+ +----------+ +----------+ 412 Figure 3 PCE that communicates with more than one GMPLS node. 414 5. PCE functional scenarios 416 5.1. Overview 418 PCE provides functions of traffic engineering in GMPLS and IP/MPLS net- 419 works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- 420 straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal 421 virtual network topology reconfiguration control, and judges on whether 422 a new lower-region LSP should be established when a higher-region LSP is 423 requested. PCE also handles interworking between GMPLS and IP/MPLS net- 424 works, both of which will coexist at some point during the migration 425 process. 427 A PCE model in terms of inputs to PCE and outputs from PCE are as fol- 428 lows. 430 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 432 +------+ +---+ +-------+ 433 |Inputs|--->|PCE|--->|Outputs| 434 +------+ +---+ +-------+ 435 Figure 4 Inputs and outputs of PCE 437 Inputs to PCE and outputs from PCE for possible scenarios are summarized 438 as follows. 440 Inputs to PCE 441 Updated information of TE links (see Section 5.2) 442 Route request triggered by higher-region LSP setup 443 Route request in single-region TE 444 Lower-region LSP setup response 445 Lower-region LSP release response 446 Higher-region LSP route change response 447 Trigger of traffic demand change 448 Trigger of topology change 449 Trigger of network failure 451 Outputs from PCE: 452 Route response 453 Lower-region LSP setup request 454 Lower-region LSP release request 455 Higher-region LSP route change request 457 Inputs and outputs for each scenarios are described in Sections 5.3-5.5. 459 5.2. Collection of TE-link information 461 PCE collects TE-link information, which is stored in its TEDB. First, 462 TE-link information may be collected by using routing protocols of 463 OSPF/IS-IS [RFC2338][RFC3630][GMPLS-OSPF] if PCE is configured as a 464 OSPF/ISIS peer node. Second, TE-link information may be collected by 465 monitoring link-state advertisement passing through some control-plane 466 links between/among OSPF/ISIF peer nodes. Third, TE-link information may 467 be collected by specific protocols between PCE and a GMPLS node such as 468 SNMP or new ones. In the collection of TE-link information that is not 469 included in link-sate advertisements, the third mechanism should be 470 adopted. Otherwise, routing protocols needs to be extended to advertise 471 TE-link information that is not included in link-sate advertisements. 473 A GMPLS node keeps information of LSPs as TE links. The TE-link informa- 474 tion includes, 475 Interface identifiers 476 Reserved bandwidth 477 GMPLS specific parameters such as switch type, encoding type, and GPID 478 Protection type and link type 479 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 481 SRLG 482 LSP identification (LSP ID, Tunnel ID, SA, DA) 483 Measured traffic volume passing through LSP 484 LSP route, etc. 486 Five items from the top are advertised as TE-link information with 487 Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others 488 are not. 490 PCE calculates a route based on constraints and TE-link information. PCE 491 provides the route with the GMPLS node when it is requested. PCE calcu- 492 lates a virtual network topology to be reconfigured based on TE-link 493 information and controls LSP establishments and releases to reconfigure 494 a virtual network topology. 496 5.3. Triggered lower-region LSP setup 498 As described in Section 2, there are two possible approach in the lower- 499 region LSP setup triggered by higher-region LSP setup. 501 5.3.1. First approach 503 An example of the first approach is in the following [OKI-GTEP]. 505 PCE GMPLS node 506 | | 507 | Route Request | 508 |<----------------------------------------| 509 | | 510 | Lower-region LSP Setup Request* | 511 |---------------------------------------->| 512 | | 513 | Lower-region LSP Setup Response* | 514 |<----------------------------------------| 515 | | 516 | Route Response | 517 |---------------------------------------->| 518 | | 520 *LSP Setup Request/LSP Setup Response appear only when the lower-region 521 LSP needs to be established. 523 Figure 4 Triggered lower-region LSP setup procedure (first approach) 525 Step 1: The GMPLS node is requested to setup a higher-region LSP. The 526 node may be an ingress node, or an transit node from the high-region 527 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 529 LSP's point of view. 531 Step 2: If at least one condition in the following is satisfied, go to 532 Step 3. 1. In the case of an ingress node, Explicit Route is not speci- 533 fied. In the case of a transit node, Explicit Route Object is included 534 in a Path Message. 2. When Explicit Route is specified, the next hop 535 node is specified as Loose. 3. When Explicit Route is specified and the 536 next hop node is specified as "Strict", there is no TE-link that satis- 537 fies constraints such as bandwidth between the node and the next hop 538 node. Otherwise, go to Step 7. 540 Step 3. The GMPLS node requests a route of the higher-region LSP to PCE 542 Step 4. PCE requires PCE to setup a lower-region LSP if it is necessary. 543 Otherwise, go to Step 6. 545 Step 5. The GMPLS node tries to setup the lower-layer LSP and returns 546 the result whether the LSP setup succeeds to PCE. When the LSP setup 547 succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. LSP_TUN- 548 NEL_IF_ID is used to specify Explicit Route Object for the higher-region 549 LSP. 551 Step 6. PCE responds to the GMPLS node by specifying the route of the 552 higher-region LSP. The specified route is formatted as Explicit Route 553 Object that is carried in a Path message. Then, go to Step 7. 555 Step 7. Signaling procedure starts as an ingress node, or continues as 556 an transit node for the higher-region LSP, according to the route speci- 557 fied by PCE. 559 Inputs to PCE and outputs from PCE are as follows. 561 Inputs to PCE: 562 Updated information of TE links (see Section 5.2) 563 Route request triggered by higher-region LSP setup with constraints of 564 LSP to be setup including GMPLS specific parameters 565 Lower-region LSP setup response 567 Outputs from PCE: 568 Route response 569 Lower-region LSP setup request with constraints of LSP to be setup 570 including GMPLS specific parameters 572 5.3.2. Second approach 573 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 575 PCE GMPLS node 576 | | 577 | Route Request | 578 |<----------------------------------------| 579 | | 580 | Route Response | 581 |---------------------------------------->| 582 | | 584 Figure 5 Triggered lower-region LSP setup procedure (Second approach) 586 An example of the second approach is in the following. 588 Step 1: The GMPLS node is requested to setup an higher-region LSP. The 589 node may be an ingress node, or an transit node from the high-region 590 LSP's point of view. 592 Step 2: If at least one condition in the following is satisfied, go to 593 Step 3. 1. In the case of an ingress node, Explicit Route is not speci- 594 fied. In the case of a transit node, Explicit Route Object is included 595 in a Path Message. 2. When Explicit Route is specified, the next hop 596 node is specified as Loose. 3. When Explicit Route is specified and the 597 next hop node is specified as "Strict", there is no TE-link that satis- 598 fies constraints such as bandwidth between the node and the next hop 599 node. Otherwise, go to Step 6. 601 Step 3. The GMPLS node requests a route of the higher-region LSP. to 602 PCE. 604 Step 4. PCE provides the route of the higher-region LSP. If necessary, 605 it also provides the route of a lower-region LSP to be setup. 607 Step 5. In case of the necessary of the lower-region LSP establishment, 608 the GMPLS node tries to setup the lower-region LSP, according the speci- 609 fied route provided by PCE. If signaling procedure of the lower-region 610 LSP setup is completed, go to Step 6. 612 Step 6. Signaling procedure of the higher-region LSP starts as an 613 ingress node, or continues as an transit node for the higher-region LSP, 614 according to the route specified by PCE. 616 Inputs to PCE and outputs from PCE are as follows. 618 Inputs to PCE: 619 Updated information of TE links (see Section 5.2) 620 Route request triggered by higher-region LSP setup with constraints of 621 LSP to be setup including GMPLS specific parameters 622 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 624 Outputs from PCE: 625 Route response 627 5.4. Virtual network topology reconfiguration 629 A virtual network topology reconfiguration may be triggered by traffic 630 demand change, by topology change, or by network failure. In the fol- 631 lowing subsections, each reconfiguration is described. 633 5.4.1. Virtual network topology reconfiguration triggered by traffic 634 demand change 636 To achieve virtual topology reconfiguration triggered by traffic demand 637 change, the following functions of PCE and the GMPLS node are needed. 638 The virtual topology reconfiguration trigger may be issued by a GMPLS 639 node or PCE. 641 PCE collects TE-link information, periodically, when some values are 642 changed, or when some measured values exceed specified thresholds at 643 GMPLS nodes. 645 The calculation of the reconfigured virtual topology may be performed 646 periodically, when some LSP values are changes, or threshold-based. 648 PCE controls virtual network topology reconfiguration according to the 649 calculation results. 651 When a virtual network topology is reconfigured, "make-before-break" 652 procedures for established higher-region LSPs should be adopted so that 653 service disruption can be avoided. 655 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 657 PCE GMPLS node 658 | | 659 | Traffic demand change trigger | 660 |<----------------------------------------| 661 | | 662 | Lower-region LSP setup request* | 663 | Lower-region LSP release request* | 664 | Higher-region LSP route change request* | 665 |---------------------------------------->| 666 | | 667 | Lower-region LSP setup response* | 668 | Lower-region LSP release response* | 669 | Higher-region LSP route change response*| 670 |<----------------------------------------| 671 | | 673 *The order of these requests and responses depends on reconfiguration 674 procedures. 676 Figure 6 Virtual network topology reconfiguration triggered by traffic 677 demand change issued by GMPLS node 679 PCE GMPLS node 680 | | 681 | Traffic demand change trigger | 682 |---------------------------------------->| 683 | | 684 | Lower-region LSP setup request* | 685 | Lower-region LSP release request* | 686 | Higher-region LSP route change request* | 687 |---------------------------------------->| 688 | | 689 | Lower-region LSP setup response* | 690 | Lower-region LSP release response* | 691 | Higher-region LSP route change response*| 692 |<----------------------------------------| 693 | | 695 *The order of these requests and responses depends on reconfiguration 696 procedures. 698 Figure 7 Virtual network topology reconfiguration triggered by traffic 699 demand change issued by PCE 701 Inputs to PCE and outputs from PCE are as follows. 703 Inputs to PCE: 704 Updated information of TE links (see Section 5.2) 705 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 707 Traffic demand change trigger issued by GMPLS node 708 Lower-region LSP setup response 709 Lower-region LSP release response 710 Higher-region LSP route change response 712 Outputs from PCE: 713 Traffic demand change trigger issued by PCE 714 Lower-region LSP setup request 715 Lower-region LSP release request 716 Higher-region LSP route change request 718 5.4.2. Virtual network topology reconfiguration triggered by topology 719 change 721 The calculation of the reconfigured virtual topology is performed when 722 topology is changed. The virtual topology reconfiguration trigger may be 723 issued by a GMPLS node or PCE. 725 PCE controls virtual network topology reconfiguration according to the 726 calculation results. 728 When a virtual network topology is reconfigured, "make-before-break" 729 procedures for established LSPs should be adopted so that service dis- 730 ruption can be avoided. 732 PCE GMPLS node 733 | | 734 | Network topology change trigger | 735 |<----------------------------------------| 736 | | 737 | Lower-region LSP setup request* | 738 | Lower-region LSP release request* | 739 | Higher-region LSP route change request* | 740 |---------------------------------------->| 741 | | 742 | Lower-region LSP setup response* | 743 | Lower-region LSP release response* | 744 | Higher-region LSP route change response*| 745 |<----------------------------------------| 746 | | 748 *The order of these requests and responses depends on reconfiguration 749 procedures. 751 Figure 8 Virtual network topology reconfiguration triggered by traffic 752 demand change issued by GMPLS node 753 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 755 PCE GMPLS node 756 | | 757 | Network topology change trigger | 758 |---------------------------------------->| 759 | | 760 | Lower-region LSP setup request* | 761 | Lower-region LSP release request* | 762 | Higher-region LSP route change request* | 763 |---------------------------------------->| 764 | | 765 | Lower-region LSP setup response* | 766 | Lower-region LSP release response* | 767 | Higher-region LSP route change response*| 768 |<----------------------------------------| 769 | | 771 *The order of these requests and responses depends on reconfiguration 772 procedures. 774 Figure 9 Virtual network topology reconfiguration triggered by traffic 775 demand change issued by PCE 777 Inputs to PCE and outputs from PCE are as follows. 779 Inputs to PCE: 780 Updated information of TE links (see Section 5.2) 781 Topology change trigger issued by GMPLS node 782 Lower-region LSP setup response 783 Lower-region LSP release response 784 Higher-region LSP route change response 786 Outputs from PCE: 787 Topology change trigger issued by PCE 788 Lower-region LSP setup request 789 Lower-region LSP release request 790 Higher-region LSP route change request 792 5.4.3. Virtual network topology reconfiguration triggered by network 793 failure 795 When network failure occurs, virtual topology reconfiguration should be 796 performed as fast as possible so that the degradation of network perfor- 797 mance can be avoided. The virtual topology reconfiguration trigger may 798 be issued by a GMPLS node or PCE. 800 Procedures of the virtual network topology reconfiguration is similar to 801 that triggered by traffic demand change and topology change, but the 802 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 804 network failure triggered operation requires urgent actions as a emer- 805 gent case. 807 PCE GMPLS node 808 | | 809 | Network failure change trigger | 810 |<----------------------------------------| 811 | | 812 | Lower-region LSP setup request* | 813 | Lower-region LSP release request* | 814 | Higher-region LSP route change request* | 815 |---------------------------------------->| 816 | | 817 | Lower-region LSP setup response* | 818 | Lower-region LSP release response* | 819 | Higher-region LSP route change response*| 820 |<----------------------------------------| 821 | | 823 *The order of these requests and responses depends on reconfiguration 824 procedures. 826 Figure 10 Virtual network topology reconfiguration triggered by traffic 827 demand change issued by GMPLS node 829 PCE GMPLS node 830 | | 831 | Network failure change trigger | 832 |---------------------------------------->| 833 | | 834 | Lower-region LSP setup request* | 835 | Lower-region LSP release request* | 836 | Higher-region LSP route change request* | 837 |---------------------------------------->| 838 | | 839 | Lower-region LSP setup response* | 840 | Lower-region LSP release response* | 841 | Higher-region LSP route change response*| 842 |<----------------------------------------| 843 | | 845 *The order of these requests and responses depends on reconfiguration 846 procedures. 848 Figure 11 Virtual network topology reconfiguration triggered by traffic 849 demand change issued by PCE 851 Inputs to PCE and outputs from PCE are as follows. 853 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 855 Inputs to PCE: 856 Updated information of TE links (see Section 5.2) 857 Network failure change trigger issued by GMPLS node 858 Lower-region LSP setup response 859 Lower-region LSP release response 860 Higher-region LSP route change response 862 Outputs from PCE: 863 Lower-region LSP setup request 864 Lower-region LSP release request 865 Higher-region LSP route change request 867 5.5. Single-region traffic engineering 869 PCE GMPLS node 870 | | 871 | Route Request | 872 |<---------------------------| 873 | | 874 | Route Response | 875 |--------------------------->| 876 | | 878 Figure 12 Single-region traffic engineering 880 An example of the single-layer LSP route request procedure is in the 881 following. 883 Step 1. The GMPLS node is requested to setup an LSP. 885 Step 2. The GMPLS node requests a route of the LSP to PCE. 887 Step 3. PCE sends the GMPLS node the LSP route. 889 Inputs to PCE and outputs from PCE are as follows. 891 Inputs to PCE: 892 Updated information of TE links (see Section 5.2) 893 Route request in single-region TE 895 Outputs from PCE: 896 Route response 897 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 899 6. PCE Requirements 901 6.1. Triggered lower-region LSP setup 903 Lower-region LSP setup triggered by the high-layer LSP setup should be 904 supported. When the higher-layer LSP is setup, PCE should judge whether 905 new lower-layer LSPs should be established as forwarding adjacency LSPs 906 (FA-LSPs), or existing lower-layer LSPs should be used as FA-LSPs. PCE 907 provides LSP routes for both layer LSPs if it is necessary. The LSP 908 routes may be specified as a "explicit" or " loose" route. 910 To achieve triggered lower-region LSP setups, there are two possible 911 approaches. 913 The first approach is that PCE participates in both route calculation of 914 both region LSPs and the management of hierarchical signaling including 915 initiating the lower-region LSP setup. The GMPLS node does not have to 916 manage multi-region hierarchical signaling. The GMPLS node can handle 917 two single-region LSP establishments separately. 919 The second approach is that PCE participates only in the route calcula- 920 tion of both region LSPs and does not have to handle the management of 921 hierarchical signaling. The GMPLS node handles multi-region hierarchical 922 signaling. 924 More messages between the GMPLS node and PCE need to be defined in the 925 first approach than the second approach. In the first approach, PCE more 926 involves in multi-region traffic engineering, but the GMPLS node less 927 does. Vice versa in the second approach. 929 A GMPLS node that supports only single-region traffic engineering 930 prefers adopting the first approach to adopting the second approach. 931 This is because a single-region supporting GMPLS node can support multi- 932 region traffic engineering in corporation with PCE as long as PCE inter- 933 faces are implemented. 935 6.2. Virtual network topology reconfiguration 937 Virtual network topology reconfigurations triggered by traffic demand 938 change, by topology change, and by network failure should be supported. 940 When a virtual network topology is reconfigured triggered by traffic 941 demand change and by topology change, "make-before-break" procedures for 942 established LSPs should be adopted so that service disruption can be 943 avoided. 945 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 947 When network failure occurs, virtual topology reconfiguration should be 948 performed as fast as possible so that the degradation of network perfor- 949 mance can be avoided. 951 6.3. Single-region traffic engineering 953 Single-region traffic engineering is a subset of multi-region traffic 954 engineering. PCE should support to provide an LSP route request in a 955 single-region environment. 957 6.4. Constraints of the route calculation to PCE 959 A GMPLS node should provide constraints for LSP setups for PCE, when the 960 GMPLS node requests a route of the LSP to PCE. 962 Constraints for LSP setups should include GMPLS specific parameters. 963 Example of the GMPLS specific parameters are a switch type, encoding 964 type, GPID, bandwidth, protection type, and link type, which are 965 included in a generalized label request object [RFC3471][RFC3473]. 967 When PCE fails to provide an route that doest not satisfy the con- 968 straints, PCE should optionally includes suggested routes but does not 969 completely satisfy the constraints that enable to find a route. In MPLS 970 networks, [MPLS-COMP] describes examples of relaxation of alternative 971 constraints such as bandwidth and protection type. In GMPLS networks, 972 relaxation of alternative constraints such as switching type, encoding 973 type, GPID, and SRLG should be extended. 975 6.5. Collection of TE-link information 977 PCE should collect TE-link information. A part of TE-link information is 978 able to be obtained by using routing protocols of OSPF/IS-IS. However, A 979 part of TE-link information that is not included in link-sate advertise- 980 ments is not able to be collected with the routing protocols. Such TE- 981 link information should be collected by specific protocols between PCE 982 and a GMPLS node. 984 A GMPLS node should keep information of LSPs as TE links. The TE-link 985 information includes, 986 Reserved LSP bandwidth 987 GMPLS specific parameters such as switch type, encoding type, GPID, 988 Protection type and link type 989 Measured traffic volume passing through LSP 990 LSP route, etc. 992 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 994 The first and second items are advertised as TE-link information with 995 Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others 996 are not. 998 PCE should collect all TE-link information in the manageable network 999 domain. The LSP information that is stored in LSP database of each GMPLS 1000 node should be reported to PCE in a timely manner. LSP database should 1001 be updated after LSP establishment/release. A large volume of TE-link 1002 information data should be transferred with reliability. 1004 6.6. PCE scalability 1006 In GMPLS multi-region network environments, traffic engineering becomes 1007 more complicated, compared with that in single-region network environ- 1008 ments. Complicated TE algorithms should not degrade PCE scalability in 1009 terms of processing capability. 1011 6.7. Interworking GMPLS and IP/MPLS networks 1013 PCE should support interworking GMPLS and IP/MPLS networks, both of 1014 which will coexist at some point during the migration process [OKI- 1015 INTERWORK]. 1017 6.8. Synchronization of TEDBs in PCE and in GMPLS node 1019 TEDB in PCEs and GMPLS nodes should be synchronized consistently and 1020 quickly. 1022 6.9. Fault-tolerant PCEs 1024 PCE should be fault tolerant. 1026 7. Nodal requirements related to PCE 1028 7.1. PCE request mode 1030 7.1.1. PCE mandatory request mode 1032 A GMPLS node should have a mandatory request mode where it must request 1033 PCE to calculate a route to the destination node whenever the route 1034 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 1036 needs to be obtained. In this mode, the GMPLS node should not calculate 1037 the route with its own CSPF engine. 1039 7.1.2. PCE normal request mode 1041 A GMPLS node should have a normal request mode. Consider that a GMPLS 1042 node receives a Path message including Explicit Route Object. The next 1043 hop node is specified as "Strict", but there is no TE link that satis- 1044 fies constraints. The GMPLS node should not issue a Path Error Massage 1045 to the upstream node without inquiring the possibility of a lower-region 1046 LSP establishment with PCE. 1048 The GMPLS node should request the possibility of a lower-region LSP 1049 establishment with PCE. The lower-region LSP establishment suggested by 1050 PCE should be consistent with the explicit route of the higher-region 1051 LSP. 1053 7.2. Network stability in terms of PCE 1055 When a GMPLS node is not able to find any available PCE in a managed 1056 network domain, a GMPLS node should act as a non-PCE mode. 1058 Any PCE failure should not affect data-plane transmission that is 1059 already serviced. 1061 8. Intellectual Property Considerations 1063 The IETF takes no position regarding the validity or scope of any Intel- 1064 lectual Property Rights or other rights that might be claimed to pertain 1065 to the implementation or use of the technology described in this docu- 1066 ment or the extent to which any license under such rights might or might 1067 not be available; nor does it represent that it has made any independent 1068 effort to identify any such rights. Information on the procedures with 1069 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 1071 Copies of IPR disclosures made to the IETF Secretariat and any assur- 1072 ances of licenses to be made available, or the result of an attempt made 1073 to obtain a general license or permission for the use of such propri- 1074 etary rights by implementers or users of this specification can be 1075 obtained from the IETF on-line IPR repository at 1076 http://www.ietf.org/ipr. 1078 The IETF invites any interested party to bring to its attention any 1079 copyrights, patents or patent applications, or other proprietary rights 1080 that may cover technology that may be required to implement this 1081 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 1083 standard. Please address the information to the IETF at ietf- 1084 ipr@ietf.org. 1086 9. IPR Disclosure Acknowledgement 1088 By submitting this Internet-Draft, I certify that any applicable patent 1089 or other IPR claims of which I am aware have been disclosed, and any of 1090 which I become aware will be disclosed, in accordance with RFC 3668. 1092 10. References 1094 [GMPLS-ARC] E. Mannie, "Generalized Multi-Protocol Label Switching 1095 Architecture," IETF draft, draft-ietf-ccamp-gmpls-architecture-07.txt, 1096 May 2003. 1098 [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional 1099 Description," RFC 3471 , Jan. 2003. 1101 [RFC3473] P. Ashwood-Smith et al, "Generalized MPLS Signaling - RSVP-TE 1102 Extensions," RFC 3473, Jan. 2003. 1104 [RFC2338] J. Moy, "OSPF Version 2," RFC 2328. 1106 [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF 1107 Version 2," RFC 3630. 1109 [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of 1110 Generalized MPLS," IETF draft, draft-ietf-ccamp-ospf-gmpls-exten- 1111 sions-12.txt, Oct. 2003. (working in progress) 1113 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in 1114 Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC 3477. 1115 (working in progress) 1117 [MRN_REQ] K. Shiomoto et al, "Requirements for GMPLS-based multi-region 1118 and multi-layer networks," IETF draft, draft-shiomoto-ccamp-gmpls-mrn- 1119 reqs-00.txt, Oct. 2004. (work in progress) 1121 [MRN_EXT] D. Papadimitriou et al., "Generalized Multi-Protocol Label 1122 Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)," 1123 IETF draft, draft-papadimitriou-ccamp-gmpls-mrn-extensions-00.txt, Oct. 1124 2004. (work in progress) 1126 [LSP-HIERARCHY] K. Kompella and Y. Rekhter, "LSP Hierarchy with General- 1127 ized MPLS TE," draft-ietf-mpls-lsp-hierarchy-08.txt, Sep. 2002. (working 1128 in progress) 1129 Oki et al. draft-oki-pce-gmpls-req-02.txt February 2005 1131 [MPLS-COMP] JP Vasseur et al., "RSVP Path computation request and reply 1132 messages," IETF draft, draft-vasseur-mpls-computation-rsvp-03, June 1133 2002. 1135 [OKI-GTEP] E. Oki et al., "Generalized Traffic Engineering Protocol", 1136 IETF draft, draft-oki-ccamp-gtep-01.txt, October 2004. 1138 [OKI-INTERWORK] E. Oki et al, "Migrating from IP/MPLS to GMPLS net- 1139 works," IETF draft, draft-oki-ccamp-gmpls-ip-interworking-04.txt, Octo- 1140 ber 2004. 1142 11. Authors' Address 1144 Eiji Oki 1145 NTT Corporation 1146 3-9-11 Midori-cho, 1147 Musashino-shi, Tokyo 180-8585, Japan 1148 Email: oki.eiji@lab.ntt.co.jp 1150 Takashi Kurimoto 1151 NTT Corporation 1152 3-9-11 Midori-cho, 1153 Musashino-shi, Tokyo 180-8585, Japan 1154 Email: kurimoto.takashi@lab.ntt.co.jp 1156 Ichiro Inoue 1157 NTT Corporation 1158 3-9-11 Midori-cho, 1159 Musashino-shi, Tokyo 180-8585, Japan 1160 Email: inoue.ichiro@lab.ntt.co.jp 1162 Kohei Shiomoto 1163 NTT Corporation 1164 3-9-11 Midori-cho, 1165 Musashino-shi, Tokyo 180-8585, Japan 1166 Email: shiomoto.kohei@lab.ntt.co.jp