idnits 2.17.1 draft-ietf-pwe3-p2mp-pw-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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 (March 11, 2012) is 4400 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) == Unused Reference: 'RFC2119' is defined on line 636, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- No information found for draft-ietf-pwe3-pw-types-wc-fec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PW-TWC-FEC' == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-03 == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-15 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Siva Sivabalan (Ed.) 3 Internet Draft Sami Boutros (Ed.) 4 Intended status: Standards Track Luca Martini 5 Expires: September 11, 2012 Cisco Systems 7 Frederic Jounay Maciek Konstantynowicz 8 Philippe Niger Juniper 9 France Telecom 10 Gianni Del Vecchio 11 Thomas D. Nadeau Swisscom 12 CA Technologies 13 Yuji Kamite 14 Simon Delord NTT Communications 15 Telstra 16 Lizhong Jin 17 Laurent Ciavaglia ZTE 18 Martin Vigoureux 19 Alcatel-Lucent 20 March 11, 2012 22 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP 23 draft-ietf-pwe3-p2mp-pw-04.txt 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on September 11, 2012. 48 Abstract 50 This document specifies a mechanism to signal Point-to-Multipoint 51 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 52 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 53 MPLS enabled PSN. A P2MP PW established via the proposed mechanism is 54 root initiated. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Terminology....................................................4 60 3. Signaling P2MP PW..............................................5 61 3.1. PW ingress to egress incompatibility issues...............6 62 3.2. P2MP PW FEC...............................................7 63 3.3. Typed Wildcard FEC Format for new FEC....................12 64 3.4. Group ID usage...........................................13 65 3.5. Generic Label TLV........................................13 66 4. LDP Capability Negotiation....................................13 67 5. P2MP PW Status................................................15 68 6. Security Considerations.......................................15 69 7. IANA Considerations...........................................16 70 7.1. FEC Type Name Space......................................16 71 7.2. LDP TLV Type.............................................16 72 7.3. mLDP Opaque Value Element TLV Type.......................16 73 7.4. Selective Tree Interface Parameter sub-TLV Type..........16 74 7.5. WildCard PMSI tunnel type................................17 75 8. Acknowledgment................................................17 76 9. References....................................................17 77 9.1. Normative References.....................................17 78 9.2. Informative References...................................18 79 Author's Addresses...............................................19 80 Full Copyright Statement.........................................21 81 Intellectual Property Statement..................................21 83 1. Introduction 85 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the 86 essential attributes of a unidirectional P2MP Telecommunications 87 service such as P2MP ATM over PSN. A major difference between a 88 Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that 89 the former is intended for bidirectional service whereas the latter 90 is intended for both unidirectional, and optionally bidirectional 91 service. Requirements for P2MP PW are described in [P2MP-PW-REQ]. 93 P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or 94 Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW- 95 REQ]. P2MP MS-PW is outside the scope of this document. A reference 96 model for P2MP PW is depicted in Figure 1 below. A transport LSP 97 associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP 98 TE tunnel established via RSVP-TE [RFC4875] or P2MP LSP established 99 via mLDP [RFC6388]) spanning from the Root-PE to the Leaf-PE(s) of 100 the P2MP SS-PW tree. For example, in Figure 1, PW1 can be associated 101 with a P2MP TE tunnel or P2MP LSP setup using mLDP originating from 102 PE1 and terminating at PE2 and PE3. 104 |<--------------P2MP PW---------------->| 105 Native | | Native 106 Service | |<--PSN1->| |<--PSN2->| | Service 107 (AC) V V V V V V (AC) 108 | +-----+ +------+ +------+ | 109 | | | | P1 |=========|T-PE2 |AC3 | +---+ 110 | | | | .......PW1.........>|-------->|CE3| 111 | |T-PE1|=========| . |=========| | | +---+ 112 | | .......PW1........ | +------+ | 113 | | . |=========| . | +------+ | 114 | | . | | . |=========|T-PE3 |AC4 | +---+ 115 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 116 |CE1|------->|... | | |=========| | | +---+ 117 +---+ | | . | +------+ +------+ | 118 | | . | +------+ +------+ | 119 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 120 | | .......PW1..............PW1.........>|-------->|CE5| 121 | | |=========| |=========| | | +---+ 122 | +-----+ +------+ +------+ | 124 Figure 1: P2MP PW 126 Mechanisms for establishing P2P SS-PW using LDP are described in 128 [RFC4447]. In this document, we specify a method to signal P2MP PW 129 using LDP. In particular, we define new FEC, TLVs, parameters, and 130 status codes to facilitate LDP to signal and maintain P2MP PWs. 132 As outlined in [P2MP-PW-REQ], even though the traffic flow from a 133 Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be 134 desirable for any L-PE to send unidirectional P2P traffic destined 135 only to the R-PE. The proposed mechanism takes such option into 136 consideration. 138 The P2MP PW requires an MPLS LSP to carry the PW traffic, and the 139 MPLS packets carried over the PW will be encapsulated according to 140 the methods described in [RFC5332]. 142 Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC-2119 Error! 147 Reference source not found.. 149 2. Terminology 151 FEC: Forwarding Equivalence Class 153 LDP: Label Distribution Protocol 155 mLDP: Label Distribution Protocol for P2MP/MP2MP LSP 157 LSP: Label Switching Path 159 MS-PW: Multi-Segment Pseudowire 161 P2P: Point to Point 163 P2MP: Point to Multipoint 165 PE: Provider Edge 167 PSN: Packet Switched Network 168 PW: Pseudowire 170 SS-PW: Single-Segment Pseudowire 172 S-PE: Switching Provider Edge Node of MS-PW 174 TE: Traffic Engineering 176 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 178 L-PE: Leaf-PE - egress PE. 180 3. Signaling P2MP PW 182 In order to advertise labels as well as exchange PW related LDP 183 messages, PEs must establish LDP sessions among themselves using the 184 Extended Discovery Mechanisms. A PE discovers other PEs that are to 185 be connected via P2MP PWs either via manual configuration or 186 autodiscovery [RFC6074]. 188 R-PE and each L-PE MUST be configured with the same FEC as defined 189 in the following section. 191 P2MP PW requires that there is an active P2MP PSN LSP set up between 192 R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP 193 is different depending on the signaling protocol used (RSVP-TE or 194 mLDP). 196 In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any 197 time; whereas in the case of RSVP-TE, the P2MP LSP is set up by the 198 R-PE, generally at the initial service provisioning time. It should 199 be noted that local policy can override any decision to join, add or 200 prune existing or new L-PE(s) from the tree. In any case, the PW 201 setup can ignore these differences, and simply assume that the P2MP 202 PSN LSP is available when needed. 204 A P2MP PW signaling is initiated by the R-PE simply by sending a 205 P2MP-PW LDP label mapping message to the L-PE(s) belonging to that 206 P2MP PW. This label mapping message will contain the following: 208 1. A FEC TLV containing P2MP PW Upstream FEC element that 209 includes Transport LSP sub TLV. 210 2. An Interface Parameters TLV, as described in [RFC4447]. 211 3. A PW Grouping TLV, as described in [RFC4447]. 212 4. A label TLV for the upstream-assigned label used by R-PE 213 for the traffic going from R-PE to L-PE(s). 215 The R-PE imposes the upstream-assigned label on the outbound packets 216 sent over the P2MP-PW, and using this label an L-PE identifies the 217 inbound packets arriving over the P2MP PW. 219 Additionally, the R-PE MAY send label mapping message(s) to one or 220 more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use 221 such PW(s) to send traffic to the R-PE. This optional label mapping 222 message will contain the following: 224 1. P2P PW Downstream FEC element. 225 2. A label TLV for the down-stream assigned label used by the 226 corresponding L-PE to send traffic to the R-PE. 228 The LDP liberal label retention mode is used, and per requirements 229 specified in [RFC5036], the Label Request message MUST also be 230 supported. 232 The upstream-assigned label is allocated according to the rules in 233 [RFC5331]. 235 When an L-PE receives a PW Label Mapping Message, it MUST verify the 236 associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP 237 is not in place, and its type is LDP P2MP LSP, the L-PE SHOULD 238 attempt to join the P2MP LSP associated with the P2MP PW. If the 239 associated P2MP PSN LSP is not in place, and its type is RSVP-TE 240 P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is 241 signaled. 243 3.1. PW ingress to egress incompatibility issues 245 If an R-PE signals a PW with a pw type, CW mode, or interface 246 parameters that a particular L-PE cannot accept, then the L-PE must 247 not enable the PW, and notify the user. In this case, a PW status 248 message with status code of 0x00000001 (Pseudowire Not Forwarding) 249 MUST also be sent to the R-PE. 251 Note that this procedure does not apply if the L-PE had not been 252 provisioned with this particular P2MP PW. In this case according to 253 the LDP liberal label retention rules, no action is taken. 255 3.2. P2MP PW FEC 257 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 258 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 259 We define two new types of FEC elements called "P2MP PW Upstream FEC 260 Element" and "P2P PW Downstream FEC Element". These FEC elements are 261 associated with a mandatory upstream assigned label and an optional 262 downstream assigned label respectively. 264 FEC type of the P2MP PW Upstream FEC Element is 0x82 (pending IANA 265 allocation) and is encoded as follows: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | P2MP PW Up |C| PW Type | PW Info Length| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AGI Type | Length | AGI Value | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ~ AGI Value (contd.) ~ 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | AII Type | Length | SAII Value | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 ~ SAII Value (contd.) ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |PMSI Tunnel typ| Length | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 284 + + 285 ~ Transport LSP ID ~ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 | Optional Parameters | 290 ~ ~ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 2: P2MP PW Upstream FEC Element 295 * PW Type: 297 15-bit representation of PW type, and the assigned values are 298 assigned by IANA. 300 * C bit: 302 A value of 1 or 0 indicates whether control word is present or 303 absent for the P2MP PW. 305 * PW Info Length: 307 Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional 308 Parameters field in octets. If this value is 0, then it 309 references all PWs using the specified grouping ID. In this case, 310 there are neither other FEC element fields (AGI, SAII, etc.) 311 present, nor any interface parameters TLVs. Alternatively, we can 312 use typed WC FEC described in section 3.3 to achieve the same or 313 to have better filtering. 315 * AGI: 317 Attachment Group Identifier can be used to uniquely identify VPN 318 or VPLS instance associated with the P2MP PW. This has the same 319 format as the Generalized PWid FEC element [RFC4447]. 321 * SAII: 323 Source Attachment Individual Identifier is used to identify the 324 root of the P2MP PW. The root is represented using AII type 2 325 format specified in [RFC5003]. Note that the SAII can be omitted 326 by simply setting the length and type to zero. 328 P2MP PW is identified by the Source Attachment Identifier (SAI). 329 If the AGI is non-null, the SAI is the combination of the SAII 330 and the AGI, if the AGI is null, the SAI is the SAII. 332 * PMSI Tunnel Type and Transport LSP ID: 334 A P2MP PW MUST be associated with a transport LSP which can be 335 established using RSVP-TE or mLDP. 337 * PMSI Tunnel Type: 339 The PMSI tunnel type is defined in [L3VPN-MCAST]. 341 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is 342 a P2MP FEC Element as defined in [RFC6388]. A new mLDP Opaque 343 Value Element type for L2VPN-MCAST application needs to be 344 allocated. 346 * Transport LSP ID: 347 This is the Tunnel Identifier which is defined in [L3VPN-MCAST]. 349 An R-PE sends Label Mapping Message as soon as the transport LSP 350 ID associated with the P2MP PW is known (e.g., via configuration) 351 regardless of the operational state of that transport LSP. 352 Similarly, an R-PE does not withdraw the labels when the 353 corresponding transport LSP goes down. Furthermore, an L-PE 354 retains the P2MP PW labels regardless of the operational status 355 of the transport LSP. 357 Note that a given transport LSP can be associated with more than one 358 P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s). 360 In the case of LDP P2MP LSP, when an L-PE receives the Label 361 Mapping Message, it can initiate the process of joining the P2MP LSP 362 tree associated with the P2MP PW. 364 In the case of RSVP-TE P2MP LSP, only the R-PE initiates the 365 signaling of P2MP LSP. 367 * Optional Parameters: 369 The Optional Parameter field can contain some TLVs that are not 370 part of the FEC, but are necessary for the operation of the PW. 371 This proposed mechanism uses two such TLVs: Interface Parameters 372 TLV, and Group ID TLV. 374 The Interface Parameters TLV and Group ID TLV specified in 375 [RFC4447] can also be used in conjunction with P2MP PW FEC in a 376 label message. For Group ID TLV, the sender and receiver of these 377 TLVs should follow the same rules and procedures specified in 378 [RFC4447]. For Interface Parameters TLV, the procedure differs 379 from the one specified in [RFC4447] due to specifics of P2MP 380 connectivity. When the interface parameters are signaled by a R- 381 PE, each L-PE must check if its configured value(s) is less than 382 or equal to the threshold value provided by the R-PE (e.g. MTU 383 size (Ethernet), max number of concatenated ATM cells, etc)). For 384 other interface parameters like CEP/TDM Payload bytes (TDM), the 385 value MUST exactly match the values signaled by the R-PE. 387 Multicast traffic stream associated with a P2MP PW can be 388 selective or inclusive. To support the former, this document 389 defines a new optional Selective Tree Interface Parameter sub-TLV 390 (type is pending IANA allocation) according to the format 391 described in [RFC4447]. The value of the sub-TLV contains the 392 source and the group for a given multicast tree as shown in Figure 393 3. Also, if a P2MP PW is associated with multiple selective trees, 394 the corresponding label mapping message will carry more than one 395 instance of this Sub-TLV. Furthermore, in the absence of this sub- 396 TLV, the P2MP PW is associated with all multicast traffic stream 397 originating from the root. 399 +----------------------------------------- + 400 | Multicast Source Length (1 Octet) | 401 +----------------------------------------- + 402 | Multicast Source (variable length) | 403 +----------------------------------------- + 404 | Multicast Group Length (1 Octet) | 405 +----------------------------------------- + 406 | Multicast Group (variable length) | 407 +----------------------------------------- + 409 Figure 3: Selective Tree Interface Parameter Sub-TLV Value 411 Note that since the LDP label mapping message is only sent by the R- 412 PE to all the L-PEs, it is not possible to negotiate any interface 413 parameters. 415 The type of optional P2P PW Downstream FEC Element is 0x83 (pending 416 IANA allocation), and is encoded as follows: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | P2P PW Down |C| PW Type | PW Info Length| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | AGI Type | Length | AGI Value | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 ~ AGI Value (contd.) ~ 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | AII Type | Length | SAII Value | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 ~ SAII Value (contd.) ~ 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 4: P2P PW Downstream FEC Element 436 The definition of the fields in the P2P PW Downstream FEC Element is 437 the same as those of P2MP PW Upstream FEC Element. 439 3.3. Typed Wildcard FEC Format for new FEC 441 [RFC5918] defines the general notion of a "Typed Wildcard" FEC 442 Element, and requires FEC designer to specify a typed wildcard FEC 443 element for newly defined FEC element types. This document defines 444 two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC 445 element, and hence requires us to define their Typed Wildcard 446 format. 448 [PW-TWC-FEC] defines Typed Wildcard FEC element format for other PW 449 FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as 450 follows: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |Typed Wcard=0x5|Type=PW FEC| Len = 3 |R| PW type | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | . . . | PMSI Tun Type | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 5: Typed Wildcard Format for P2MP PW FEC Elements 460 [PW-TWC-FEC] specifies that "Type" field can be either "PWid" (0x80) 461 or "Generalized PWid" (0x81) FEC element type. This document reuses 462 the existing typed wildcard format as specified in [PW-TWC-FEC] and 463 illustrated in Figure 5. We extend the definition of "Type" field to 464 also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element 465 types, as well as add an additional field "PMSI Tun Type". We 466 reserve PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel 467 type. This "wildcard" transport tunnel type can be used in a typed 468 wildcard p2mp FEC for further filtering. This field only applies to 469 Typed wildcard P2MP PW Upstream FEC and MUST be set to "wildcard" 470 for "P2P PW Downstream FEC" typed wildcard element. 472 3.4. Group ID usage 474 The Grouping TLV as defined in [RFC4447] contains a group ID capable 475 of indicating an arbitrary group membership of a P2MP-PW. This group 476 ID can be used in LDP "wild card" status, and withdraw label 477 messages, as described in [RFC4447]. 479 3.5. Generic Label TLV 481 As in the case of P2P PW signaling, P2MP PW labels are carried 482 within Generic Label TLV contained in LDP Label Mapping Message. A 483 Generic Label TLV is formatted and processed as per the rules and 484 procedures specified in [RFC4447]. For a given P2MP PW, a single 485 upstream-assigned label is allocated by the R-PE, and is advertised 486 to all L-PEs using the Generic Label TLV in label mapping message 487 containing the P2MP PW Upstream FEC element. 489 The R-PE can also allocate a unique label for each L-PE from which 490 it intends to receive P2P traffic. Such a label is advertised to the 491 L-PE using Generic Label TLV and P2P PW Downstream FEC in label 492 mapping message. 494 4. LDP Capability Negotiation 496 The capability of supporting P2MP PW must be advertised to all LDP 497 peers. This is achieved by using the methods in [RFC5561] and 498 advertising the LDP "P2MP PW Capability" TLV. If an LDP peer 499 supports the dynamic capability advertisement, this can be done by 500 sending a new Capability message with the S bit set for the P2MP PW 501 capability TLV. If the peer does not supports dynamic capability 502 advertisement, then the P2MP PW Capability TLV MUST be included in 503 the LDP Initialization message during the session establishment. An 504 LSR having P2MP PW capability MUST recognize both P2MP PW Upstream 505 FEC Element and P2P PW Downstream FEC Element in LDP label messages. 507 In line with requirements listed in [RFC5561], the following TLV is 508 defined to indicate the P2MP PW capability: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |U|F| P2MP PW Capability (0x703)| Length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |S| Reserved | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 7: LDP P2MP PW Capability TLV 520 Note: TLV number pending IANA allocation. 522 * U-bit: 524 SHOULD be 1 (ignore if not understood). 526 * F-bit: 528 SHOULD be 0 (don't forward if not understood). 530 * P2MP PW Capability TLV Code Point: 532 The TLV type, which identifies a specific capability. The P2MP PW 533 capability code point is requested in the IANA allocation section 534 below. 536 * S-bit: 538 The State Bit indicates whether the sender is advertising or 539 withdrawing the P2MP PW capability. The State bit is used as 540 follows: 541 1 - The TLV is advertising the capability specified by the 542 TLV Code Point. 544 0 - The TLV is withdrawing the capability specified by the 545 TLV Code Point. 547 * Length: 548 MUST be set to 2 (octet). 550 5. P2MP PW Status 552 In order to support the proposed mechanism, a node MUST be capable 553 of handling PW status. As such, PW status negotiation procedure 554 described in [RFC4447] is not applicable to P2MP PW. 556 Once an L-PE successfully processes a Label Mapping Message for a 557 P2MP PW, it MUST send appropriate PW status according to the 558 procedure specified [RFC4447] to notify the PW status. If there is 559 no PW status notification required, then no PW status notification 560 is sent (for example if the P2MP PW is established and operational 561 with a status code of Success (0x00000000), pw status message is 562 not necessary). PW status message sent from any L-PE to R-PE 563 contains P2P PW Downstream FEC to identify the PW. 565 An R-PE also sends PW status to L-PE(s) to reflect its view of a 566 P2MP PW state. Such PW status message contains P2MP PW Upstream FEC 567 to identify the PW. 569 Connectivity status of the underlying P2MP LSP that P2MP PW is 570 associated with, can be verified using LSP Ping and Traceroute 571 procedures described in [P2MP-LSP-PING]. 573 6. Security Considerations 575 The security measures described in [RFC4447] is adequate for the 576 proposed mechanism. 578 7. IANA Considerations 580 7.1. FEC Type Name Space 582 This document uses two new FEC element types, number 0x82 and 0x83 583 will be requested as an allocation from the registry "FEC Type Name 584 Space" for the Label Distribution Protocol (LDP RFC5036): 586 Value Hex Name Reference 587 ------- ----- ----------------------------- --------- 588 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 589 131 0x83 P2P PW Downstream FEC Element RFCxxxx 591 7.2. LDP TLV Type 593 This document uses a new LDP TLV types, IANA already maintains a 594 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 595 following values are suggested for assignment: 597 TLV type Description: 599 0x0703 P2MP PW Capability TLV 601 7.3. mLDP Opaque Value Element TLV Type 603 This document requires allocation of a new mLDP Opaque Value Element 604 Type from the LDP MP Opaque Value Element type name space defined in 605 [mLDP]. 607 The following value is suggested for assignment: 609 TLV type Description 610 0x3 L2VPN-MCAST application TLV 612 7.4. Selective Tree Interface Parameter sub-TLV Type 614 This document requires allocation of a sub-TLV from the registry 615 "Pseudowire Interface Parameters Sub-TLV Type". 617 The following value is suggested for assignment: 619 TLV type Description 620 0x0D Selective Tree Interface Parameter. 622 7.5. WildCard PMSI tunnel type. 624 This document requires the allocation of PMSI tunnel Type 0xFF to 625 mean wildcard transport tunnel type 627 8. Acknowledgment 629 Authors would like thank Andre Pelletier and Parag Jain for their 630 valuable suggestions. 632 9. References 634 9.1. Normative References 636 [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate 637 Requirement Levels", RFC 2119, March, 1997. 639 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 640 et al., RFC 4447, April 2006. 642 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 643 Specification", RFC 5036, October 2007. 645 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 646 Individual Identifier (AII) Types for Aggregation", RFC5003, 647 September 2007. 649 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 650 Assignment and Context-Specific Label Space", RFC 5331, August 2008. 652 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS 653 Multicast Encapsulations", RFC 5332, August 2008. 655 [RFC6388] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 656 Distribution Protocol Extensions for Point-to-Multipoint and 657 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 658 2011. 660 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 661 "Extensions to Resource Reservation Protocol - Traffic Engineering 662 (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", 663 RFC 4875, May 2007. 665 [L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 666 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft- 667 ietf-l3vpn-2547bis-mcast-bgp-08.txt, Work in Progress, October 2009. 669 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 670 Capabilities", RFC 5561, July 2009. 672 [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard 673 Forwarding Equivalence Class", RFC 5918, August 2010. 675 [PW-TWC-FEC] K. Raza, S. Boutros, and C. Pignataro, "LDP Typed 676 Wildcard FEC for PWid and Generalized PWid FEC Elements", 677 draft-ietf-pwe3-pw-types-wc-fec-03.txt, work in progress, 678 February 2012. 680 9.2. Informative References 682 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 684 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- 685 Discovery, and Signaling in Layer 2 Virtual Private Networks 686 (L2VPNs)", RFC6074, January 2011. 688 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point to 689 Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-03.txt, 690 Work in Progress, August 2010. 692 [P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane 693 Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) 694 - Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-15.txt, 695 Work In Progress, January 2011. 697 Author's Addresses 699 Siva Sivabalan 700 Cisco Systems, Inc. 701 2000 Innovation Drive 702 Kanata, Ontario, K2K 3E8 703 Canada 704 Email: msiva@cisco.com 706 Sami Boutros 707 Cisco Systems, Inc. 708 3750 Cisco Way 709 San Jose, California 95134 710 USA 711 Email: sboutros@cisco.com 713 Luca Martini 714 Cisco Systems, Inc. 715 9155 East Nichols Avenue, Suite 400 716 Englewood, CO, 80112 717 United States 718 Email: lmartini@cisco.com 720 Maciek Konstantynowicz 721 Juniper Networks 722 UNITED KINGDOM 723 e-mail: maciek@juniper.net 725 Gianni Del Vecchio 726 Swisscom (Schweiz) AG 727 Zentweg 9 728 CH-3006 Bern 729 Switzerland 730 e-mail: Gianni.DelVecchio@swisscom.com 732 Thomas D. Nadeau 733 CA Technologies 734 273 Corporate Drive 735 Portsmouth, NH 03801 736 USA 737 e-mail: thomas.nadeau@ca.com 739 Frederic Jounay 740 France Telecom 741 2, avenue Pierre-Marzin 742 22307 Lannion Cedex 743 FRANCE 744 Email: frederic.jounay@orange-ftgroup.com 746 Philippe Niger 747 France Telecom 748 2, avenue Pierre-Marzin 749 22307 Lannion Cedex 750 FRANCE 751 Email: philippe.niger@orange-ftgroup.com 753 Yuji Kamite 754 NTT Communications Corporation 755 Tokyo Opera City Tower 756 3-20-2 Nishi Shinjuku, Shinjuku-ku 757 Tokyo 163-1421 758 Japan 759 Email: y.kamite@ntt.com 761 Lizhong Jin 762 ZTE 763 889 Bibo Road, 764 Shanghai, 201203 765 P.R.China 766 Email: lizhong.jin@zte.com.cn 768 Martin Vigoureux 769 Alcatel-Lucent 770 Route de Villejust 771 Nozay, 91620 772 France 773 Email: martin.vigoureux@alcatel-lucent.com 775 Laurent Ciavaglia 776 Alcatel-Lucent 777 Route de Villejust 778 Nozay, 91620 779 France 780 Email: Laurent.Ciavaglia@alcatel-lucent.com 781 Simon Delord 782 Alcatel-Lucent 783 E-mail: simon.a.delord@team.telstra.com 785 Kamran Raza 786 Cisco Systems, Inc. 787 2000 Innovation Drive 788 Kanata, Ontario, K2K 3E8 789 Canada 790 Email: skraza@cisco.com 792 Full Copyright Statement 794 Copyright (c) 2010 IETF Trust and the persons identified as the 795 document authors. All rights reserved. 797 This document is subject to BCP 78 and the IETF Trust's Legal 798 Provisions Relating to IETF Documents 799 (http://trustee.ietf.org/license-info) in effect on the date of 800 publication of this document. Please review these documents 801 carefully, as they describe your rights and restrictions with respect 802 to this document. Code Components extracted from this document must 803 include Simplified BSD License text as described in Section 4.e of 804 the Trust Legal Provisions and are provided without warranty as 805 described in the Simplified BSD License. 807 All IETF Documents and the information contained therein are provided 808 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 809 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 810 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 811 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 812 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 813 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 814 FOR A PARTICULAR PURPOSE. 816 Intellectual Property Statement 818 The IETF takes no position regarding the validity or scope of any 819 Intellectual Property Rights or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; nor does it represent that it has 823 made any independent effort to identify any such rights. 825 Copies of Intellectual Property disclosures made to the IETF 826 Secretariat and any assurances of licenses to be made available, or 827 the result of an attempt made to obtain a general license or 828 permission for the use of such proprietary rights by implementers or 829 users of this specification can be obtained from the IETF on-line IPR 830 repository at http://www.ietf.org/ipr. 832 The IETF invites any interested party to bring to its attention any 833 copyrights, patents or patent applications, or other proprietary 834 rights that may cover technology that may be required to implement 835 any standard or specification contained in an IETF Document. Please 836 address the information to the IETF at ietf-ipr@ietf.org. 838 The definitive version of an IETF Document is that published by, or 839 under the auspices of, the IETF. Versions of IETF Documents that are 840 published by third parties, including those that are translated into 841 other languages, should not be considered to be definitive versions 842 of IETF Documents. The definitive version of these Legal Provisions 843 is that published by, or under the auspices of, the IETF. Versions of 844 these Legal Provisions that are published by third parties, including 845 those that are translated into other languages, should not be 846 considered to be definitive versions of these Legal Provisions. 848 For the avoidance of doubt, each Contributor to the UETF Standards 849 Process licenses each Contribution that he or she makes as part of 850 the IETF Standards Process to the IETF Trust pursuant to the 851 provisions of RFC 5378. No language to the contrary, or terms, 852 conditions or rights that differ from or are inconsistent with the 853 rights and licenses granted under RFC 5378, shall have any effect and 854 shall be null and void, whether published or posted by such 855 Contributor, or included with or in such Contribution. 857 Acknowledgment 859 Funding for the RFC Editor function is currently provided by the 860 Internet Society.