idnits 2.17.1 draft-cheng-spring-mpls-path-segment-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2368 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) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cheng 3 Internet-Draft L. Wang 4 Intended status: Standards Track H. Li 5 Expires: May 3, 2018 China Mobile 6 M. Chen 7 Huawei 8 R. Zigler 9 Broadcom 10 S. Zhan 11 ZTE 12 October 30, 2017 14 Path Segment in MPLS Based Sement Routing Network 15 draft-cheng-spring-mpls-path-segment-00 17 Abstract 19 An SR path is identified by an SR segment list, one or partial 20 segments of the list cannot uniquely identify the SR path. 22 This document introduces the concept of Path Segment that is used to 23 identify an SR path. When used, it is inserted at the ingress node 24 of the SR path and immediately follows the last segment of the SR 25 path. The Path Segment will not be popped off until it reaches the 26 egress of the SR path, it can be used by the egress node to implement 27 end-2-end SR path protection or performance measurement (PM) of an SR 28 path. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 3, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. One Label Solution . . . . . . . . . . . . . . . . . . . 3 73 2.1.1. Path Segment Assignment . . . . . . . . . . . . . . . 4 74 2.2. Two Labels Solution . . . . . . . . . . . . . . . . . . . 5 75 3. Path Segment Application . . . . . . . . . . . . . . . . . . 7 76 3.1. Performance Measurement . . . . . . . . . . . . . . . . . 7 77 3.2. End-2-end Path Protection . . . . . . . . . . . . . . . . 7 78 3.3. Bi-directional SR Tunnel . . . . . . . . . . . . . . . . 8 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 8.2. Informative References . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 Segment Routing (SR) [I-D.ietf-spring-segment-routing] is a source 91 routed forwarding method that allows to directly encode forwarding 92 instructions (called segments) in each packet, hence it enables to 93 steer traffic through a network without the per-flow states 94 maintained in the transit nodes. Segment Routing can be instantiated 95 on MPLS data plane or IPv6 data plane. The former is called SR-MPLS 97 [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6 98 [I-D.ietf-6man-segment-routing-header]. SR-MPLS leverages the MPLS 99 label stack to construct SR path, and SRv6 uses the Segment Routing 100 Header to construct SR path. 102 In an SR-MPLS network, when a packet is transmitted along an SR path, 103 the labels in the MPLS label stack will be swapped or popped. So 104 that no label or only the last label may be left in the MPLS label 105 stack when the packet reaches the egress node. Thus, the egress node 106 cannot determine from which ingress node or SR path the packet comes. 108 However, to support use cases like end-2-end 1+1 path protection, 109 bidirectional path correlation or performance measurement(PM), the 110 ability to implement path identification is the pre-condition. 112 Therefore, this document introduces a new segment that is referred to 113 as Path Segment. A Path Segment is defined to unique identify an SR 114 path in a specific context. (e.g., in the context of the egress node 115 or ingress node of an SR path, or within an SR domain). It is 116 normally used by egress nodes for path identification or correlation. 117 Path Segment can only apply to SR-MPLS. 119 2. Path Segment 121 This document introduces two options for SR path identification: one 122 label solution and two labels solution. 124 [Editor notes: it is supposed that the WG will discuss and decide 125 which one is the better solution.] 127 2.1. One Label Solution 129 The Path Segment is a single label that is assigned from the Segment 130 Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of 131 the egress node of an SR path. It means that the Path Segment is 132 unique in the context of the egress node of SR paths. When Path 133 Segment is used, a Path label MUST be inserted at the ingress node 134 and MUST immediately follow the last label of the SR path. 136 If the Path label is the bottom label, the S bit MUST be set. The 137 value of the TC field MUST be set to the same value as the last 138 segment label of the SR path. The value of the TTL field MUST be set 139 to the same value of the last segment label of the SR path. 141 Normally, the intermediates node will not see the Path Segment label 142 and do not know how to process it even if they see it. A Path 143 Segment label presenting to an intermediate node is error situation. 145 The egress node MUST pop the Path label and deliver it to relevant 146 components for further processing. 148 The label stack with Path Segment is as below (Figure1): 150 +--------------------+ 151 | ... | 152 +--------------------+ 153 | Label 1 | 154 +--------------------+ 155 | Label 2 | 156 +--------------------+ 157 | ... | 158 +--------------------+ 159 | Label n | 160 +--------------------+ 161 | Path Label | 162 +--------------------+ 163 | ... | 164 +--------------------+ 166 Figure 1: Label Stack with Path Segment 168 Where: 170 o The Label 1-n are the segment labels that are used to direct how 171 to steer the packets along the SR path. 173 o The Path Label identifies the SR path in the context of the egress 174 node of the SR path. 176 2.1.1. Path Segment Assignment 178 Several ways can be used to assign the Path Segment. One way is that 179 the Path Segment label is directly assigned by the egress node of an 180 SR path. Where the ingress node of the SR path can directly send a 181 request to the egress node to ask for a Path label. With this way, 182 it needs to set up a communication channel between the ingress node 183 and the egress node. New protocols or extensions to existing 184 protocol may be required. 186 Another candidate way is to leverage a centralized controller (e.g., 187 PCE) to assign the Path label. The ingress node sends a request to 188 the PCE to compute a SR path and indicate that a Path label is 189 desired. The PCE will compute the path as required. Once the path 190 computed, the PCE will send a request (with computed path and 191 relevant information) to the egress node to ask for a Path label for 192 the SR path. The egress node will allocate a label to the SR path 193 and build mapping relationship between the label and the path. A 194 reply will be sent back to the PCE, the PCE will send a reply to the 195 ingress node about the path information and the corresponding Path 196 Segment label. 198 With either way or the variations, the final purpose is to assign a 199 label from the egress node's label space, hence a single label is 200 enough for path identification. Then the ingress node can put the 201 Path Segment label into the label stack when needed, and the egress 202 node can use that Path Segment to implement relevant functionalities. 204 2.2. Two Labels Solution 206 Two segments (Source segment and Path segment) are used to identify 207 an SR path. The Source segment is a global node segment, it can 208 uniquely identify a node within an SR domain. It MUST NOT be used 209 for forwarding and indicates that a Path segment immediately follows. 210 The Path segment is a local segment generated at the ingress node to 211 identify an SR path. The combination of Source segment and Path 212 segment can uniquely identify an SR Path with an SR domain. 214 A node that enables Path segment function will be assigned two node 215 segments. One is for forwarding just as defined in 216 [I-D.ietf-spring-segment-routing], the other is for source 217 identification. The corresponding label of the Source Segment is 218 indexed in the SRGB (or in a of the node to which the Source Segment 219 will be presented. 221 The Path segment label is a local label that is assigned to an SR 222 path at the ingress node. 224 The label stack with Source and Path segments is as below (Figure 2): 226 +--------------------+ 227 | ... | 228 +--------------------+ 229 | Label 1 | 230 +--------------------+ 231 | Label 2 | 232 +--------------------+ 233 | ... | 234 +--------------------+ 235 | Label n | 236 +--------------------+ 237 | Source Label | 238 +--------------------+ 239 | Path Label | 240 +--------------------+ 241 | ... | 242 +--------------------+ 244 Figure 2: Label Stack with Source and Path Segments 246 Where: 248 o The Label 1-n are the segment labels that are used to direct how 249 to steer the packets along an SR path, and the "label n" is the 250 last label of the SR path or the label that directs forwarding 251 packets to the node to which the Source Segment will be presented. 253 o The Source Label identifies the source of the SR path. The value 254 of the TC and TTL fields of the Source Label MUST be set to the 255 same values as the label (e.g., the Label n) it follows. 257 o The Path Label identifies the SR path in the context of source 258 node. If the Path label is the bottom label, the S bit MUST be 259 set. The value of the TC and TTL fields SHOULD be set to the same 260 values as the Source label. 262 The Source and Path label MUST be inserted at the ingress node of an 263 SR path. And they MUST immediately follow the label that directs 264 forwarding packets to the node (e.g., the egress or an intermediate 265 node) to which the Source Segment (as the stack top label) and Path 266 Segment are presented. 268 If a node receives a packet with an unknown Source Label, the packet 269 MUST be discarded and an error SHOULD be reported. 271 The Source label and Path label MUST be popped at the node who 272 receives a packet with the Source label as the stack top label. 274 3. Path Segment Application 276 3.1. Performance Measurement 278 To measure the packet loss and delay of the real traffic of an SR 279 path, one fundamental condition is path identification at the 280 measuring points. For an SR path, the ingress node have the complete 281 information of the path, it can use those information for packet 282 counting and/or timestamping. At the egress node, since the Path 283 Segment label (or combination with Source label) can be used to 284 identify the path, path based packet counting and/or timestamping can 285 be implemented as well. Then combined with the mechanisms defined 286 [RFC6374], end-2-end packet loss and/or delay measurement of an SR 287 path can be achieved. 289 Measuring at intermediate nodes needs more consideration, it will be 290 added in the next version. 292 3.2. End-2-end Path Protection 294 For end-2-end 1+1 path protection, the egress node of an path needs 295 to know the set of paths that constitute the primary and the 296 backup(s), in order to select the primary packet for onward 297 transmission, and to discard the packets from the backups. 299 To do this each path needs a path identifier that is unique at the 300 egress node. Depending on the design, this single unique label 301 chosen by the egress PE or the combination of the source node 302 identifier and a unique path identifier chosen by the source. 304 There then needs to be a method of binding this path identifiers into 305 equivalence groups such that the egress PE can determine the set of 306 packets that represent a single path and its backup. 308 It is obvious that this group can be instantiated in the network by 309 an SDN controller. 311 In a network that is using a distributed control plane the approach 312 will depend on the control protocol used, but the essence of the 313 solution is that which ever PE is responsible for creating the group 314 advertises then as a group of equivalent paths. Whether one of these 315 is advertised as primary and the others as secondary will or all are 316 advertised as of equal status will depend on the details of the 317 underlying protection mechanism. 319 3.3. Bi-directional SR Tunnel 321 With the current SR architecture, an SR path is an unidirectional 322 path. In some scenarios, for example, mobile backhaul transport 323 network, there are requirements to support bi-directional path, and 324 the path is normally treated as a single entity and both directions 325 of the path have same fate, for example, failure in one direction 326 will result in switching at both directions. 328 MPLS supports this by introducing the concepts of co-routed 329 bidirectional LSP and associated bi-directional LSP. With SR, to 330 support bidirectional path, a straightforward way is to bind two 331 unidirectional SR paths to a single bi-directional path. Path 332 segments can be used to correlate the two unidirectional SR paths at 333 both ends of the paths. 335 4. IANA Considerations 337 This document makes no request of IANA. 339 Note to RFC Editor: this section may be removed on publication as an 340 RFC. 342 5. Security Considerations 344 6. Contributors 346 The following individuals also contribute to this document. 348 o Shuangping Zhan, ZTE 350 o Cheng Li, Huawei 352 7. Acknowledgements 354 The authors would like to thank Stewart Bryant for his review, 355 suggestion and comments to this document. 357 8. References 359 8.1. Normative References 361 [I-D.ietf-6man-segment-routing-header] 362 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 363 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 364 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 365 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 366 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 367 segment-routing-header-07 (work in progress), July 2017. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 8.2. Informative References 376 [I-D.ietf-spring-segment-routing] 377 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 378 Litkowski, S., and R. Shakir, "Segment Routing 379 Architecture", draft-ietf-spring-segment-routing-13 (work 380 in progress), October 2017. 382 [I-D.ietf-spring-segment-routing-mpls] 383 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 384 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 385 data plane", draft-ietf-spring-segment-routing-mpls-10 386 (work in progress), June 2017. 388 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 389 Measurement for MPLS Networks", RFC 6374, 390 DOI 10.17487/RFC6374, September 2011, 391 . 393 Authors' Addresses 395 Weiqiang Cheng 396 China Mobile 398 Email: chengweiqiang@chinamobile.com 400 Lei Wang 401 China Mobile 403 Email: wangleiyj@chinamobile.com 404 Han Li 405 China Mobile 407 Email: lihan@chinamobile.com 409 Mach(Guoyi) Chen 410 Huawei 412 Email: mach.chen@huawei.com 414 Royi Zigler 415 Broadcom 417 Email: royi.zigler@broadcom.com 419 Shuangping Zhan 420 ZTE 422 Email: zhan.shuangping@zte.com.cn