idnits 2.17.1 draft-delord-pwe3-cw-bit-etree-07.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 (April 16, 2012) is 4390 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Simon Delord, Alcatel-Lucent 3 Internet Draft Raymond Key, Huawei 4 Category: Standard Track Frederic Jounay, Orange CH 5 Expires: October 2012 Wim Henderickx, Alcatel-Lucent 6 Lucy Yong, Huawei 7 Lizhong Jin, ZTE 9 April 16, 2012 11 Control Word Reserved bit for use in E-Tree 12 draft-delord-pwe3-cw-bit-etree-07 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 16, 2012. 37 Abstract 39 The extension described in this document allows a pair of PEs 40 connected via an Ethernet Pseudowire (PW) to signal via the use of 41 the Control Word (CW) whether the Ethernet frame encapsulated is 42 coming from a Root AC or a Leaf AC. This allows a PE receiving this 43 frame to decide whether it can be forwarded to a Leaf AC or not. 44 Such forward or drop decision is an additional filtering action 45 after the MAC-based forwarding decision. This applies to both P2P PW 46 and P2MP PW. 48 Table of Contents 50 1. Introduction....................................................3 51 2. Terminology.....................................................3 52 3. Scope and Applicability.........................................4 53 3.1. Scope & Problem...............................................4 54 3.2. Proposed Approach.............................................5 55 3.3. Applicability.................................................5 56 4. Control Word Extensions.........................................6 57 4.1. Ethernet Control Word Reserved Bit............................6 58 5. Procedures......................................................7 59 5.1. Detailed PE PW Setup Procedures...............................7 60 5.2. Detailed PE Forwarding Procedures.............................7 61 5.2.1. Forwarding PE...............................................7 62 5.2.2. Receiving PE................................................7 63 6. Security Considerations.........................................8 64 7. IANA Considerations.............................................8 65 8. Acknowledgments.................................................8 66 9. References......................................................8 67 9.1. Normative References..........................................8 68 9.2. Informative References........................................8 69 Authors' Addresses.................................................9 70 Intellectual Property and Copyright Statements.....................9 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 1. Introduction 80 This document proposes to use a specific bit within the Control Word 81 (CW) present on top of an Ethernet PW for a PE to indicate to a 82 remote PE connected via a Pseudowire (PW) whether the Ethernet frame 83 carried comes from a Root AC or a Leaf AC in an E-Tree construct 84 using VPLS. This applies to both P2P PW and P2MP PW. 86 [RFC4385] describes the preferred design of a Pseudowire Emulation 87 Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet 88 switched network. 90 [RFC4447] specifies extensions to Label Distribution Protocol (LDP) 91 for PEs to setup PWs. It also describes the procedures for PEs to 92 signal to each other whether the CW is to be used or not. 94 [RFC4448] specifies the encapsulation of Ethernet/802.3 PDUs within 95 a PW. 97 [Draft VPLS ETree Req] provides the functional requirements for MEF 98 E-Tree support in VPLS. 100 2. Terminology 102 E-Tree 104 An Ethernet VPN in which each Root AC can communicate with every 105 other AC, whereas Leaf ACs can only communicate with Root ACs. Each 106 AC on an E-Tree construct is designated as either a Root AC or a 107 Leaf AC. There can be multiple Root ACs and Leaf ACs per E-Tree 108 construct. 110 Root AC 112 An ingress frame at a Root AC can be delivered to one or more of 113 any of the other ACs in the E-Tree. Please note that this AC is 114 bidirectional. 116 Leaf AC 118 Ingress frame at a Leaf AC can only be delivered to one or more Root 119 ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered 120 to any Leaf ACs in the E-Tree. Please note that this AC is 121 bidirectional. 123 3. Scope and Applicability 125 3.1. Scope & Problem 127 One important application for carriers is the deployment of E-Tree 128 services over an MPLS backbone using VPLS. 130 +---------+ +---------+ 131 | PE1 | | PE2 | 132 | | | | 133 +---+ | +---+ | | +---+ | +---+ 134 |CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3| 135 +---+ (Root AC) | | V | | | | V | | (Root AC) +---+ 136 | | | | Ethernet | | | | 137 | | S +--+----PW----+--+ S | | 138 +---+ | | | | | | | | +---+ 139 |CE2+-----AC2----+--+ I | | | | I +--+----AC4-----+CE4| 140 +---+ (Leaf AC) | | | | | | | | (Leaf AC) +---+ 141 | +---+ | | +---+ | 142 | | | | 143 +---------+ +---------+ 144 <---------- E-Tree ----------> 146 Figure 1. E-Tree over MPLS using VPLS 148 Figure 1 describes a scenario where PE1 and PE2 need to establish an 149 E-Tree construct between different Ethernet endpoints. Each PE has 2 150 ACs connected to a VSI. These VSIs are then linked together via an 151 Ethernet PW. 153 AC1 is a Root AC on PE1 and AC2 is a Leaf AC on PE1. 155 AC3 is a Root AC on PE2 and AC4 is a Leaf AC on PE2. 157 With an E-Tree construct: 158 - AC1 can receive from and transmit to AC2, AC3 and AC4 159 - AC3 can receive from and transmit to AC1, AC2 and AC4 160 - AC2 and AC4 can receive from and transmit to AC1 and AC3 161 - AC2 and AC4 cannot receive from or transmit to each other 163 When an Ethernet Frame is received on PE1 via AC1, the frame can be 164 transmitted to AC2 and via the Ethernet PW connecting PE1 and PE2 to 165 AC3 and AC4. 167 However when an Ethernet Frame is received on PE1 via AC2, the frame 168 can be transmitted to AC3 via the Ethernet PW but not to AC4. 170 When PE2 receives an Ethernet frame from PE1 via the Ethernet PW, 171 there is no indication whether it is from a Leaf AC or a Root AC, PE2 172 is therefore unable to decide whether it can be forwarded to AC4 173 (Leaf AC) as per the E-Tree construct. 175 3.2. Proposed Approach 177 A simple fix to this problem is to carry one additional bit of 178 information (0 or 1) for each Ethernet payload frame on the Ethernet 179 PW. 181 This per-payload signaling approach indicates whether the payload 182 frame is from a Leaf AC or a Root AC on the ingress PE. 184 Based on this per-payload extra-information, the egress PE can decide 185 whether the payload frame can be forwarded to a Leaf AC or not. 187 [RFC4385] defines in section 3 the Preferred PW MPLS Control Word. 189 0 1 2 3 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |0 0 0 0| Flags |FRG| Length | Sequence Number | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Flags (bits 4 to 7): 196 These bits MAY be used by for per-payload signaling. Their 197 semantics MUST be defined in the PW specification. 199 [RFC4448] defines in section 4.6 the Control Word for Ethernet PW. 201 0 1 2 3 202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |0 0 0 0| Reserved | Sequence Number | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 The Flags (bits 4 to 7 of the Control Word) are "reserved for future 208 use" bits in the current Ethernet PW standard that can be used for 209 such per-payload signaling. 211 3.3. Applicability 213 The proposed approach in this document will allow the egress PE to 214 make a decision for each Ethernet frame arriving on the PW from the 215 ingress PE whether this frame can be forwarded towards a Leaf AC. 217 Obviously, each PE is also responsible for locally identifying which 218 ACs are Root ACs or Leaf ACs and for not forwarding Ethernet frames 219 between Leaf ACs. The most common procedure for doing so is to apply 220 a split horizon rule between Leaf ACs. However this is out of scope 221 of this document. 223 4. Control Word Extensions 225 4.1. Ethernet Control Word Reserved Bit 227 [RFC4448] defines in section 4.6 the CW format for an Ethernet PW. 229 The Control Word defined in this section is based on the Generic PW 230 MPLS Control Word as defined in [RFC4385]. It provides the ability 231 to sequence individual frames on the PW, avoidance of equal-cost 232 multiple-path load-balancing (ECMP), and Operations and Management 233 (OAM) mechanisms including VCCV. 235 The Control Word is defined as follows: 237 0 1 2 3 238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |0 0 0 0|L| Reserved | Sequence Number | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 In the above diagram, the first 4 bits MUST be set to 0 to indicate 244 PW data. 246 Leaf bit (L). 248 The L-bit is used to flag the presence of an Ethernet frame from 249 a Leaf AC as follows: 251 L = 1 The Ethernet Frame comes from a Leaf AC 252 L = 0 The Ethernet Frame comes from a Root AC 254 The rest of the first 16 bits are reserved for future use. They MUST 255 be set to 0 when transmitting, and MUST be ignored upon receipt. 257 The next 16 bits provide a sequence number that can be used to 258 guarantee ordered frame delivery. The processing of the sequence 259 number field is OPTIONAL. 261 The sequence number space is a 16-bit, unsigned circular space. The 262 sequence number value 0 is used to indicate that the sequence number 263 check algorithm is not used. The sequence number processing 264 algorithm is found in [RFC4385]. 266 5. Procedures 268 [RFC4447] defines the procedures by which PEs maintain and exchange 269 PW information via LDP. 271 This document does not change any of the procedures defined in 272 [RFC4447]. The rules for negotiating the use of the CW are defined 273 in section 6. 275 5.1. Detailed PE PW Setup Procedures 277 In order for a PEs to signal if an Ethernet frame travelling on an 278 Ethernet PW comes from a Root AC or a Leaf AC, it MUST use the 279 extension defined in this document. 281 The procedure MUST follow the standard procedures described in 282 [RFC4447]. 284 The Label Mapping messages that are sent in order to set up these 285 PWs MUST have c=1. When a Label Mapping message for a PW of one 286 of these types is received and c=0, a Label Release message MUST 287 be sent, with an "Illegal C-bit" status code. In this case, the 288 PW will not be enabled. 290 5.2. Detailed PE Forwarding Procedures 292 5.2.1. Forwarding PE 294 The L-bit MUST only be used when the first 4 bits of the CW are 295 equal to 0000. 297 The L-bit MUST be set to 0 when the first 4 bits of the CW are equal 298 to 0001. 300 If the Ethernet frame that has to be sent across an Ethernet PW (or 301 set of Ethernet PWs) comes from a Root AC, the L bit MUST be set to 302 0. 304 If the Ethernet frame that has to be sent across an Ethernet PW (or 305 set of Ethernet PWs) comes from a Leaf AC, the L bit MUST be set to 306 1. 308 5.2.2 Receiving PE 310 Upon reception of an Ethernet Frame where the L bit in the CW is set 311 to 0, this frame can be forwarded to any AC belonging to this VPN 312 instance. 314 Upon reception of an Ethernet Frame where the L bit in the CW is set 315 to 1, this frame can be forwarded to any Root AC belonging to this 316 VPN instance but it MUST NOT be forwarded to any Leaf AC. This 317 forward or drop decision is an additional filtering action after the 318 MAC-based forwarding decision. 320 6. Security Considerations 322 This will be added in later version of this document. 324 7. IANA Considerations 326 There are no specific IANA considerations in this document. 328 8. Acknowledgments 330 The authors would like to thank Yuji Kamite for his valuable 331 comments. 333 9. References 335 9.1. Normative References 337 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 338 Requirement Levels, BCP 14, RFC 2119, March 1997. 340 [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation 341 Edge-to-Edge (PWE3) Control Word for Use over an MPLS 342 PSN, February 2006. 344 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 345 Using the Label Distribution Protocol (LDP), April 2006 347 [RFC4448] Martini, L., and al, Encapsulation Methods for 348 Transport of Ethernet over MPLS Networks, April 2006 350 9.2. Informative References 352 [Draft VPLS ETree Req] 353 Key, et al., Requirements for MEF E-Tree Support in 354 VPLS, draft-ietf-l2vpn-etree-reqt-00 (work in progress), 355 October 2011 357 Authors' Addresses 359 Simon Delord 360 Alcatel-Lucent 361 Email: simon.delord@gmail.com 363 Raymond Key 364 Huawei 365 Email: raymond.key@ieee.org 367 Frederic Jounay 368 Orange CH 369 4 rue caudray 1020 Renens 370 Switzerland 371 Email: frederic.jounay@orange.ch 373 Wim Henderickx 374 Alcatel-Lucent 375 Copernicuslaan 50 376 2018 Antwerp, Belgium 377 Email: wim.henderickx@alcatel-lucent.com 379 Lucy Yong 380 Huawei USA 381 1700 Alma Dr. Suite 500 382 Plano, TX 75075, USA 383 Email: lucy.yong@huawei.com 385 Lizhong Jin 386 ZTE Corporation 387 889, Bibo Road 388 Shanghai, 201203, China 389 Email: lizhong.jin@zte.com.cn 391 Copyright Notice 393 Copyright (c) 2012 IETF Trust and the persons identified as the 394 document authors. All rights reserved. 396 This document is subject to BCP 78 and the IETF Trust's Legal 397 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 398 license-info) in effect on the date of publication of this document. 399 Please review these documents carefully, as they describe your rights 400 and restrictions with respect to this document.