idnits 2.17.1 draft-li-spring-segment-path-programming-00.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 8 instances of too long lines in the document, the longest one being 12 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 (October 17, 2015) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-pce-pce-initiated-lsp' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 == Outdated reference: A later version (-04) exists of draft-li-idr-mpls-path-programming-01 == Outdated reference: A later version (-02) exists of draft-li-spring-tunnel-segment-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft I. Milojevic 4 Intended status: Informational Z. Zhuang 5 Expires: April 19, 2016 Huawei Technologies 6 October 17, 2015 8 Segment Path Programming (SPP) 9 draft-li-spring-segment-path-programming-00 11 Abstract 13 Segment Routing for unicast traffic has been proposed to cope with 14 the usecases in traffic engineering, fast re-reroute, service chain, 15 etc. The document generalizes more use cases based on segment and 16 proposes the concept of Segment Path Programming. In the field of 17 Segment Path Programming: 1. The Segment used in the programmed 18 segment path is not only used in the forwarding plane, but also used 19 in the control plane. 2. The programmed segment path is not only 20 used in the transport layer, but also used in the service layer. 21 Accordingly this document proposes use cases, architecture and 22 protocol extension requirements for the Segment Path Programming 23 (SPP). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 19, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Redefinition of Segment . . . . . . . . . . . . . . . . . . . 3 68 3.1. Application of Segment in Control Plane and Forwarding 69 Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.2. Application of Segment in Reachability and Service 71 Process . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Definition of Segment Path Programming Path . . . . . . . . . 6 73 5. Usecases of Segment Path Programming . . . . . . . . . . . . 7 74 5.1. Flexible Service Process Combination . . . . . . . . . . 7 75 5.2. Node Segment for Synonymous Flow Label . . . . . . . . . 8 76 5.3. Steering Traffic without Mapping Segment to Label . . . . 8 77 5.4. Centralized Mapping Service to Tunnels . . . . . . . . . 9 78 6. Framework of Service-Oriented MPLS Path Programming . . . . . 11 79 6.1. Central Control for MPLS Path Programming . . . . . . . . 11 80 6.2. Protocol Extensions Requirements . . . . . . . . . . . . 12 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 9.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 Segment Routing [I-D.ietf-spring-segment-routing] for unicast traffic 91 has been proposed to cope with the usecases in traffic engineering, 92 fast re-reroute, service chain, etc. The document generalizes more 93 use cases based on segment and proposes the concept of Segment Path 94 Programming. In the field of Segment Path Programming: 1. The 95 Segment used in the programmed segment path is not only used in the 96 forwarding plane, but also used in the control plane. 2. The 97 programmed segment path is not only used in the transport layer, but 98 also used in the service layer. Accordingly this document proposes 99 use cases, architecture and protocol extension requirements for the 100 Segment Path Programming (SPP). 102 2. Terminology 104 BGP: Border Gateway Protocol 106 L2VPN: Layer 2 VPN 108 L3VPN: Layer 3 VPN 110 SPP: Segment Path Programming 112 SR-path: Segment Routing Path 114 SRGB: SR Global Block 116 3. Redefinition of Segment 118 3.1. Application of Segment in Control Plane and Forwarding Plane 120 In the existing segment routing, the segment will be applied to the 121 MPLS forwarding plane directly. In the MPLS architecture, the global 122 segment such as node segment will be mapped to MPLS label since SRGB 123 will be defined as the set of local labels reserved for global 124 segments and the local segment will be a local label outside the 125 SRGB. 127 In fact, the segment can be only used in the control plane instead of 128 mapping to the forwarding plane. In the usecase, the segment is just 129 an indicator for specific process which can be used for the 130 application of Segment Path Programming. 132 For example, node segment in the Segment Routing mapped in the 133 control plane and forwarding plane in the MPLS architecture is shown 134 in the following figure. 136 Control Plane: 137 +---------+ +------------+ 138 | Segment | | | 139 | | = | Label | 140 | ID | | | 141 +---------+ +------------+ 143 Forwarding Plane: 144 +--------+------------+ +------------+-------------------------+ 145 | | Forwarding | | Forwarding | Forwarding Information | 146 | Label | | --> | | to | 147 | | Index | | Index | Specified Node | 148 +--------+------------+ +------------+-------------------------+ 150 Figure 1: Node Segment in Segment Routing 152 In the Segment Path Programming, the node segment can be enhanced to 153 support following mapping in the control plane and forwarding plane 154 even in the MPLS architecture. 156 Control Plane: 157 +---------+ +------------+ 158 | Segment | | Forwarding | 159 | | --> | | 160 | ID | | Index | 161 +---------+ +------------+ 163 Forwarding Plane: 164 +------------+-------------------------+ 165 | Forwarding | Forwarding Information | 166 | | to | 167 | Index | Specified Node | 168 +------------+-------------------------+ 170 Figure 2: Enhanced Node Segment in Segment Path Programming 172 In this mapping, the Segment ID can map to the forwarding entry to 173 specific node. But it is only an indicator in the control plane 174 which can be used for possible applications. When receive the 175 mapping information between the application and the Segment ID, the 176 network node will install additional forwarding entry as follows 177 which map the application information to the forwarding information 178 specified by the segment ID. 180 Control Plane: 182 Mapping Information 183 +--------+------------+ 184 | App | Segment | 185 | | | 186 | Info | ID | 187 +--------+------------+ 189 Forwarding Plane: 190 +----------+------------+ +------------+-------------------------+ 191 | | Forwarding | | Forwarding | Forwarding Information | 192 | App Info | | --> | | to | 193 | | Index | | Index | Specified Node | 194 +----------+------------+ +------------+-------------------------+ 195 Figure 3: Mapping App to Segment in Segment Path Programming 197 The application information in the forwarding entry should be derived 198 from the packet received by the network nodes such as the destination 199 IP/MAC address, the source IP/MAC address, the port number, the 200 protocol number, etc. It can also be the MPLS label. 202 In order to support the enhanced segment in the Segment Programming 203 Path, whether to map the Segment to MPLS label can be determined by 204 the local policy of the network node. Protocol extensions can also 205 be introduced to specify if the Segment maps to the MPLS label when 206 advertised the information of SRGBs or all kinds of Segments. 208 3.2. Application of Segment in Reachability and Service Process 210 In the existing Segment Routing, in the MPLS architecture the segment 211 will be mapped to the label which is always the indicator of 212 reachability to the specific node, the specific agency, etc. More 213 types of Segments which indicates the reachability can be introduced 214 according to existing MPLS forwarding plane. Since these segments 215 represent reachability in the network, they can be used for traffic 216 steering. These segments includes: 218 -- Node Segment 220 -- Agency Segment 222 -- AS (Autonomous System) Segment 224 -- Anycast Segment 226 -- Multicast Segment 227 -- Tunnel Segment 229 -- VPN Segment 231 -- etc. 233 As the development of Segment Routing, the service segment is 234 introduced to represent the specific service process. It can be used 235 for some new application scenarios such qw the Service Function Chain 236 (SFC). For the service process in the traditional IP/MPLS fowarding 237 plane, it can also be indicated by different types of segments. This 238 provides the possibility to flexibly combine these segment to set up 239 a Segment Path to represent a series of service process in the 240 network on the specific flow instead of only steering traffic. These 241 Segments can represent different service process in the forwarding 242 plane as follows: 244 -- OAM Segment 246 -- ECMP (Equal Cost Multi-Path) Segment 248 -- QoS Segment 250 -- Bandwidth-Guarantee Segment 252 -- Security Segment 254 -- Multi-Topology Segment 256 -- etc. 258 4. Definition of Segment Path Programming Path 260 Owing to more types of segments and flexible application of segment 261 in the control plane and the forwarding plane, there will be powerful 262 capability to combine these segments which can be used to steering 263 traffic or provide flexible service process to satisfy different 264 service requirement for specific flows in the network. We call such 265 combination of segments as Segment Path and the flexible combining of 266 segments as Segment Path Programming. 268 Segment Routing ([I-D.ietf-spring-segment-routing]) is a typical 269 example of Segment Path Programming. There can be multiple layers 270 for Segment Path Programming which are shown in the following figure: 272 +---+ +---+ 273 +--+ | | +---+ +---+ +---+ | | +--+ 274 |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| 275 +--+ | | +---+ +---+ +---+ | | +--+ 276 +---+ +---+ 278 Service-oriented Segment Path Programming 279 (SoSPP) 280 o--------o--------- Service Layer------------o--------o 282 o--------- Network Layer -----------o 284 Transport-oriented Segment Path Programming 285 (Segment Routing) 286 o-------o--------o---------o-------o Transport Layer 288 o-----o o-----o o-----o o-----o o-----o o-----o Link Layer 290 Figure 4: Multiple Layers of Segment Path Programming 292 Now the segment routing is to provide the source packet routing in 293 the transport layer or the link layer for traffic steering . We can 294 call such type of source packet routing as Transport-Oriented Segment 295 Path Programming. There can be more application scenarios which need 296 the segment path to respresent the service processes in the service 297 layer or network layer. We call these types of source packet routing 298 as Service-Oriented Segment Path Programming. 300 5. Usecases of Segment Path Programming 302 5.1. Flexible Service Process Combination 304 The following figure shows the usecase of Segment Path Programming to 305 combine service segments according to the service requirements on the 306 traffic which can be specified by the traditional BGP VPN prefix. 307 The combination of these service segments represent the required 308 ECMP, QoS and OAM process. 310 Traditional Label Binding for VPN Prefix: 311 +----------+----------+ 312 | VPN |VPN Prefix| 313 | Prefix | Label | 314 +----------+----------+ 316 Additional Segment Path Information: 317 +----------+----------+----------+ 318 | ECMP | QoS | OAM | 319 | Segment | Segment | Segment | 320 +----------+----------+----------+ 322 If the network node maps the corresponding segment to MPLS label, the 323 forwarding entry can be as follows: 325 +----------+ +----------+----------+----------+----------+ 326 |VPN Prefix| | Entropy | QoS | OAM |VPN Prefix| Transport Tunnel 327 | | --> | Label | Label | Label | Label | ---> determined by 328 +----------+ +----------+----------+----------+----------+ BGP Nexthop 330 5.2. Node Segment for Synonymous Flow Label 332 Synonymous flow label has been proposed by 333 [I-D.bryant-mpls-synonymous-flow-labels] to solve the issue of the 334 measurement of packet loss for multipoint-to-point LSP. Node segment 335 advertised in the Segment Routing can be used as the flow label. In 336 the scenario of performance measurement the flow label can only be 337 interpreted by network node to identify the source of the flow other 338 than set up the MPLS forwarding entry for the node segment in the 339 scenario of segment routing. So when advertise the node segment 340 information on the usage of the node segment can also be carried or 341 the local policy can be introduced to determine the application of 342 the node segment. Then the segment path can be set up based on such 343 node segment for the purpose of performance measurement. 345 5.3. Steering Traffic without Mapping Segment to Label 347 The following figure shows the usecase of Segment Path Programming to 348 steer traffic which can be specified by the traditional BGP prefix. 350 Traditional BGP Prefix: 351 +----------+ 352 | BGP | 353 | Prefix | 354 +----------+ 356 Additional Segment Path Information: 357 +----------+----------+ 358 | Agency | Node | 359 | Segment | Segment | 360 +----------+----------+ 362 If these segments are not applied in the MPLS forwarding plane, the 363 Segment Path will be explained as steering traffic specified by the 364 BGP prefix to reach specific node (determined by the Node Segment) 365 through specific local link (determined by the Agency Segment). The 366 corresponding fowarding entry will be as follows: 368 +----------+------------+ +------------+---------------+--------------------+ 369 | BGP | Forwarding | | Forwarding | Next Hop | Outgoing Interface | 370 | | | --> | | determined by | determine by | 371 | Prefix | Index | | Index | Node Segment | Link Segment | 372 +----------+------------+ +------------+---------------+--------------------+ 374 5.4. Centralized Mapping Service to Tunnels 376 In the transport layers, there can be multiple tunnels with different 377 constraints to one specific destination. In the traditional way, the 378 tunnel is set up by the distributed forwarding nodes. As the PCE- 379 initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp]is introduced, 380 the tunnel setup can be triggered by the central controlled way. In 381 order to satisfy the different service requirements, it is necessary 382 to provide the capability to flexibly map the service to different 383 tunnels. Since the central control point has enough information 384 based on the whole network view, it can be an effective way to map 385 the service to the tunnel by the central point and advertise the 386 mapping information to the end-points of the service to guide the 387 mapping in the forwarding node. 389 The method to implement mapping service to tunnels can directly 390 introduce the tunnel attribute to specify the tunnel proposed by 391 [I-D.li-idr-mpls-path-programming]. [I-D.li-spring-tunnel-segment] 392 proposes one new type of segment, Tunnel Segment, which can provide 393 an alternative way to implement mapping service to tunnels. In the 394 following figure, the central controller can trigger to set up the 395 MPLS TE tunnels through PCE-initiated LSP and allocate Segment ID for 396 the tunnel in the Node-1. 398 +------------+ 399 | Central | 400 | Controller | 401 +------------+ 402 ^ Tunnel Binding 403 | SID (Z) 404 | .-----. 405 | ( ) 406 V .--( )--. 407 +-------+ ( ) +-------+ 408 | |_( IP/MPLS Network )_| | 409 |Node-1 | ( ================> ) |Node-2 | 410 +-------+ (MPLS TE/IP Tunnel) +-------+ 411 '--( )--' 412 ( ) 413 '-----' 415 Figure 5: Using Tunnel Segment for Mapping Service to Tunnel 417 Without applying the segment to MPLS label the Node-1 can set up the 418 following mapping for the tunnel segment: 420 Control Plane: 421 +---------+ +------------+ 422 | Segment | | Forwarding | 423 | | --> | | 424 | ID | | Index | 425 +---------+ +------------+ 427 Forwarding Plane: 428 +------------+-----------------------+ 429 | Forwarding | Tunnel Forwarding | 430 | | | 431 | Index | Information | 432 +------------+-----------------------+ 434 Figure 6: Enhanced Node Segment in Segment Path Programming 436 Then the central controller can advertise following Segment Path 437 information for the flow which can be specified by the traditional 438 BGP prefix. 440 Traditional BGP Prefix: 441 +----------+ 442 | BGP | 443 | Prefix | 444 +----------+ 446 Additional Segment Path Information: 447 +----------+ 448 | Tunnel | 449 | Segment | 450 +----------+ 452 Then the following forwarding entry can be set up for the specified 453 BGP prefix to steer traffic to specific tunnel in the Noed-1. 455 +----------+------------+ +------------+----------------------+ 456 | BGP | Forwarding | | Forwarding | Tunnel Forwarding | 457 | | | --> | | | 458 | Prefix | Index | | Index | Information | 459 +----------+------------+ +------------+----------------------+ 461 6. Framework of Service-Oriented MPLS Path Programming 463 6.1. Central Control for MPLS Path Programming 465 Central control plays an important role in Segment Path Programming 466 shown in the figure 7. There are two important functionalities for 467 the central controller: 469 1. Central controlled Segment allocation/collection: Segment can be 470 allocated centrally for specific usage. Or central controller can 471 collect the segment binding information from the network nodes. 472 BGP/PCEP/IGP extensions can be introduced to distribute or collect 473 the segment binding information. 475 2. Central controlled Segment Path Programming: Central controller 476 can calculate path in a global network view and implement the Segment 477 Path Programming based on the collected information of segments to 478 satisfy different requirements of service flows. BGP/PCEP extensions 479 can be introduced to download the Segment Path for the Service/ 480 Network layer or Transport/Link layer. 482 +-------------------+ 483 | Central | 484 | Controller | 485 |----------|(Path Calculation |--------| 486 | | /Path Programming)| | 487 | +-------------------+ | 488 | / | \ | 489 Segment Path / Segment \ Segment Path 490 | / | \ | 491 | Segment | Segment | 492 | / | \ | 493 | / | \ | 494 | / | \ | 495 +--------+ +--------+ +--------+ 496 | CLIENT | | CLIENT | | CLIENT | 497 | | ...... | | ...... | | 498 | (PE) | | (P) | | (PE) | 499 | | | | | | 500 +--------+ +--------+ +--------+ 502 Figure 7: Central Control for Segment Path Programming 504 6.2. Protocol Extensions Requirements 506 REQ 01: BGP/PCEP/IGP extensions should be introduced to distribute 507 Segment binding for specific usage from the central controller to 508 other client nodes. 510 REQ 02: BGP/PCEP/IGP extensions should be introduced to collect 511 Segment binding for specific usage from the client nodes to the 512 central controller. 514 REQ 03: BGP extensions should be introduced to download Segment 515 (stack) for Segment Path of the service/network layer. 517 REQ 04: PCE extensions should be introduced to download Segment 518 (stack) for Segment Path of the transport layer. 520 REQ 05: Protocol extensions should be introduced to specify the 521 application of SRGB or Segment which means if the segment is applied 522 to MPLS forwarding plane. 524 7. IANA Considerations 526 This document makes no request of IANA. 528 8. Security Considerations 530 TBD. 532 9. References 534 9.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 9.2. Informative References 543 [I-D.bryant-mpls-synonymous-flow-labels] 544 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 545 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 546 bryant-mpls-synonymous-flow-labels-01 (work in progress), 547 July 2015. 549 [I-D.ietf-pce-pce-initiated-lsp] 550 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 551 Extensions for PCE-initiated LSP Setup in a Stateful PCE 552 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 553 progress), April 2015. 555 [I-D.ietf-spring-segment-routing] 556 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 557 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 558 ietf-spring-segment-routing-06 (work in progress), October 559 2015. 561 [I-D.li-idr-mpls-path-programming] 562 Li, Z., "BGP Extensions for Service-Oriented MPLS Path 563 Programming (MPP)", draft-li-idr-mpls-path-programming-01 564 (work in progress), March 2015. 566 [I-D.li-spring-tunnel-segment] 567 Li, Z. and N. Wu, "Tunnel Segment in Segment Routing", 568 draft-li-spring-tunnel-segment-00 (work in progress), 569 September 2015. 571 Authors' Addresses 572 Zhenbin Li 573 Huawei Technologies 574 Huawei Bld., No.156 Beiqing Rd. 575 Beijing 100095 576 China 578 Email: lizhenbin@huawei.com 580 Igor Milojevic 581 Huawei Technologies 582 Poland-Warsaw-TULIPAN HOUSE, UL. DOMANI EWSKA 50, 02-672 583 Warsaw 584 Poland 586 Email: Igor.Milojevic@huawei.com 588 Shunwan Zhuang 589 Huawei Technologies 590 Huawei Bld., No.156 Beiqing Rd. 591 Beijing 100095 592 China 594 Email: zhuangshunwan@huawei.com